Informatikë re e shpjeguar: 11 konceptet arkitekturore që duhet të dini (Masterclass 4K).

Çfarë mbulon kjo video

• - Muri i Arkitekturës dhe Plani Kryesor
• - 01. Shkallëzimi Vertikal vs. Horizontal
• - 02. Arkitektura e Balancimit të Ngarkesës (L4 vs. L7 & Kontrollet e Shëndetit)
• - 03. Auto-shkallëzimi dhe Elasticiteti
• - 04. Serverless (FaaS & Firecracker MicroVMs)

Transkript i përkthyer

Përkthyer nga tregimi origjinal në anglisht. Audio dhe titrat e disponueshme kontrollohen nga YouTube.

- Muri i Arkitekturës dhe Plani Kryesor

0:00 Çdo inxhinier softueri përfundimisht përballet me murin e arkitekturës së resë. Ti ndërton një aplikacion në laptopin tënd, e shtyn në prodhim, dhe në momentin që mbërrijnë përdoruesit e vërtetë, serverat dështojnë, lidhjet e bazës së të dhënave shterojnë, dhe fatura jote e AWS duket si një numër telefoni. Shumica e zhvilluesve përpiqen të zgjidhin inxhinierinë e resë duke memorizuar treqind akronime të ndryshme të produkteve të AWS. Por informatikë reale në re nuk ka të bëjë me memorizimin e katalogëve të shitësve: ajo është e ndërtuar mbi njëmbëdhjetë primitive themelore arkitekturore.

0:34 Në këtë masterclass, do të shqyrtojmë të gjithë planin e ndërmarrjes: nga shkallëzimi dhe balancimi i ngarkesës deri te serverless, shkëputja e bazuar në ngjarje, hierarkitë e ruajtjes dhe rrjetëzimi në re. Mësoni këto njëmbëdhjetë koncepte, dhe mund të projektoni çdo backend në AWS, GCP, ose Azure. Kjo është The Daily Diff, nën kapak.

- 01. Shkallëzimi Vertikal vs. Horizontal

0:57 Koncepti numër një: Shkallëzimi. Kur aplikacioni juaj përjeton rritje të trafikut, keni dy mënyra thelbësisht të ndryshme për të trajtuar ngarkesën: shkallëzimi vertikal, ose shkallëzimi horizontal. Shkallëzimi vertikal, ose "scaling up", do të thotë të marrësh makinën ekzistuese dhe të shtosh më shumë burime: të kalosh nga katër bërthama CPU në tridhjetë e dy, ose të zëvendësosh tridhjetë e dy gigabajt RAM me njëqind e njëzet e tetë. Shkallëzimi vertikal nuk kërkon ndryshime arkitekturore: kodi juaj

1:28 dhe baza e të dhënave mbeten saktësisht të njëjta. Por ai godet një tavan brutal hardueri. Asnjë makinë e vetme në botë nuk ka dhjetë mijë bërthama CPU, dhe instancat e nivelit të lartë mbartin një prime çmimi eksponenciale. Shkallëzimi horizontal, ose "scaling out", do të thotë të mbash serverat e tu të vegjël dhe me çmime të lira, por të ekzekutosh instanca të shumta paralelisht pas një ruteri. Nëse një instancë dështon, nyjet e mbetura thithin trafikun me kohë-ndalje zero. Rregulli i artë i shkallëzimit horizontal është

2:01 pa-shteti (statelessness): serverat tuaj të aplikacionit nuk mund të ruajnë sesionet e përdoruesve, skedarët e ngarkuar, ose gjendjen në disqet e tyre lokale. Gjendja duhet të jetë në një bazë të dhënash ose cache të jashtme, duke lejuar çdo nyje të trajtojë çdo kërkesë të përdoruesit.

- 02. Arkitektura e Balancimit të Ngarkesës (L4 vs. L7 & Kontrollet e Shëndetit)

2:17 Koncepti numër dy: Balancimi i Ngarkesës. Shkallëzimi horizontal tingëllon i shkëlqyer në letër, por ai sjell një problem të menjëhershëm: kur dhjetë mijë përdorues godasin emrin e domenit tuaj, cili server specifik merr trafikun e tyre? Një balancues ngarkese vepron si një proxy i kundërt i cili ndodhet midis internetit publik dhe klasterit tuaj privat backend. Ai pranon lidhje TCP ose HTTP hyrëse dhe shpërndan kërkesat nëpër instancat tuaja të shëndetshme.

2:47 Balancuesit e ngarkesës operojnë në dy shtresa kryesore të rrjetit. Balancuesit e Ngarkesës të Rrjetit të Shtresës 4 operojnë në shtresën e transportit, duke drejtuar paketa të papërpunuara TCP dhe UDP bazuar në adresën IP dhe portin me vonesë mikrosekondëshe dhe miliona kërkesa në sekondë. Balancuesit e Ngarkesës të Aplikacionit të Shtresës 7 inspektojnë protokollin HTTP vetë: duke lexuar shtigjet e URL-së, titujt e kërkesave, "cookies", dhe metodat HTTP. Kjo mundëson drejtimin e bazuar në shteg: dërgimin e kërkesave slash-api në klasterin tuaj backend dhe kërkesat slash-static në një

3:25 depo objektesh. Thelbësisht, balancuesit e ngarkesës kryejnë kontrolle aktive të shëndetit. Çdo pak sekonda, balancuesi pingon një pikë fundore shëndetësore në çdo instancë. Nëse një instancë hedh tre gabime të njëpasnjëshme pesëqind ose nuk arrin të përgjigjet, ajo nxirret automatikisht nga pishina me zero kërkesa të rëna.

- 03. Auto-shkallëzimi dhe Elasticiteti

3:45 Koncepti numër tre: Auto-shkallëzimi. Nëse aplikacioni juaj i uebit ka nevojë për dy servera në tre të mëngjesit, por njëzet servera gjatë një lëshimi në mesditë, klikimi manual i butonave në konsolën e resë është një rrugë e garantuar drejt kohës së mosfunksionimit dhe falimentimit. Auto-shkallëzimi sjell elasticitet dinamik në pishinat e serverëve horizontalë. Një Grup Auto-Shkallëzimi monitoron metrika të performancës si mesatarja e përdorimit të CPU-së, I-O të rrjetit, ose thellësinë e radhës së pasme. Kur mesatarja e CPU kalon një prag të caktuar — themi,

4:19 shtatëdhjetë për qind për tre minuta të njëpasnjëshme — auto-shkallëzuesi automatikisht lëshon makina virtuale të reja, i regjistron ato me balancuesin tuaj të ngarkesës, dhe fillon drejtimin e trafikut. Po aq i rëndësishëm është shkallëzimi brenda: kur vala e trafikut zvogëlohet, auto-shkallëzuesi ndërpret instancat e tepërta në mënyrë që të ndaloni pagesat për llogaritjen e papunë. Për të parandaluar flapingun — ku serverat krijohen dhe shkatërrohen shpejt në një cikël të pafund shkatërrimi — arkitektët e resë konfigurojnë periudha ftohjeje. Koncepti numër katër: Serverless.

- 04. Serverless (FaaS & Firecracker MicroVMs)

4:53 Për vite me radhë, ekipet e marketingut e prezantuan serverless si kod magjik që ekzekutohej në qiell. Në realitet, serverless ende përdor servera — por ti nuk i zotëron, nuk i rregullon, ose nuk i paguan ato kur nuk ekzekutohet asnjë kod. Me Funksion-si-Shërbim si AWS Lambda ose Google Cloud Functions, ju shkruani një funksion përgjegjës i pavarur. Kur ndodh një kërkesë HTTP, ngarkim skedari S3, ose ndryshim baze të dhënash, kohëzgjatja e resë nis një makinë virtuale mikro-efemere

5:23 si Firecracker në më pak se pesë milisekonda. Kodi juaj ekzekutohet, kthen një përgjigje, dhe fiket. Nëse askush nuk viziton faqen tuaj të internetit për tre muaj, fatura juaj e llogaritjes është saktësisht zero dollarë dhe zero cent. Nëse një milion përdorues e godasin njëkohësisht, ofruesi lëshon një milion microVM-s paralele. Kompromiset inxhinierike janë reale: vonesë e fillimit të ftohtë kur nisni kohëzgjatje të freskëta, një kufi i fortë ekzekutimi prej pesëmbëdhjetë minutash në Lambda, dhe pa-shtetësi e rreptë.

5:55 Serverless është i pakrahasueshëm për tubacionet e ngjarjeve dhe API-të sporadike, por i dobët për WebSockets të qëndrueshëm ose ekzekutime trajnimi shumë-orëshe.

- 05. Arkitektura e Bazuar në Ngjarje (EDA & Shkëputja)

6:05 Koncepti numër pesë: Arkitektura e Bazuar në Ngjarje, ose EDA. Në arkitekturat tradicionale, shërbimet komunikojnë sinkronisht. Shërbimi juaj i pagesës thërret pagesën, pagesa thërret inventarin, inventari thërret mashtrimin, dhe mashtrimi thërret emailin. Kjo krijon kaskadën sinkrone të shkatërrimit. Nëse ofruesi i tretë i emailit përjeton një problem rrjeti dhe i duhen dhjetë sekonda për t'u përgjigjur, e gjithë kërkesa e pagesës së klientit tuaj skadon me një gabim. Në një arkitekturë të bazuar në ngjarje, shërbimet janë plotësisht të shkëputura.

6:37 Kur një klient klikon butonin "blej", shërbimi i pagesës nuk thërret shërbimet e poshtme. Ai thjesht publikon një ngjarje të quajtur "OrderPlaced" në një Autobus Ngjarjesh qendror si Amazon EventBridge ose një temë SNS. Pagesa përfundon në pesëdhjetë milisekonda. Punëtorët e poshtëm për pagesën, zbritjen e inventarit dhe faturat e emailit tërheqin mesazhet në mënyrë të pavarur nga radhët e tyre të dedikuara SQS. Nëse shërbimi i emailit ndalon për një orë, mesazhet presin në mënyrë të sigurtë në radhë pa asnjë porosi të humbur.

- 06. Orkestrimi i Kontejnerëve (Docker & Kubernetes)

7:13 Koncepti numër gjashtë: Orkestrimi i Kontejnerëve. Docker zgjidhi paketimin: ai mbështjell kodin tuaj të aplikacionit, bibliotekat e sistemit, konfigurimin dhe mjedisin e ekzekutimit në një imazh të pandryshueshëm që ekzekutohet identikisht në MacBook tuaj dhe në re. Por paketimi i një kontejneri është i lehtë. Ekzekutimi i pesëqind kontejnerëve në pesëdhjetë makina virtuale fizike është pika ku inxhinieria dështon. Kjo është arsyeja pse ekzistojnë orkestruesit e kontejnerëve si Kubernetes dhe AWS ECS.

7:41 Një orkestrues ofron një plan kontrolli: një server API, një depozitë gjendjeje etcd dhe një orarues inteligjent. Ju deklaroni gjendjen tuaj të dëshiruar: dua dhjetë replika të shërbimit tim të autentifikimit me dy gigabajt RAM secila. Oraruesi inspekton klasterin, vendos "pods" në nyje me memorie të lirë, konfiguron rrjetëzimin e brendshëm dhe pajton vazhdimisht realitetin. Nëse një nyje vuan një dështim harduerik, Kubernetes detekton humbjen dhe ri-planifikon menjëherë të gjitha "pods" e zhvendosura në

- 07. 4 Shtyllat e Ruajtjes në Re (S3, EBS, DBs & Redis)

8:16 nyje të shëndetshme. Koncepti numër shtatë: Hierarkia e Ruajtjes në Re. Fillestarët shpesh e trajtojnë ruajtjen në re si një kovë të vetme ku hidhen skedarët. Në arkitekturën e prodhimit, ruajtja ndahet në katër shtyllash të veçanta bazuar në modelet e aksesit dhe vonesën. Së pari është Ruajtja e Objekteve, si Amazon S3 ose Google Cloud Storage. Ju aksesoni skedarët mbi API-të HTTP REST duke përdorur thirrje të thjeshta PUT dhe GET. Ofron kapacitet horizontal të pafund në dy cent për gigabajt në muaj,

8:49 duke e bërë atë ideal për video, ngarkime nga përdoruesit, regjistra dhe kopje rezervë. Së dyti është Ruajtja në Bllok, si Amazon EBS. Këta janë hard disqe virtuale të montuar direkt në një makinë virtuale specifike përmes lidhjeve me shpejtësi të lartë. Ata formatizohen në sisteme standarde skedarësh si ext4, duke mbështetur aksesin e shpejtë të leximit dhe shkrimit të rastësishëm të kërkuar nga motorët e bazave të të dhënave. Së treti janë Baza e të Dhënave të Menaxhuara: motorë relacionale si PostgreSQL në RDS që ofrojnë transaksione ACID dhe bashkime komplekse,

9:21 dhe motorë NoSQL si DynamoDB që japin vonesë milisekondëshe me një shifër në shkallë masive. Dhe së katërti janë Cache-të në Memorie si Redis. Leximi i të dhënave nga RAM-i kërkon mikrosekonda dhe jo milisekonda. Cache-të qëndrojnë përpara bazës tuaj të të dhënave, duke e mbrojtur atë nga trafiku i përsëritur i leximit dhe duke menaxhuar shenjat e sesioneve të përdoruesve të paqëndrueshme.

- 08. Disponueshmëria e Lartë dhe Nëntëshat (Dështimi i Shumë-AZ)

9:44 Koncepti numër tetë: Disponueshmëria e Lartë, ose HA. Disponueshmëria i përgjigjet një pyetjeje: çfarë përqindje të kohës aplikacioni juaj është operacional dhe i arritshëm nga përdoruesit? Në kontratat e ndërmarrjeve, disponueshmëria matet në nëntësha. Dy nëntësha, ose nëntëdhjetë e nëntë për qind disponueshmëri, lejon mbi tre e gjysmë ditë ndërprerje çdo vit. Katër nëntësha ul kohën e ndërprerjes së lejuar në pesëdhjetë e dy minuta, dhe pesë nëntësha lejojnë vetëm pesë minuta kohë të përgjithshme ndërprerjeje në

10:15 vit. Për të arritur disponueshmëri të lartë, duhet të eliminoni pikat e vetme të dështimit në të gjithë fushat e defekteve. Në re, kjo do të thotë të vendosni nëpër Zona të Shumëfishta të Disponueshmërisë. Një Zonë Disponueshmërie nuk është një raft i vetëm: ajo është një ose më shumë qendra të dhënash fizike të ndryshme me milje larg me energji dhe ftohje të pavarur. Duke ekzekutuar instanca aktive në Zonën A dhe Zonën B me replikim sinkron të bazës së të dhënave, një goditje rrufeje ose prerje e fibrës që shkakton rënien e një objekti fizik të tërë rezulton në një kalim automatik në rezervë.

10:50 në tridhjetë sekonda pa ndërhyrje njerëzore.

- 09. Qëndrueshmëria vs. Disponueshmëria (Pse 11 Nëntëshat nuk janë Koha e Punës)

10:53 Koncepti numër nëntë: Qëndrueshmëria kundrejt disponueshmërisë. Ky është kurthi i vetëm konceptual më i zakonshëm në arkitekturën e cloud-it intervista. Inxhinierët shpesh i përdorin fjalët në mënyrë të ndërsjellë, por ato matin veti krejtësisht të ndryshme. Disponueshmëria mat kohën e funksionimit: mund të bëj një thirrje API për të lexuar ose shkruar të dhënat e mia pikërisht tani? Qëndrueshmëria mat ruajtjen: a do të mbijetojnë të dhënat e mia pa dëmtim të përhershëm, korrupsion, ose shkatërrim gjatë dhjetë vjetëve?

11:24 Shikoni Amazon S3 Standard. Marrëveshja e Nivelit të Shërbimit ofron nëntëdhjetë e nëntë pikë nëntë përqind disponueshmëri, e cila lejon afërsisht dyzet e tre minuta ndërprerje çdo muaj ku një kërkesë API mund të kthejë një gabim pesëqind. Por S3 premton njëmbëdhjetë nënta të qëndrueshmërisë: nëntëdhjetë e nëntë pikë nëntë nëntë nëntë nëntë nëntë nëntë nëntë nëntë nëntë përqind. Nëse ruani dhjetë milionë skedarë në S3, mund të prisni statistikisht të humbni një

11:56 mesatarisht një skedar çdo dhjetë mijë vjet. S3 e arrin këtë duke koduar objektet me fshirje dhe duke replikuar blloqet në të paktën të paktën tre qendra të dhënash të ndara gjeografikisht. Gjatë një ndërprerjeje të madhe të rrjetit rajonal, S3 mund të jetë përkohësisht i padisponueshëm, por të dhënat tuaja nuk shkatërrohen kurrë.

- 10. Infrastruktura si Kod (Terraform vs. Rrjedha e Konsolës)

12:14 Koncepti numër dhjetë: Infrastruktura si Kod, ose IaC. Në ditët e para të cloud computing, inxhinierët hynin në AWS konsolën e menaxhimit të uebit dhe klikonin manualisht për të krijuar makina virtuale, konfiguroni nënrrjetet dhe bashkëngjitni grupe sigurie. Industria e quan këtë ClickOps, dhe në prodhim, është një fatkeqësi absolute. Ndryshimet manuale të konsolës nuk kanë një gjurmë auditi, asnjë mekanizëm rikthimi, dhe në mënyrë të pashmangshme shkaktojnë rrëshqitje konfigurimi midis mjediseve të staging dhe production. Me Infrastrukturën si mjete Kodi si Terraform,

12:48 OpenTofu, Pulumi, ose AWS CDK, ju përcaktoni të gjithë arkitekturën tuaj të cloud-it të gjithë arkitekturën tuaj të cloud-it në skedarë konfigurimi deklarativ të ruajtur në Git. Çdo ndryshim në një port të hapur ose kopje të bazës së të dhënave kalon nëpërmjet një kërkese tërheqjeje dhe rishikimi nga kolegët. Çdo ndryshim në një port të hapur ose një replikë baze të dhënash kalon nëpër një kërkesë tërheqjeje dhe rishikim nga kolegët. Ekzekutimi i planit të Terraform-it parashikon diferencën e saktë të API-t përpara se të preket diçka, dhe ngritja e një replike identike të stack-ut tuaj të prodhimit zgjat katër minuta në vend të katër javëve.

- 11. Rrjetëzimi në Re (VPC, Nën-rrjetat, NAT & Grupet e Sigurisë)

13:20 Koncepti numër njëmbëdhjetë: Rrjetet e Cloud-it dhe Rrjetet Private Virtuale. Kur vendosni servera në cloud, ata nuk janë të ekspozuar në internetin publik të papërpunuar. Ata jetojnë brenda një kufiri të izoluar të përcaktuar nga softueri e quajtur VPC. Brenda VPC-së tuaj, ju caktoni një hapësirë adresash IP private si dhjetë-pikë-zero-pikë-zero-pikë-zero slash gjashtëmbëdhjetë, dhe e ndani atë në nënrrjete publike dhe private. Një nënrrjet publik ka një rrugë direkte për në një Internet Gateway.

13:51 Ai mban asete të drejtuara nga publiku si Balancuesit e Ngarkesës së Aplikacionit dhe Portat NAT. Është e vetmja pjesë e rrjetit tuaj që zotëron adresa IP publike. Serverat e aplikacionit tuaj dhe bazat e të dhënave të prodhimit jetojnë rreptësisht në nënrrjete private pa IP publike dhe pa rrugë hyrëse nga interneti. Kur serverat tuaj backend duhet të shkarkojnë përditësime sigurie, trafiku i tyre dalës kalon përmes Portës NAT në nënrrjetin publik. Rreth çdo instance janë Grupet e Sigurisë: firewall virtualë të gjendjes që zbatojnë parimin e privilegjit minimal.

- 12. Plani i Plotë i Ndërmarrjes dhe Vendimi

14:28 Grupi juaj i sigurisë së bazës së të dhënave pranon lidhje vetëm në portën 5432 rreptësisht nga grupi i sigurisë i serverave tuaj të aplikacionit, duke e bërë depërtimin e jashtëm matematikisht të pamundur. Kur zmadhoni, këto njëmbëdhjetë primitive lidhen në një sistem koheziv. DNS-ja juaj rrugëzohet drejt një Balancuesi Ngarkese në një nënrrjet publik, grupet e shkallëzimit automatik trajtojnë rritjet e trafikut nëpër Zona të Shumëfishta Disponueshmërie, busët e ngjarjeve shkëputin punëtorët e backend-it, dhe i gjithë stack-u juaj është i vendosur nga Git duke përdorur Infrastrukturën si Kod.

15:02 Vendimi i masterklasës së sotme: SHIP IT. Ndaloni së mësuari qindra akronime të marketingut të cloud-it. Zotëroni këto njëmbëdhjetë modele arkitekture, shkëputni gjendjen tuaj, dhe ndërtoni sisteme që nuk mund të dështojnë. Më tregoni cili koncept i cloud-it ju dha dhimbjen më të madhe të kokës kur filluat ndërtimin në komente. Dhe për të marrë fletën e plotë të hileve të arkitekturës, abonohuni në buletinin në the daily diff dot dev,

15:28 linku më poshtë. Dhe kjo është diferenca për sot. Unë jam Niko nga Axrisi. Bashkohuni me përgjegjësi.

Burimet

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