# Обяснено е облачното изчисление: 11-те архитектурни концепции, които трябва да знаете (4K Masterclass).

Published: 2026-09-15

Повечето софтуерни инженери се опитват да научат облачна архитектура, като наизустяват стотици акроними на продукти от доставчици като AWS, GCP и Azure. Но инженерството на облака в реалния свят е изградено върху единадесет фундаментални архитектурни примитива. В този 4K ремастериран майсторски клас, Нико разглежда пълния корпоративен план: от вертикално спрямо хоризонтално мащабиране и балансиране на натоварването на Layer 7 до динамично автоматично мащабиране, изпълнение на безсървърни микро-виртуални машини, асинхронно управлявано от събития развързване, оркестрация на контейнери, йерархия на съхранението с четири стълба, критичната разлика между висока наличност и 11 деветки дълготрайност, декларативна инфраструктура като код и мрежи за виртуални частни облаци. Овладейте тези единадесет концепции и можете да проектирате всяка бек-енд система в производство. Присъда: SHIP IT.

Canonical: https://thedailydiff.dev/bg/video/2026-09-14-cloud-computing-explained-4k/

## Какво обхваща този видеоклип

- - Архитектурната стена и генерален план
- - 01. Вертикално спрямо хоризонтално мащабиране
- - 02. Архитектура за балансиране на натоварването (L4 срещу L7 и проверки за изправност)
- - 03. Автоматично мащабиране и еластичност
- - 04. Безсървърни (FaaS и Firecracker MicroVMs)

## Глави

- 0:00 - Архитектурната стена и генерален план
- 0:57 - 01. Вертикално спрямо хоризонтално мащабиране
- 2:17 - 02. Архитектура за балансиране на натоварването (L4 срещу L7 и проверки за изправност)
- 3:45 - 03. Автоматично мащабиране и еластичност
- 4:50 - 04. Безсървърни (FaaS и Firecracker MicroVMs)
- 6:05 - 05. Архитектура, управлявана от събития (EDA и развързване)
- 7:13 - 06. Оркестрация на контейнери (Docker и Kubernetes)
- 8:16 - 07. Четирите стълба за облачно съхранение (S3, EBS, Бази данни и Redis)
- 9:44 - 08. Висока наличност и деветките (Failover между няколко зони за наличност)
- 10:53 - 09. Дълготрайност срещу наличност (Защо 11 деветки не е време на работа)
- 12:14 - 10. Инфраструктура като код (Terraform срещу отклонение на конзолата)
- 13:20 - 11. Облачни мрежи (VPC, подмрежи, NAT и групи за сигурност)
- 14:26 - 12. Пълният корпоративен план и присъда

## Преведен препис

Преведено от оригиналния английски разказ. Наличните аудио и субтитри се контролират от YouTube.

### - Архитектурната стена и генерален план

0:00 Всеки софтуерен инженер в крайна сметка се сблъсква със стената на облачната архитектура. Изграждаш приложение на лаптопа си, качваш го в производство, и в момента, в който пристигнат реални потребители, сървърите се сриват, връзките към базата данни се изчерпват, и сметката ти за AWS изглежда като телефонен номер. Повечето разработчици се опитват да решат проблемите с облачното инженерство, като наизустяват триста различни акронима на продукти от AWS. Но истинското облачно изчисление не е за наизустяване на каталози от доставчици: то е изградено върху единадесет фундаментални архитектурни примитива.

0:34 В този майсторски клас ще преминем през целия корпоративен план: от мащабиране и балансиране на натоварването до безсървърно, управлявано от събития развързване, йерархии за съхранение и облачни мрежи. Овладейте тези единадесет концепции и можете да проектирате всяка бек-енд система на AWS, GCP или Azure. Това е The Daily Diff, отвътре.

### - 01. Вертикално спрямо хоризонтално мащабиране

0:57 Концепция номер едно: Мащабиране. Когато приложението ви преживее ръст на трафика, имате два фундаментално различни начина да се справите с натоварването: вертикално мащабиране или хоризонтално мащабиране. Вертикалното мащабиране, или „scaling up“, означава да вземете вашата съществуваща машина и да добавите повече ресурси: надграждане от четири процесорни ядра до тридесет и две, или смяна на тридесет и два гигабайта RAM за сто двадесет и осем. Вертикалното мащабиране не изисква архитектурни промени: кодът ви

1:28 и базата данни остават абсолютно същите. Но удря жесток хардуерен таван. Нито една машина в света няма десет хиляди процесорни ядра, а висококачествените инстанции носят експоненциална ценова премия. Хоризонталното мащабиране, или „scaling out“, означава да поддържате сървърите си малки и на стандартна цена, но да работите с множество инстанции паралелно зад рутер. Ако една инстанция се срине, останалите възли поемат трафика с нулево време на прекъсване. Златното правило на хоризонталното мащабиране е

2:01 безстатовост: сървърите на приложението ви не могат да съхраняват потребителски сесии, качени файлове или състояние на локалните си дискове. Състоянието трябва да живее във външна база данни или кеш, позволявайки на всеки възел да обработва всяка потребителска заявка.

### - 02. Архитектура за балансиране на натоварването (L4 срещу L7 и проверки за изправност)

2:17 Концепция номер две: Балансиране на натоварването. Хоризонталното мащабиране звучи страхотно на хартия, но въвежда незабавен проблем: когато десет хиляди потребители посетят вашето домейн име, кой конкретен сървър получава техния трафик? Балансьорът на натоварването действа като обратен прокси, стоящ между публичния интернет и вашия частен бек-енд клъстер. Той приема входящи TCP или HTTP връзки и разпределя заявките между изправните ви инстанции.

2:47 Балансьорите на натоварването оперират на два основни мрежови слоя. Layer 4 Network Load Balancers работят на транспортния слой, маршрутизирайки сурови TCP и UDP пакети въз основа на IP адрес и порт с латентност от микросекунди и милиони заявки в секунда. Layer 7 Application Load Balancers инспектират HTTP протокола сами по себе си: четат пътища на URL, хедъри на заявки, бисквитки и HTTP методи. Това позволява маршрутизиране въз основа на път: изпращане на заявки за slash-api към вашия бек-енд клъстер и заявки за slash-static към

3:25 хранилище за обекти. От решаващо значение е, че балансьорите на натоварването извършват активни проверки за изправност. На всеки няколко секунди балансьорът изпраща пинг до крайна точка за изправност на всяка инстанция. Ако инстанция върне три последователни петстотин грешки или не успее да отговори, тя автоматично се изважда от пула с нулеви отхвърлени заявки.

### - 03. Автоматично мащабиране и еластичност

3:45 Концепция номер три: Автоматично мащабиране. Ако вашето уеб приложение се нуждае от два сървъра в три сутринта, но двадесет сървъра по време на обяд, ръчното щракане на бутони в облачната конзола е гарантиран път към прекъсвания и фалит. Автоматичното мащабиране внася динамична еластичност в хоризонталните сървърни пулове. Групата за автоматично мащабиране следи метрики за производителност като средно използване на процесора, мрежов вход/изход или дълбочина на опашката на натоварване. Когато средното натоварване на процесора пресече определен праг — да речем,

4:19 седемдесет процента за три последователни минути — автоматичният мащабатор автоматично стартира нови виртуални машини, регистрира ги с вашия балансьор на натоварването, и започва да маршрутизира трафик. Еднакво важно е мащабирането надолу: когато вълната от трафик отстъпи, автоматичният мащабатор прекратява излишните инстанции, така че да спрете да плащате за празен изчислителен капацитет. За да се предотврати „флапинг“ — при което сървърите бързо се създават и унищожават в безкраен цикъл на натоварване — облачните архитекти конфигурират периоди на изчакване. Концепция номер четири: Безсървърни.

### - 04. Безсървърни (FaaS и Firecracker MicroVMs)

4:53 Години наред маркетинговите екипи представяха безсървърните като магически код, работещ в небето. В действителност, безсървърните все още използват сървъри – но вие не ги притежавате, не ги пачвате и не плащате за тях, когато не работи код. С Function-as-a-Service като AWS Lambda или Google Cloud Functions, пишете самостоятелна функция за обработка. Когато възникне HTTP заявка, качване на S3 файл или промяна в база данни, облачната среда за изпълнение стартира временна

5:23 микро-виртуална машина като Firecracker за под пет милисекунди. Вашият код се изпълнява, връща отговор и се изключва. Ако никой не посети уебсайта ви в продължение на три месеца, сметката ви за изчислителни услуги е точно нула долара и нула цента. Ако милион потребители го посетят едновременно, доставчикът стартира милион едновременни микро-виртуални машини. Инженерните компромиси са реални: латентност при студен старт при стартиране на нови среди за изпълнение, твърдо ограничение от петнадесет минути за изпълнение на 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. Четирите стълба за облачно съхранение (S3, EBS, Бази данни и Redis)

8:16 изправни възли. Концепция номер седем: Йерархията на облачното съхранение. Начинаещите често третират облачното съхранение като един единствен кош, където изхвърляте файлове. В производствената архитектура съхранението е разделено на четири различни стълба въз основа на моделите на достъп и латентността. Първо е Обектно хранилище, като Amazon S3 или Google Cloud Storage. Достъпвате файлове чрез HTTP REST API с помощта на обикновени PUT и GET повиквания. То предлага безкраен хоризонтален капацитет на цена от два цента на гигабайт на месец,

8:49 което го прави идеално за видео, потребителски качвания, логове и резервни копия. Второ е Блоковото хранилище, като Amazon EBS. Това са виртуални твърди дискове, монтирани директно към конкретна виртуална машина чрез високоскоростни връзки. Те се форматират в стандартни файлови системи като ext4, поддържащи бърз произволен достъп за четене и запис, изискван от двигателите на бази данни. Трето са Управляваните бази данни: релационни двигатели като PostgreSQL на RDS, осигуряващи ACID транзакции и сложни съединения,

9:21 и NoSQL двигатели като DynamoDB, доставящи едноцифрена милисекундна латентност при мащабни операции. И четвърто са кешове в паметта като Redis. Четенето на данни от RAM отнема микросекунди, а не милисекунди. Кешовете стоят пред вашата база данни, предпазвайки я от повтарящ се трафик за четене и управлявайки променливи потребителски сесийни токени.

### - 08. Висока наличност и деветките (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 срещу отклонение на конзолата)

12:14 Концепция номер десет: Инфраструктура като код, или IaC. В ранните дни на облачните изчисления, инженерите влизаха в уеб конзолата за управление на AWS и ръчно кликваха, за да създават виртуални машини, да конфигурират подмрежи и да прикачват групи за сигурност. машини, конфигурират подмрежи и прикачват групи за сигурност. Индустрията нарича това ClickOps, и в производството, това е абсолютна катастрофа. Ръчните промени в конзолата нямат одиторски пътеки, нямат механизъм за връщане назад, и неизбежно причиняват разминаване в конфигурацията между тестовите и производствените среди. С инструменти за инфраструктура производствени среди. С инструменти за инфраструктура

12:48 като код като Terraform, OpenTofu, Pulumi или AWS CDK, вие дефинирате цялата си облачна архитектура в декларативни конфигурационни файлове, съхранявани в Git. цялата си облачна архитектура в декларативни конфигурационни файлове, съхранявани в Git. Всяка промяна на отворен порт или реплика на база данни минава през искане за изтегляне и партньорска проверка. Изпълнението на terraform plan преглежда точното API diff, преди нещо да бъде докоснато, а стартирането на идентична реплика на вашия производствен стек отнема четири минути вместо четири седмици. стек отнема четири минути вместо четири седмици.

### - 11. Облачни мрежи (VPC, подмрежи, NAT и групи за сигурност)

13:20 Концепция номер единадесет: Облачна мрежа и виртуални частни облаци. Когато разполагате сървъри в облака, те не стоят изложени на суровия публичен интернет. Те живеят в софтуерно дефинирана изолирана граница, наречена VPC. Вътре във вашия VPC, вие разпределяте частно IP адресно пространство като десет-точка-нула-точка-нула-точка-нула наклонена черта шестнадесет и го разделяте на публични и частни подмрежи. Публичната подмрежа има директен маршрут до интернет шлюз.

13:51 Тя съдържа публично достъпни активи като вашите балансьори на натоварване на приложения и NAT шлюзове. Тя е единствената част от вашата мрежа, която притежава публични IP адреси. Вашите сървъри за приложения и производствени бази данни живеят строго в частни подмрежи без публични IP адреси и нулеви входящи маршрути от интернет. Когато вашите бекенд сървъри трябва да изтеглят актуализации за сигурност, техният изходящ трафик преминава през NAT Gateway в публичната подмрежа. Около всеки екземпляр има групи за сигурност: състояние виртуални защитни стени, които налагат принципа на най-малко привилегии.

### - 12. Пълният корпоративен план и присъда

14:28 Вашата група за сигурност на база данни приема връзки само на порт 5432 строго от групата за сигурност на вашите сървъри за приложения, правейки външно проникване математически невъзможно. Когато се отдалечите, тези единадесет примитива се свързват в една кохезивна система. Вашият DNS маршрутизира до балансьор на натоварване в публична подмрежа, групите за автоматично мащабиране обработват пикове на трафика в множество зони на наличност, шините за събития разделят бекенд работници, а целият ви стек е разположен от Git с помощта на инфраструктура като код.

15:02 Присъдата от днешния майсторски клас: SHIP IT. Спрете да запаметявате стотици акроними за облачен маркетинг. Овладейте тези единадесет архитектурни модела, отделете състоянието си и изградете системи, които не могат да се провалят. Кажете ми кой облачен концепт ви причини най-голямо главоболие, когато за първи път започнахте да строите, в коментарите. И за да вземете пълния лист с архитектурни хитрини, абонирайте се за бюлетина на daily diff dot dev,

15:28 линкът е по-долу. И това е разликата за днес. Аз съм Нико от Axrisi. Сливайте отговорно.

## Източници

- [AWS Well-Architected Framework (Reliability & Performance Pillars)](https://aws.amazon.com/architecture/well-architected/) — aws.amazon.com
- [Kubernetes Architecture & Control Plane Concepts](https://kubernetes.io/docs/concepts/architecture/) — kubernetes.io
- [Martin Fowler: What is Event-Driven Architecture?](https://martinfowler.com/articles/201701-event-driven.html) — martinfowler.com
- [Amazon S3 Data Durability & Availability Technical Whitepaper](https://aws.amazon.com/s3/features/) — aws.amazon.com
- [HashiCorp: Declarative Infrastructure as Code with Terraform](https://www.terraform.io/) — www.terraform.io