Wolkrekenaarkunde verduidelik: die 11 argitektuurkonsepte wat jy moet ken (4K Meesterklas).

Wat hierdie video dek

• - Die Argitektuurmuur & Meesterbloudruk
• - 01. Vertikale vs. Horisontale Skaal
• - 02. Lasbalanseringsargitektuur (L4 vs. L7 & Gesondheidskontroles)
• - 03. Outoskaal & Elastisiteit
• - 04. Bedienerloos (FaaS & Firecracker MicroVMs)

Vertaalde transkripsie

Vertaal uit die oorspronklike Engelse vertelling. Beskikbare klank en onderskrifte word deur YouTube beheer.

- Die Argitektuurmuur & Meesterbloudruk

0:00 Elke sagteware-ingenieur staan uiteindelik voor die wolkkargitektuurmuur. Jy bou 'n toepassing op jou skootrekenaar, stoot dit na produksie, en die oomblik wat regte gebruikers opdaag, val bedieners in duie, databasisverbindings raak op, en jou AWS-rekening lyk soos 'n telefoon- nommer. Die meeste ontwikkelaars probeer wolk-ingenieurswese oplos deur driehonderd verskillende AWS-produk-akronieme te memoriseer. Maar regte wolkrekenaarkunde gaan nie oor die memorisering van verskafferprodukte nie: dit is gebou op elf fundamentele argitektoniese primitiewe.

0:34 In hierdie meesterklas sal ons deur die hele ondernemingsbloudruk stap: van skaal en lasbalansering tot bedienerloos, gebeurtenisgedrewe ontkoppeling, bergingshiërargieë, en wolknetwerke. Bemeester hierdie elf konsepte, en jy kan enige agterkant op AWS, GCP, of Azure ontwerp. Dit is The Daily Diff, onder die enjinkap.

- 01. Vertikale vs. Horisontale Skaal

0:57 Konsep nommer een: Skaal. Wanneer jou toepassing verkeersgroei ervaar, het jy twee fundamenteel verskillende maniere om die las te hanteer: vertikale skaal, of horisontale skaal. Vertikale skaal, of opskaal, beteken om jou bestaande masjien te neem en meer hulpbronne by te voeg: opgradering van vier SVE-kerne na twee-en-dertig, of die vervanging van twee-en-dertig gigagrepe RAM vir 'n honderd-agt-en-twintig. Vertikale skaal vereis geen argitektoniese veranderinge nie: jou kode

1:28 en databasis bly presies dieselfde. Maar dit tref 'n brutale hardewareplafond. Geen enkele masjien in die wêreld het tienduisend SVE-kerne nie, en top-vlak instansies dra 'n eksponensiële prys-premie. Horisontale skaal, of uitskaal, beteken om jou bedieners klein en goedkoop te hou, maar om verskeie instansies parallel agter 'n roeteerder te laat loop. As een instansie in duie stort, absorbeer die oorblywende nodusse die verkeer met nul stilstand. Die goue reël van horisontale skaal is

2:01 staatloosheid: jou toepassingsbedieners kan nie gebruikersessies, opgelaaide lêers, of toestand op hul plaaslike skywe stoor nie. Toestand moet in 'n eksterne databasis of kas bestaan, wat enige node toelaat om enige gebruikerversoek te hanteer.

- 02. Lasbalanseringsargitektuur (L4 vs. L7 & Gesondheidskontroles)

2:17 Konsep nommer twee: Lasbalansering. Horisontale skaal klink goed op papier, maar dit bring 'n onmiddellike probleem mee: wanneer tienduisend gebruikers jou domeinnaam tref, watter spesifieke bediener ontvang hul verkeer? ’n Lasbalanseerder dien as ’n omgekeerde instaanbediener wat tussen die publieke internet en jou private agterkant-groep sit. Dit aanvaar inkomende TCP- of HTTP-verbindings en versprei versoeke oor jou gesonde instansies.

2:47 Lasbalanseerders werk op twee primêre netwerklagings. Laag 4 Netwerk-lasbalanseerders werk op die transportlaag, roetering van rou TCP- en UDP-pakkette gebaseer op IP-adres en poort met mikrosekonde latensie en miljoene versoeke per sekonde. Laag 7 Toepassings-lasbalanseerders inspekteer die HTTP-protokol self: lees URL-paaie, versoekopskrifte, koekies, en HTTP- metodes. Dit maak padgebaseerde roetering moontlik: stuur slash-api- versoeke na jou agterkant-groep en slash-static versoeke na 'n

3:25 objekberging. Belangrik, lasbalanseerders doen aktiewe gesondheids- kontroles. Elke paar sekondes ping die balanseerder 'n gesondheidspunt op elke instansie. As 'n instansie drie opeenvolgende vyfhonderd foute gooi of versuim om te reageer, word dit outomaties uit die groep verwyder met nul gedaalde versoeke.

- 03. Outoskaal & Elastisiteit

3:45 Konsep nommer drie: Outoskaal. As jou webtoepassing om drie uur in die oggend twee bedieners benodig, maar twintig bedieners tydens 'n middagbekendstelling, is die handmatige klik van knoppies in die wolk-konsole 'n gewaarborgde pad na stilstand en bankrotskap. Outoskaal bring dinamiese elastisiteit na horisontale bedienerpoele. 'n Outoskaalgroep monitor prestasie-metrieke soos gemiddelde SVE-benutting, netwerk I-O, of tou-agterstand diepte. Wanneer die gemiddelde SVE 'n gedefinieerde drempel oorskry - sê,

4:19 sewentig persent vir drie opeenvolgende minute - loods die outoskaler outomaties nuwe virtuele masjiene, registreer hulle by jou lasbalanseerder, en begin verkeer roeteer. Ewe belangrik is inskaal: wanneer die verkeersgolf terugtrek, beëindig die outoskaler oortollige instansies sodat jy ophou betaal vir ledige rekenaarkrag. Om te voorkom dat bedieners vinnig geskep en vernietig word in 'n eindelose heen-en-weer-lus - stel wolkargitekte afkoelperiodes in. Konsep nommer vier: Bedienerloos.

- 04. Bedienerloos (FaaS & Firecracker MicroVMs)

4:53 Vir jare het bemarkingspanne bedienerloos as towerkode wat in die lug loop, voorgestel. In werklikheid gebruik bedienerloos steeds bedieners - maar jy besit, lap, of betaal nie vir hulle wanneer geen kode loop nie. Met Funksie-as-diens soos AWS Lambda of Google Cloud Functions, skryf jy 'n selfstandige hanteerfunksie. Wanneer 'n HTTP-versoek, S3-lêeroplaai, of databasisverandering plaasvind, begin die wolk-looptyd 'n efemere

5:23 mikro-virtuele-masjien soos Firecracker in minder as vyf millisekondes. Jou kode voer uit, gee 'n antwoord terug, en sluit af. As niemand jou webwerf vir drie maande besoek nie, is jou rekenaarkoste presies nul dollar en nul sent. As 'n miljoen gebruikers dit gelyktydig tref, stel die verskaffer 'n miljoen gelyktydige mikro-VM's op. Die ingenieurshandelings is werklik: koue begin- latensie wanneer nuwe looptye opgestel word, 'n harde vyftien-minuut uitvoeringstydperk op Lambda, en streng staatloosheid.

5:55 Bedienerloos is onverbeterlik vir gebeurtenispyplyne en sporadies API's, maar swak vir aanhoudende WebSockets of multi-uur oefensessies.

- 05. Gebeurtenisgedrewe Argitektuur (EDA & Ontkoppeling)

6:05 Konsep nommer vyf: Gebeurtenisgedrewe Argitektuur, of EDA. In tradisionele argitekture kommunikeer dienste sinchroon. Jou uitklokdiens roep betaling, betaling roep voorraad, voorraad roep bedrog, en bedrog roep e-pos. Dit skep die sinchroniese kaskade van ondergang. As die derdeparty-e-posverskaffer 'n netwerkhikkie ervaar en tien sekondes neem om te reageer, loop jou klant se hele uitklokversoek uit met 'n fout. In 'n gebeurtenisgedrewe argitektuur is dienste heeltemal ontkoppel.

6:37 Wanneer 'n klant op koop klik, roep die uitklokdiens nie stroomaf dienste nie. Dit publiseer bloot 'n gebeurtenis genaamd OrderPlaced na 'n sentrale Gebeurtenisbus soos Amazon EventBridge of 'n SNS-onderwerp. Die uitklok voltooi in vyftig millisekondes. Stroomaf werkers vir betaling, voorraadvermindering, en e-pos kwitansies haal boodskappe onafhanklik uit hul eie toegewyde SQS-toue. As die e-posdiens vir 'n uur afgaan, wag boodskappe veilig gebuffer in die tou sonder 'n enkele gedaalde bestelling.

- 06. Houerorkestrasie (Docker & Kubernetes)

7:13 Konsep nommer ses: Houerorkestrasie. Docker het verpakking opgelos: dit omvou jou toepassingskode, stelselbiblioteke, konfigurasie, en looptyd in 'n onveranderlike beeld wat identies op jou MacBook en in die wolk loop. Maar die verpakking van 'n houer is maklik. Die loop van vyfhonderd houers oor vyftig fisiese virtuele masjiene is waar ingenieurswese in duie stort. Daarom bestaan houerorkestreerders soos Kubernetes en AWS ECS.

7:41 'n Orkestreerder verskaf 'n beheerpaneel: 'n API-bediener, 'n etcd-toestandsberging, en 'n intelligente skeduleerder. Jy verklaar jou verlangde toestand: ek wil tien replikas van my outo- diens met twee gigagrepe RAM elk hê. Die skeduleerder inspekteer die groep, plaas pods op nodusse met vrye geheue, konfigureer interne netwerke, en versoen voortdurend die werklikheid. As 'n nodus 'n hardewarefout ly, bespeur Kubernetes die verlies en herskeduleer onmiddellik alle verplaasde pods na

- 07. Die 4 Wolkbergingspilare (S3, EBS, DBs & Redis)

8:16 gesonde nodusse. Konsep nommer sewe: Die Wolkberginghiërargie. Beginners behandel wolkberging dikwels as 'n enkele emmer waar jy lêers stort. In produksie-argitektuur is berging verdeel in vier afsonderlike pilare gebaseer op toegangspatrone en latensie. Eerstens is Objekberging, soos Amazon S3 of Google Cloud Berging. Jy kry toegang tot lêers oor HTTP REST API's deur gebruik te maak van eenvoudige PUT- en GET-oproepe. Dit bied oneindige horisontale kapasiteit teen twee sent per gigagreep per maand,

8:49 wat dit ideaal maak vir video, gebruikeroplaaie, logs, en rugsteune. Tweedens is Blokberging, soos Amazon EBS. Dit is virtuele hardeskywe wat direk aan 'n spesifieke virtuele masjien oor hoëspoed-verbindings gemonteer is. Hulle formateer in standaard lêerstelsels soos ext4, wat vinnige ewekansige lees- en skryftoegang vereis deur databasis- enjins ondersteun. Derdens is Bestuurde Databasisse: relasionele enjins soos PostgreSQL op RDS wat ACID-transaksies en komplekse koppelings verskaf,

9:21 en NoSQL-enjins soos DynamoDB wat enkel-syfer millisekonde latensie op massiewe skaal lewer. En vierdens is In-geheue kase soos Redis. Die lees van data uit RAM neem mikrosekondes eerder as millisekondes. Kase sit voor jou databasis, beskerm dit teen herhaalde leestoegang en bestuur vlugtige gebruikeressietokens.

- 08. Hoë Beskikbaarheid & Die Nege (Multi-AZ Failover)

9:44 Konsep nommer agt: Hoë Beskikbaarheid, of HA. Beskikbaarheid beantwoord een vraag: watter persentasie van die tyd is jou toepassing operasioneel en bereikbaar vir gebruikers? In ondernemingskontrakte word beskikbaarheid in nege gemeet. Twee nege, of nege-en-negentig persent beskikbaarheid, laat meer as drie en 'n 'n half dae stilstand elke jaar toe. Vier nege verlaag toegelate stilstand tot twee-en-vyftig minute, en vyf nege laat skaars vyf minute totale stilstand per

10:15 jaar toe. Om hoë beskikbaarheid te bereik, moet jy enkelpunte van mislukking oor foutdomeine uitskakel. In die wolk beteken dit om oor verskeie Beskikbaarheidsones te ontplooi. 'n Beskikbaarheidsone is nie 'n enkele rek nie: dit is een of meer afsonderlike fisiese datasentrums kilometers uitmekaar met onafhanklike krag en verkoeling. Deur aktiewe instansies in Sone A en Sone B te bestuur met sinchroniese databasisreplikasie, lei 'n weerligslag of veselkabelbreuk wat 'n hele fisiese fasiliteit afneem, tot 'n outomatiese oorrol.

10:50 oor dertig sekondes met geen menslike ingryping nie.

- 09. Duursaamheid vs. Beskikbaarheid (Waarom 11 Nege Nie Uptime Is Nie)

10:53 Konsep nommer nege: Duursaamheid teenoor Beskikbaarheid. Dit is die enkele mees algemene konseptuele strik in wolkargitektuur onderhoude. Ingenieurs gebruik gereeld die woorde uitruilbaar, maar hulle meet heeltemal verskillende eienskappe. Beskikbaarheid meet uptyd: kan ek nou 'n API-oproep maak om my data te lees of te skryf? Duursaamheid meet bewaring: sal my data oor tien jaar oorleef sonder permanente bisverrotting, korrupsie of vernietiging?

11:24 Kyk na Amazon S3 Standaard. Sy Diensvlakooreenkoms bied nege-en-negentig komma nege persent beskikbaarheid, wat ongeveer drie-en-veertig minute stilstand elke maand toelaat waar 'n API-versoek 'n vyf-honderd-fout kan terugstuur. Maar S3 beloof elf neges van duursaamheid: nege-en-negentig komma nege nege nege nege nege nege nege nege nege persent. As jy tien miljoen lêers in S3 stoor, kan jy statisties verwag om 'n

11:56 gemiddeld van een lêer elke tienduisend jaar te verloor. S3 bereik dit deur objekte met uitwissingskodes te enkripteer en stukke te repliseer oor ten minste drie geografies geskeide datafasiliteite. Tydens 'n groot streeksnetwerkonderbreking mag S3 tydelik onbeskikbaar wees, maar jou data word nooit vernietig nie.

- 10. Infrastruktuur as Kode (Terraform vs. Konsole Drift)

12:14 Konsep nommer tien: Infrastruktuur as Kode, of IaC. In die vroeë dae van wolkrekenaarkunde het ingenieurs by die AWS webbestuurskonsole ingeteken en handmatig geklik om virtuele masjiene te skep, subnette te konfigureer en sekuriteitsgroepe aan te heg. Die bedryf noem dit ClickOps, en in produksie is dit 'n absolute ramp. Handmatige konsol-veranderinge het geen ouditspoor, geen terugrol- meganisme, en veroorsaak onvermydelik konfigurasieafwyking tussen toets- en produksie-omgewings. Met Infrastruktuur

12:48 as Kode-gereedskap soos Terraform, OpenTofu, Pulumi, of AWS CDK, definieer jy jou hele wolkargitektuur in deklaratiewe konfigurasielêers wat in Git gestoor is. Elke verandering aan 'n oop poort of databasisreplika gaan deur 'n trekaanvraag en ewekniebeoordeling. Die uitvoering van terraform plan voorskou die presiese API-verskil voordat enigiets aangeraak word, en die opstel van 'n identiese replika van jou produksie stapel neem vier minute in plaas van vier weke.

- 11. Wolknetwerk (VPC, Subnette, NAT & Sekuriteitsgroepe)

13:20 Konsep nommer elf: Wolknetwerke en Virtuele Privaat Wolke. Wanneer jy bedieners na die wolk ontplooi, sit hulle nie blootgestel aan die rou openbare internet nie. Hulle leef binne 'n sagteware-gedefinieerde geïsoleerde grens wat 'n VPC genoem word. Binne jou VPC ken jy 'n privaat IP-adresruimte toe soos tien-punt-nul-punt-nul-punt-nul skuinsstreep sestien, en verdeel dit in openbare en private subnette. 'n Openbare subnet het 'n direkte roete na 'n Internetpoort.

13:51 Dit bevat openbare bates soos jou Toepassingslasbalanseerders en NAT Poorte. Dit is die enigste deel van jou netwerk wat openbare IP- adresse besit. Jou toepassingsbedieners en produksie-databasisse leef streng in private subnette met geen openbare IP's en geen inkomende roetes vanaf die internet nie. Wanneer jou agterkantbedieners sekuriteitsopdaterings moet aflaai, roeteer hul uitgaande verkeer deur die NAT-poort in die openbare subnet. Rondom elke instansie is Sekuriteitsgroepe: statusbewuste virtuele brandmure wat die beginsel van minste voorreg afdwing.

- 12. Die Volledige Ondernemingsbloudruk & Oordeel

14:28 Jou databasis-sekuriteitsgroep aanvaar slegs verbindings op poort 5432 streng vanaf die sekuriteitsgroep van jou toepassingsbedieners, wat buite-penetrasie wiskundig onmoontlik maak. Wanneer jy uitzoem, verbind hierdie elf primitiewe in een samehangende stelsel. Jou DNS roeteer na 'n Lasbalanseerder in 'n openbare subnet, autoscaling-groepe hanteer verkeersvloede oor verskeie Beskikbaarheidsones, gebeurtenisbusse ontkoppel agterkantwerkers, en jou hele stapel word ontplooi vanaf Git met behulp van Infrastruktuur as Kode.

15:02 Vandag se meesterklas-uitspraak: SHIP IT. Hou op om honderde wolkbemarkingsakronieme te memoriseer. Bemeester hierdie elf argitektuurpatrone, ontkoppel jou toestand, en bou stelsels wat nie kan misluk nie. Vertel my watter wolkkonsep jou die grootste hoofpyn gegee het toe jy eers begin het om in die kommentaar te bou. En om die volledige argitektuur-blad te kry, teken in op die nuusbrief by the daily diff dot dev,

15:28 skakel hieronder. En dit is die verskil vir vandag. Ek is Niko van Axrisi. Voeg verantwoordelik saam.

Bronne

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