Në këtë artikull janë mbledhur disa modele të zakonshme që ndihmojnë inxhinierët të punojnë me shërbime të mëdha, të cilat kërkohen nga miliona përdorues.

Sipas përvojës së autorit, kjo nuk është një listë e plotë, por vërtet këshilla efektive. Le të fillojmë.

Përkthyer me mbështetje nga Zgjidhjet Cloud të Mail.ru.

Niveli fillestar

Masat e listuara më poshtë janë relativisht të lehta për t'u zbatuar, por ofrojnë një kthim të lartë. Nëse nuk i keni ndërmarrë më parë, do të befasoheni nga përmirësimet e dukshme.

Infrastruktura si kod

Pjesa e parë e këshillave është që të implementoni infrastrukturën si kod. Kjo do të thotë se duhet të keni një mënyrë programore për të implementuar tërë infrastrukturën. Duket kompleks, por në të vërtetë po flasim për kodin e mëposhtëm:

Implementimi i 100 makinave virtuale

me Ubuntu

2 GB RAM në secilën

do të kenë këtë kod

me këto parametra

Mund të monitoroni ndryshimet në infrastrukturë dhe të ktheheni shpejt në to duke përdorur një sistem menaxhimi të versioneve.

Modernisti në mua thotë se mund të përdorni Kubernetes/Docker për të bërë gjithçka të përmendur më lart, dhe ka të drejtë.

Përveç kësaj, mund të sigurohet automatizimi, me anë të Chef, Puppet ose Terraform.

Integrimi dhe dorëzimi i vazhdueshëm

Për të krijuar një shërbim të shkallëzuar, është e rëndësishme të keni një tubacion ndërtimi dhe testi për çdo kërkesë të tërheqjes. Edhe nëse testi është më i thjeshtë, të paktën sigurohet që kodi që po e deployoni, kompilon.

Çdo herë në këtë fazë, përgjigjeni pyetjes: a do të kompilojë ndërtimi im dhe do të kalojë testet, a është valido? Kjo mund të duket si një nivel i ulët, por zgjidh shumë probleme.

Nuk ka asgjë më të bukur se të shohësh këto shenja

Për këtë teknologji, mund të shqyrtoni Github, CircleCI ose Jenkins.

Balancuesit e ngarkesës

Pra, ne duam të nisemi me një balancues ngarkese për të drejtuar trafikun dhe për të siguruar ngarkesë të barabartë në të gjitha nyjet ose funksionimin e shërbimit në rast dështimi:

Balancuesi i ngarkesës zakonisht ndihmon në shpërndarjen e trafik, Praktika më e mirë është mbrojtja e tepërt, në mënyrë që të mos keni një pikë dështimi.

Zakonisht balancuesit e ngarkesës konfigurohen në atë cloud që po përdorni.

RayID, correlation ID ose UUID për kërkesat

A e keni takuar ndonjëherë një gabim në aplikacion me një mesazh të tillë: ‘Diçka shkoi gabim. Ruani këtë id dhe dërgojeni në shërbimin tonë të mbështetjes’?

Një identifikues unik, correlation ID, RayID ose ndonjë nga opsionet - është një identifikues unik që lejon ndjekjen e kërkesës gjatë ciklit të saj të jetës. Kjo lejon që të ndjekësh të gjithë rrugën e kërkesës në log.

Përdoruesi bën një kërkesë në sistemin A, më pas A lidhet me B, B me C, ruan në X dhe pastaj kërkesa kthehet te A.

Nëse do t'ju duhej të lidhnit në distancë me makinat virtuale dhe të provonit të ndiqnit rrugën e kërkesës (dhe të lidhni manualisht, cilat thirrje ndodhin), do të çmendeshit. Të kesh një identifikues unik e bën jashtëzakonisht më të lehtë jetën. Kjo është një nga gjërat më të thjeshta që mund të bëni për të kursyer kohë ndërsa shërbimi juaj rritet.

Niveli i mesëm

Këtu këshillat janë më të ndërlikuara se ato të mëparshmet, por mjetet e duhura e lehtësojnë задачë dhe ofrojnë kthim të investimeve edhe për kompani të vogla dhe të mesme.

Menaxhimi i centralizuar i regjistrave

Urime! Keni implementuar 100 makina virtuale. Të nesërmen, CEO i kompanisë vjen dhe ankohet për një gabim që ka marrë gjatë testimit të shërbimit. Ai jep identifikuesin përkatës, për të cilin diskutuan më lart, por ju do të duhet të kaloni përmes regjistrave të 100 makinave për të gjetur atë që shkaktoi dështimin. Dhe duhet ta gjeni atë përpara prezantimit të nesërm.

Edhe pse duket si një aventurë, ndoshta është më mirë të siguroheni se keni mundësi të kërkoni në të gjitha regjistrat nga një vend. Unë zgjodha të centralizoja regjistrat duke përdorur funksionalitetin e ndërtuar në ELK stack: këtu mbështetet mbledhja e regjistrave me mundësinë për të kërkuar. Kjo vërtet do t'ju ndihmojë të zgjidhni problemin me gjetjen e një regjistri të caktuar. Si bonus, mund të krijoni grafikë dhe gjëra të tjera argëtuese.

Funksionaliteti i ELK stack

Agjentët e monitorimit

Tani që shërbimi juaj është aktiv, duhet të siguroheni që të funksionojë pa probleme. Mënyra më e mirë për ta bërë këtë është të nisni disa agjentë, të cilët punojnë paralelisht dhe kontrollojnë nëse ajo funksionon dhe kryhen operacionet bazë.

Në këtë fazë, ju kontrolloni nëse ndërtimi i nisur ndjehet mirë dhe punon normalisht..

Për projektet e vogla dhe ata mesatarë, unë rekomandoj Postman për monitorimin dhe dokumentimin e API-ve. Megjithatë, në përgjithësi, thjesht sigurohuni që keni një mënyrë për të mësuar kur ndodhi një dështim dhe të merrni njoftime të shpejta.

Auto-skalimi sipas ngarkesës

Është shumë e thjeshtë. Nëse keni një makinë virtuale që shërben kërkesa dhe po afrohet në 80% të kapacitetit të memories, mund të rritni burimet e saj ose të shtoni më shumë makina virtuale në klaster. Automatizimi i këtyre operacioneve është një mënyrë e shkëlqyer për të rritur fleksibilitetin e përputhjes me ngarkesën. Por gjithmonë duhet të jeni të kujdesshëm për shumën e parave që shpenzoni dhe të vendosni kufij të arsyeshëm.

Në shumicën e shërbimeve cloud, mund të konfiguroni auto-skalimin duke përdorur më shumë serverë ose serverë më të fuqishëm.

Sistemi i eksperimenteve

Një mënyrë e mirë për të shpërndarë përditësime në mënyrë të sigurt është të keni mundësinë të testoni diçka për 1% të përdoruesve për një orë. Sigurisht, keni parë mekanizma të tillë në veprim. Për shembull, Facebook tregon një ngjyrim tjetër ose ndryshon madhësinë e shkronjave për një pjesë të audiencës për të parë si reagojnë përdoruesit ndaj ndryshimeve. Kjo quhet testim A/B.

Edhe lëshimi i një karakteristike të re mund të testohet si një eksperiment dhe më pas të përcaktohet si të shkarkohet. Gjithashtu, ju jepni mundësinë për të "përmbyllur" ose për të ndryshuar konfigurimin në flakë në përputhje me një funksion që shkakton degradimin e shërbimit tuaj.

Niveli i avancuar

Këtu janë këshilla që janë mjaft të vështira për t'u zbatuar. Probabilisht do t'ju nevojiten më shumë burime, prandaj është e vështirë për një kompani të vogël ose mesatare të merret me to.

Shpërndarjet blu-jeshil

Kjo është ajo që unë e quaj "shpërndarje erlang". Erlang janë përdorur gjerësisht kur u shfaqën kompanitë telefonike. Për të rritur thirrjet telefonike, filluan të aplikohen komutatorë softuerikë. Detyra kryesore e softuerit të këtyre komutatorëve ishte të mos ndërpriste thirrjet gjatë përditësimit të sistemit. Erlang ka një mënyrë të shkëlqyer për të ngarkuar një modul të ri pa rrënuar atë ekzistues.

Ky hap varet nga disponueshmëria e një balancuesi ngarkese. Le të themi se keni versionin N të softuerit tuaj dhe më pas dëshironi të shpërndani versionin N+1.

Ju mundet thjesht të ndaloni shërbimin dhe të shpërndani versionin tjetër në momentin që e konsideroni të përshtatshëm për përdoruesit tuaj, dhe të merrni një periudhë të caktuar papunësie. Por supozoni se keni vërtet kushtet e rrepta të SLA. Kështu, një SLA prej 99.99% do të thotë që mund të jeni offline vetëm për 52 minuta në vit.

Nëse me të vërtetë dëshironi të arrini këto nivele, ju nevojiten dy shpërndarje njëkohësisht:

ajo që është tani (N);
versioni tjetër (N+1).

Ju i thoni balancuesit të ngarkesës të redirektojë një përqindje të trafikut në versionin e ri (N+1), ndërsa ju aktivisht monitoroni regresionet.

Këtu kemi një shpërndarje të gjelbër N që funksionon normalisht. Ne po përpiqemi të kalojmë në versionin tjetër të kësaj shpërndarjeje.

Fillimisht ne dërgojmë një test shumë të vogël për të parë nëse shpërndarja jonë N+1 punon me një numër të vogël trafiku:

Më në fund, kemi një grup kontrollesh automatike që në fund do të ekzekutojmë derisa shpërndarja jonë të përfundojë. Nëse jeni shumë, shumë të kujdesshëm, gjithashtu mund të mbani shpërndarjen tuaj N përgjithmonë për një rikthim të shpejtë në rast të regresionit të keq:

Nëse dëshiron të kalosh në një nivel akoma më të avancuar, le të bëjë gjithçka në shpërndarjen blu-jeshil automatikisht.

Zbulimi i anomalisë dhe mitizimi automatik i pasojave

Duke marrë parasysh se keni një qendër të centralizuar logimi dhe mbledhje të mira logesh, mund të vendosni objektiva më të larta. Për shembull, të parashikoni proaktivisht dështimet. Në monitorë dhe në logje, funksionet gjurmohen dhe ndizen grafika të ndryshme - dhe mund të parashikoni përpara se gjithçka të shkojë keq:

Me zbulimin e anomalisë, filloni të studioni disa shenja që shërbimi jep. Për shembull, një rritje e ngarkesës së CPU mund t'ju japë alarmin se disku i harduerit po dështon, dhe një rritje e numrit të kërkesave tregon se duhet të shkalloni. Statistika të tilla ju lejojnë të bëni shërbimin proaktiv.

Duke marrë këto të dhëna analitike, mund të shkalloni në çdo dimension, duke ndryshuar proaktivisht dhe reaktivisht karakteristikat e makinave, baza të të dhënave, lidhje dhe burime të tjera.

Këtu është gjithçka!

Ky这个 список приоритетов do t'ja te shfryte lëng të shumë problemeve nëse po ngrini një shërbim në re.

Autori i artikullit origjinal i fton lexuesit të lënë komente dhe të bëjnë ndryshime. Artikulli shpërndahet si open source, kërkesat për pull-requests autori pranon në Github.

Çfarë tjetër të lexoni mbi temën:

Burimi: habr.com