Үүлэн тооцоолол тайлбарлагдсан нь: Таны мэдэх ёстой архитектурын 11 ойлголт (4K Мастер анги).

Энэ видео юуг хамардаг

• - Архитектурын хана ба Мастер төлөвлөгөө
• - 01. Босоо ба Хэвтээ масштаблалт
• - 02. Ачаалал тэнцвэржүүлэх архитектур (L4 ба L7 ба эрүүл мэндийн шалгалт)
• - 03. Автомат масштаблалт ба уян хатан байдал
• - 04. Сервергүй (FaaS ба Firecracker MicroVMs)

Орчуулсан бичлэг

Англи хэл дээрх эх хувилбараас орчуулсан. Боломжтой дуу болон хадмал орчуулгыг YouTube хянадаг.

- Архитектурын хана ба Мастер төлөвлөгөө

0:00 Програм хангамжийн инженер бүр эцэст нь үүлэн архитектурын ханатай тулгардаг. Та өөрийн зөөврийн компьютер дээрээ програм бүтээж, үйлдвэрлэлд нэвтрүүлж, бодит хэрэглэгчид ирэх үед серверүүд "унадаг", өгөгдлийн сангийн холболтууд шавхагдаж, таны AWS-ийн төлбөр утасны дугаар шиг харагддаг. Ихэнх хөгжүүлэгчид гурван зуун өөр AWS бүтээгдэхүүний товчлолыг цээжилснээр үүлэн инженерчлэлийг шийдэхийг хичээдэг. Гэхдээ бодит үүлэн тооцоолол нь вендорын каталогийг цээжлэх тухай биш юм: энэ нь арван нэгэн суурь архитектурын анхдагч элементүүд дээр суурилдаг.

0:34 Энэхүү мастер ангид бид аж ахуйн нэгжийн бүрэн загварыг бүхэлд нь авч үзэх болно: масштаблалт, ачаалал тэнцвэржүүлэлтээс эхлээд сервергүй, үйл явдалд суурилсан салгах, хадгалах шатлал, үүлэн сүлжээ хүртэл. Эдгээр арван нэгэн ойлголтыг эзэмшсэнээр та AWS, GCP, эсвэл Azure дээр ямар ч бэкэнд загварчилж чадна. GCP, эсвэл Azure дээр ямар ч бэкэнд загварчилж чадна. Энэ бол The Daily Diff, доторх зүйлс.

- 01. Босоо ба Хэвтээ масштаблалт

0:57 Нэгдүгээр ойлголт: Масштаблалт. Таны програмд траффик нэмэгдэх үед ачааллыг зохицуулах хоёр үндсэн өөр арга байдаг: босоо масштаблалт, эсвэл хэвтээ масштаблалт. Босоо масштаблалт буюу өргөтгөх гэдэг нь одоо байгаа машинаа илүү их нөөц нэмж оруулахыг хэлнэ: дөрвөн CPU цөмөөс гучин хоёр хүртэл эсвэл гучин хоёр гигабайт RAM-ийг зуун хорин найман гигабайт RAM-аар солих. зуун хорин найман гигабайт RAM-аар солих. Босоо масштаблалт нь архитектурын ямар ч өөрчлөлт шаарддаггүй: таны код

1:28 болон өгөгдлийн сан яг хэвээр үлддэг. Гэхдээ энэ нь эцсийн техник хангамжийн хязгаарт хүрдэг. Дэлхийн нэг ч машинд арван мянган CPU цөм байхгүй, мөн дээд зэрэглэлийн инстанцууд экспоненциал үнийн нэмэгдэлтэй байдаг. Хэвтээ масштаблалт буюу өргөтгөх гэдэг нь серверүүдээ жижиг, энгийн үнэтэй байлгахыг хэлдэг боловч маршрутизаторын ард олон инстанцыг зэрэгцээ ажиллуулдаг. Хэрэв нэг инстанц "унавал" үлдсэн нодууд тэг зогсолтгүйгээр траффикийг шингээдэг. Хэвтээ масштаблалтын алтан дүрэм бол төлөвгүй байдал юм:

2:01 таны програмын серверүүд хэрэглэгчийн сесс, байршуулсан файлууд, эсвэл төлвийг өөрийн орон нутгийн диск дээр хадгалах боломжгүй. Төлөв нь гадаад өгөгдлийн сан эсвэл кэшид байх ёстой, энэ нь ямар ч нодыг ямар ч хэрэглэгчийн хүсэлтийг зохицуулах боломжийг олгодог.

- 02. Ачаалал тэнцвэржүүлэх архитектур (L4 ба L7 ба эрүүл мэндийн шалгалт)

2:17 Хоёрдугаар ойлголт: Ачаалал тэнцвэржүүлэлт. Хэвтээ масштаблалт нь цаасан дээр гайхалтай сонсогддог боловч энэ нь нэн даруй асуудал үүсгэдэг: арван мянган хэрэглэгч таны домен нэрийг ашиглах үед аль тодорхой сервер тэдний траффикийг хүлээн авах вэ? Ачаалал тэнцвэржүүлэгч нь нийтийн интернет болон таны хувийн бэкэнд кластерын хооронд байрлах урвуу прокси үүрэг гүйцэтгэдэг. Энэ нь ирж буй TCP эсвэл HTTP холболтыг хүлээн авч, хүсэлтүүдийг таны эрүүл инстанцууд дээр хуваарилдаг.

2:47 Ачаалал тэнцвэржүүлэгчид үндсэн хоёр сүлжээний давхаргад ажилладаг. Layer 4 Сүлжээний ачаалал тэнцвэржүүлэгчид дамжуулалтын давхаргад ажилладаг, IP хаяг болон порт дээр суурилсан түүхий TCP болон UDP пакетуудыг микросекундын хоцрогдолтойгоор, секундэд сая сая хүсэлтээр чиглүүлдэг. Layer 7 Аппликешн ачаалал тэнцвэржүүлэгчид HTTP протоколыг өөрийг нь шалгадаг: URL зам, хүсэлтийн толгой, күүкий, болон HTTP аргууд. Энэ нь замд суурилсан чиглүүлэлтийг идэвхжүүлдэг: slash-api хүсэлтүүдийг таны бэкэнд кластерт, slash-static хүсэлтүүдийг

3:25 объект хадгалах санд илгээх. Хамгийн чухал нь, ачаалал тэнцвэржүүлэгчид идэвхтэй эрүүл мэндийн шалгалт хийдэг. Хэдхэн секунд тутамд тэнцвэржүүлэгч инстанц бүр дээрх эрүүл мэндийн цэг рүү пинг илгээдэг. Хэрэв инстанц дараалсан гурван таван зуун алдаа гаргавал эсвэл хариу өгөхөөс татгалзвал, энэ нь тэг унасан хүсэлтгүйгээр автомат усан сангаас хасагддаг.

- 03. Автомат масштаблалт ба уян хатан байдал

3:45 Гуравдугаар ойлголт: Автомат масштаблалт. Хэрэв таны веб програмд өглөөний гурван цагт хоёр сервер хэрэгтэй боловч өдрийн дунд үед хорин сервер хэрэгтэй бол, үүлэн консол дээр товчлууруудыг гараар дарах нь зогсолт болон дампууралд хүргэх баталгаатай зам юм. Автомат масштаблалт нь хэвтээ серверийн сангуудад динамик уян хатан байдлыг авчирдаг. Автомат масштаблах бүлэг нь дундаж CPU ашиглалт, сүлжээний I-O, эсвэл дарааллын арын бичиг баримтын гүн зэрэг гүйцэтгэлийн үзүүлэлтүүдийг хянадаг. Дундаж CPU тодорхой босго хэмжээг давбал - жишээлбэл,

4:19 дараалсан гурван минутын турш далан хувь - автомат масштаблагч автоматаар шинэ виртуал машинуудыг эхлүүлж, тэдгээрийг таны ачаалал тэнцвэржүүлэгчтэй бүртгэж, траффикийг чиглүүлж эхэлдэг. Мөн адил чухал нь масштаблах явдал юм: траффикийн давалгаа буурах үед, автомат масштаблагч илүүдэл инстанцуудыг зогсоож, та хоосон тооцоололд мөнгө төлөхөө зогсоодог. "Дэлсэх"-ээс сэргийлэхийн тулд - серверүүд хурдан үүсгэгдэж, тасралтгүй хямрах гогцоонд устгагддаг — үүлэн архитекторууд тохируулдаг хөргөлтийн хугацаа. Дөрөв дэх үзэл баримтлал: Сервергүй.

- 04. Сервергүй (FaaS ба Firecracker MicroVMs)

4:53 Олон жилийн турш маркетингийн багууд сервергүйг ид шидийн код гэж сурталчилж байсан. тэнгэрт гүйж байна. Бодит байдал дээр сервергүй нь сервер ашигласаар байдаг — гэхдээ та тэднийг эзэмшдэггүй, код ажиллахгүй үед засварлахгүй, төлбөр төлөхгүй. AWS Lambda эсвэл Google Cloud Functions зэрэг Function-as-a-Service-ийг ашиглан, та бие даасан хэрэглэгчийн функц бичнэ. HTTP хүсэлт, S3 файл байршуулах эсвэл мэдээллийн сангийн өөрчлөлт үүсэх үед үүлэн хугацаа нь түр зуурын

5:23 Firecracker шиг микро-виртуал машиныг таван миллисекундээс бага хугацаанд ачаална. Таны код ажиллаж, хариулт өгөөд, унтарна. Хэрэв гурван сарын турш таны вэбсайтад хэн ч зочлоогүй бол таны тооцооллын төлбөр яг тэг доллар, тэг цент. Хэрэв нэг сая хэрэглэгч нэгэн зэрэг хандвал, үйлчилгээ үзүүлэгч нэг сая зэрэг микроVM-ийг ажиллуулна. Инженерийн солилцоо бодит юм: шинэ хугацааг ажиллуулах үеийн хүйтэн эхлүүлэх хойшлуулалт, Lambda дээрх арван таван минутын хатуу гүйцэтгэлийн хязгаар болон хатуу төлөвгүй байдал.

5:55 Сервергүй нь үйл явдлын дамжуулалт болон үе үеийн API-д тохиромжтой, харин байнгын WebSockets эсвэл олон цагийн сургалтад муу.

- 05. Үйл явдалд суурилсан архитектур (EDA ба салгах)

6:05 Тав дахь үзэл баримтлал: Үйл явдалд суурилсан архитектур, эсвэл EDA. Уламжлалт архитектурт үйлчилгээнүүд синхроноор харилцдаг. Таны худалдан авалтын үйлчилгээ төлбөр рүү дууддаг, төлбөр нь бараа материал руу дууддаг, бараа материал нь залилан руу дууддаг, залилан нь имэйл руу дууддаг. Энэ нь сүйрлийн синхрон хүрхрээг бий болгодог. Хэрэв гуравдагч талын имэйл үйлчилгээ үзүүлэгч сүлжээний доголдолтой тулгарч, арав секунд хариу өгөхөд таны хэрэглэгчийн бүх худалдан авалтын хүсэлт хугацаа дуусч, алдаа гарна. Үйл явдалд суурилсан архитектурт үйлчилгээнүүд бүрэн салангид байна.

6:37 Хэрэглэгч худалдаж авах товчийг дарахад худалдан авалтын үйлчилгээ доогуур үйлчилгээнүүд рүү залгадаггүй. Энэ нь зүгээр л OrderPlaced гэсэн үйл явдлыг төв Amazon EventBridge эсвэл SNS сэдэв зэрэг үйл явдлын автобус руу нийтэлдэг. Худалдан авалт тавин миллисекундэд дуусдаг. Төлбөр, бараа материалын хорогдол, имэйл баримтын доод талын ажилчид мессежүүдийг өөрсдийн SQS дарааллаас бие даан татдаг. Хэрэв имэйл үйлчилгээ нэг цаг унавал, мессежүүд аюулгүйгээр хүлээгдэнэ дараалалд буферлагдаж, нэг ч захиалга алдагдахгүй.

- 06. Контейнер зохицуулалт (Docker ба Kubernetes)

7:13 Зургаа дахь үзэл баримтлал: Контейнерын удирдлага. Docker савлахыг шийдсэн: энэ нь таны програмын кодыг, системийн сангууд, тохиргоо, болон ажиллах орчныг өөрчлөх боломжгүй та нарын MacBook болон үүлэн дээр адилхан ажилладаг зураг болгон боож өгдөг. Гэхдээ контейнер савлах нь амархан. Тавин физик виртуал машин дээр таван зуун контейнер ажиллуулах нь инженерчлэл доголдоход хүргэдэг. Тийм ч учраас Kubernetes болон AWS ECS шиг контейнер зохицуулагчид

7:41 байдаг. Зохицуулагч хяналтын самбар өгдөг: API сервер, etcd төлөвийн дэлгүүр, болон ухаалаг хуваарилагч. Та өөрийн хүссэн төлөвийг зарладаг: Би баталгаажуулах үйлчилгээний арван хуулбар, тус бүр хоёр гигабайт RAM-тай байхыг хүсэж байна. Хуваарилагч кластерыг шалгаж, сул санах ойтой зангилаануудад под байрлуулж, дотоод сүлжээг тохируулж, бодит байдлыг тасралтгүй зохицуулдаг. Хэрэв зангилаа тоног төхөөрөмжийн эвдрэлээс болж гэмтвэл, Kubernetes алдагдлыг илрүүлж, бүх нүүлгэн шилжүүлсэн подуудыг

- 07. Үүлэн хадгалалтын 4 тулгуур (S3, EBS, DBs ба Redis)

8:16 эрүүл зангилаануудад шууд хуваарилдаг. Долоо дахь үзэл баримтлал: Үүлэн санах ойн шатлал. Эхлэн сурагчид ихэвчлэн үүлэн санах ойг файл хаядаг нэг сав гэж үздэг. Үйлдвэрлэлийн архитектурт санах ойг хандалтын хэв маяг болон хоцролтоос хамааран дөрвөн өөр тулгуур болгон хуваадаг. Эхнийх нь Amazon S3 эсвэл Google Cloud Storage шиг объект хадгалах сан юм. Та HTTP REST API-аар дамжуулан файлуудад энгийн PUT болон GET дуудлага ашиглан хандана. Энэ нь сард нэг гигабайтад хоёр центээр хязгааргүй хэвтээ багтаамжийг санал болгодог,

8:49 видео, хэрэглэгчийн байршуулалт, лог, нөөцлөлтөд тохиромжтой. Хоёр дахь нь Amazon EBS шиг блок хадгалах сан юм. Эдгээр нь өндөр хурдны холболтоор дамжуулан тодорхой виртуал машинд шууд холбогдсон виртуал хатуу дискүүд юм. өндөр хурдны холболтоор дамжуулан. Тэд ext4 гэх мэт стандарт файлын системд форматлагддаг, мэдээллийн сангийн хөдөлгүүрт шаардлагатай хурдан санамсаргүй унших, бичих хандалтыг дэмждэг. Гурав дахь нь Удирдлагатай мэдээллийн сан: PostgreSQL шиг харилцааны хөдөлгүүрүүд RDS дээр ACID гүйлгээ болон нарийн төвөгтэй нэгдлүүдийг хангадаг,

9:21 болон DynamoDB шиг NoSQL хөдөлгүүрүүд нэг оронтой тоон асар том хэмжээнд миллисекундын хоцролтыг хангадаг. Дөрөв дэх нь Redis шиг санах ойн кэш юм. RAM-аас өгөгдөл унших нь миллисекунд биш микросекунд болдог. Кэшүүд таны мэдээллийн сангийн урд байрлаж, давтан унших траффикаас хамгаалж, хувирамтгай хэрэглэгчийн сессийн токенуудыг удирддаг.

- 08. Өндөр хүртээмжтэй байдал ба есөн удаагийн (Multi-AZ Failover)

9:44 Найм дахь үзэл баримтлал: Өндөр хүртээмж, эсвэл HA. Хүртээмж нэг асуултад хариулдаг: таны програмын хэрэглэгчдэд ажиллаж, хүртээмжтэй байх хугацааны хувь хэд вэ? Аж ахуйн нэгжийн гэрээнд хүртээмжийг есөөр хэмждэг. Хоёр ес, эсвэл ерэн есөн хувийн хүртээмж нь жил бүр гурав ба хагас өдөр тасалдлыг зөвшөөрдөг. Дөрвөн ес нь зөвшөөрөгдөх тасалдлыг тавин хоёр минут болгож бууруулдаг, таван ес нь жилд ердөө таван минутын нийт тасалдлыг зөвшөөрдөг.

10:15 Өндөр хүртээмжийг бий болгохын тулд та доголдолын домайн дахь ганц алдагдах цэгүүдийг арилгах ёстой. алдагдах домайн дагуу. Үүлэн дээр энэ нь олон хүртээмжийн бүсүүдэд байршуулахыг хэлнэ. Хүртээмжийн бүс нь нэг тавиур биш: энэ нь нэг эсвэл хэд хэдэн ялгаатай бие даасан эрчим хүч, хөргөлттэй, хоорондоо хэдэн миль зайтай физик дата төвүүд юм. Бүс А болон Бүс Б-д идэвхтэй жишээнүүдийг синхрон мэдээллийн сангийн репликацитай ажиллуулах замаар аянга буулт эсвэл шилэн кабел тасралт бүх физик байгууламжийг зогсооход автомат шилжилт хийгдэнэ.

10:50 хүний оролцоогүйгээр гучин секундын дотор.

- 09. Бат бөх байдал ба хүртээмжтэй байдал (Яагаад 11 есөн удаа ажиллахгүй байна вэ)

10:53 Ес дэх үзэл баримтлал: Бат бөх байдал ба Бэлэн байдал. Энэ бол үүлэн архитектурын ярилцлагын үеэр хамгийн түгээмэл асуудал юм Инженерүүд ихэвчлэн эдгээр үгсийг хоорондоо сольж хэрэглэдэг, гэхдээ тэдгээр нь огт өөр шинж чанаруудыг хэмждэг. Бэлэн байдал нь ажиллах хугацааг хэмждэг: би API дуудлага хийж өгөгдлөө унших эсвэл бичих боломжтой юу одоо? Бат бөх байдал нь хадгалалтыг хэмждэг: миний өгөгдөл арван жилийн турш байнгын эвдрэлгүйгээр оршин тогтнох уу? бит ялзрах, гэмтэх, эсвэл устгагдах уу?

11:24 Amazon S3 Standard-ийг харна уу. Түүний Үйлчилгээний түвшний гэрээ нь ерэн есөн цэг есөн хувийн бэлэн байдлыг санал болгодог бөгөөд энэ нь сард дөчин гурван минутын зогсолттой байхыг зөвшөөрдөг үүнд API хүсэлт таван зуун алдаа буцааж болно. Гэхдээ S3 нь арван нэгэн есийн бат бөх байдлыг амлаж байна: ерэн есөн цэг ес ес ес ес ес ес ес ес ес ес ес хувь. Хэрэв та S3-д арван сая файл хадгалсан бол статистикийн хувьд нэг файлыг алдахыг хүлээж болно.

11:56 арван мянган жилд нэг файл дунджаар. S3 нь объектуудыг устгалын кодчилол хийж, хэсгүүдийг дор хаяж гурван газарзүйн хувьд тусгаарлагдсан өгөгдлийн байгууламжид хуулбарлах замаар үүнд хүрдэг. дор хаяж гурван газарзүйн хувьд тусгаарлагдсан өгөгдлийн байгууламжид хуулбарлах замаар үүнд хүрдэг. Томоохон бүс нутгийн сүлжээний тасалдал үед S3 түр хугацаанд боломжгүй байж болох ч таны өгөгдөл хэзээ ч устгагдахгүй.

- 10. Код хэлбэрийн дэд бүтэц (Terraform ба Console Drift)

12:14 Арав дахь үзэл баримтлал: Код хэлбэртэй дэд бүтэц, эсвэл IaC. Үүлэн тооцооллын эхэн үед инженерүүд AWS руу нэвтэрсэн веб менежментийн консол дээр гар аргаар дарж виртуал үүсгэсэн машинууд, дэд сүлжээнүүдийг тохируулж, аюулгүй байдлын бүлгүүдийг холбосон. Салбар үүнийг ClickOps гэж нэрлэдэг бөгөөд үйлдвэрлэлд энэ нь үнэмлэхүй гамшиг. Гарын авлагын консолын өөрчлөлтүүд нь аудит хийх замгүй, буцаах механизмгүй, мөн зайлшгүй шатанд болон үйлдвэрлэлийн орчмын хооронд тохиргооны ялгаа үүсгэдэг. Дэд бүтэц үйлдвэрлэлийн орчмын хооронд тохиргооны ялгаа үүсгэдэг. Дэд бүтэц

12:48 Terraform, OpenTofu, Pulumi, эсвэл AWS CDK гэх мэт кодын хэрэгслээр OpenTofu, Pulumi, эсвэл AWS CDK гэх мэт кодын хэрэгслээр та өөрийн бүх үүлэн архитектураа Git-д хадгалагдсан тунхагласан тохиргооны файлуудад тодорхойлдог. Нээлттэй порт эсвэл мэдээллийн сангийн хуулбар дахь өөрчлөлт бүр татах хүсэлт болон үе тэнгийнхний хяналтаар дамждаг. terraform plan-ийг ажиллуулах нь ямар нэгэн зүйлд хүрэхээс өмнө API-ийн яг ижил зөрүүг урьдчилан хардаг ямар нэгэн зүйлд хүрэхээс өмнө API-ийн яг ижил зөрүүг урьдчилан хардаг бөгөөд таны үйлдвэрлэлийн стекний ижил хуулбарыг эхлүүлэхэд дөрвөн долоо хоногийн оронд дөрвөн минут зарцуулдаг.

- 11. Үүлэн сүлжээ (VPC, Subnets, NAT ба Аюулгүй байдлын бүлгүүд)

13:20 Арван нэг дэх үзэл баримтлал: Үүлэн сүлжээ ба Виртуал хувийн үүл. Та серверүүдийг үүлэнд байршуулахдаа тэдгээр нь түүхий нийтийн интернэтэд ил байрладаггүй. Тэд VPC гэж нэрлэгддэг програм хангамжаар тодорхойлогдсон тусгаарлагдсан хил дотор амьдардаг. VPC. Таны VPC дотор та хувийн IP хаягийн зайг хуваарилдаг, жишээлбэл арав-цэг-тэг-цэг-тэг-цэг-тэг slash арван зургаа, мөн үүнийг нийтийн болон хувийн дэд сүлжээнүүдэд хуваадаг. Нийтийн дэд сүлжээ нь Интернэт гарц руу шууд чиглэлтэй.

13:51 Энэ нь таны Аппликейшн ачааллын тэнцвэржүүлэгч болон NAT гарц гэх мэт нийтийн нүүр царайтай хөрөнгийг хадгалдаг. Энэ нь таны сүлжээний нийтийн IP хаягтай цорын ганц хэсэг юм. Таны програмын серверүүд болон үйлдвэрлэлийн мэдээллийн сангууд нь зөвхөн нийтийн IP хаяггүй, интернэтээс орох чиглэлгүй хувийн дэд сүлжээнүүдэд оршдог. Таны арын серверүүд аюулгүй байдлын шинэчлэлтүүдийг татаж авах шаардлагатай үед, тэдний гадагш чиглэсэн траффик нь нийтийн дэд сүлжээнд байгаа NAT гарцаар дамждаг. Хүрээлэн буй бүх жишээг Аюулгүй байдлын бүлгүүд: хамгийн бага давуй эрхийн зарчмыг хэрэгжүүлдэг төлөвтэй виртуал галт хана. төлөвтэй виртуал галт хана.

- 12. Аж ахуйн нэгжийн бүрэн төлөвлөгөө ба дүгнэлт

14:28 Таны мэдээллийн сангийн аюулгүй байдлын бүлэг нь зөвхөн 5432 порт дээр зөвхөн таны програмын серверүүдийн аюулгүй байдлын бүлгээс холболтыг хүлээн авдаг, гаднаас нэвтрэх боломжийг математикийн хувьд үгүй хийдэг. Та холдвол эдгээр арван нэгэн үндсэн зүйлс нэгдмэл систем болж холбогддог. Таны DNS нь нийтийн дэд сүлжээ дэх Ачааллын тэнцвэржүүлэгч рүү чиглүүлдэг, автомасштабчлах бүлгүүд нь олон Бэлэн байдлын бүсүүд дэх траффикийн өсөлтийг зохицуулдаг, үйл явдлын автобуснууд арын ажилчдыг салгадаг бөгөөд таны бүх стек Код хэлбэртэй дэд бүтцийг ашиглан Git-ээс байршуулсан.

15:02 Өнөөдрийн мастерклассын шийдвэр: SHIP IT. Хэдэн зуун үүлэн маркетингийн товчлолыг цээжлэхээ зогсоо. Эдгээр арван нэгэн архитектурын загварыг эзэмшиж, өөрийн төлөвийг салга, мөн алдагдахгүй системийг бий болго. Анх барьж эхлэх үед танд хамгийн их толгой өвдгөсөн үүлэн концепцыг коммент хэсэгт бичээрэй. коммент хэсэгт бичээрэй. Мөн бүрэн архитектурын хуурмаг хуудсыг авахын тулд, daily diff dot dev хаягаар мэдээллийн товхимолд бүртгүүлнэ үү,

15:28 доорх холбоос. Өнөөдрийн ялгаа энэ байна. Би Axrisi-гийн Нико байна. Хариуцлагатай нэгтгэ.

Эх сурвалжууд

1. AWS Well-Architected Framework (Reliability & Performance Pillars)aws.amazon.com
2. Kubernetes Architecture & Control Plane Conceptskubernetes.io
3. Martin Fowler: What is Event-Driven Architecture?martinfowler.com
4. Amazon S3 Data Durability & Availability Technical Whitepaperaws.amazon.com
5. HashiCorp: Declarative Infrastructure as Code with Terraformwww.terraform.io