Ky artikull përmban disa modele të zakonshme për të ndihmuar inxhinierët të punojnë me shërbime në shkallë të gjerë që aksesohen nga miliona përdorues.
Në përvojën e autorit, kjo nuk është një listë shteruese, por në të vërtetë efektive këshilloj. Pra, le të fillojmë.
Përkthyer me mbështetje .
Niveli i hyrjes
Masat e renditura më poshtë janë relativisht të thjeshta për t'u zbatuar, por kanë një ndikim të lartë. Nëse nuk i keni provuar më parë, do të habiteni nga përmirësimet e rëndësishme.
Infrastruktura si kod
Pjesa e parë e këshillës është zbatimi i infrastrukturës si kod. Kjo do të thotë që ju duhet të keni një mënyrë programatike për të vendosur të gjithë infrastrukturën. Duket e ndërlikuar, por ne në fakt po flasim për kodin e mëposhtëm:
Vendosja e 100 makinave virtuale
- me Ubuntu
- 2 GB RAM secila
- ata do të kenë kodin e mëposhtëm
- me këto parametra
Ju mund të gjurmoni ndryshimet në infrastrukturën tuaj dhe t'u ktheheni shpejt atyre duke përdorur kontrollin e versionit.
Modernisti tek unë thotë se mund të përdorni Kubernetes/Docker për të bërë të gjitha sa më sipër, dhe ai ka të drejtë.
Përveç kësaj, ju mund të siguroni automatizim duke përdorur Chef, Puppet ose Terraform.
Integrimi dhe ofrimi 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 testimi për çdo kërkesë tërheqjeje. Edhe nëse testi është shumë i thjeshtë, të paktën do të sigurojë që kodi që vendosni të përpilohet.
Çdo herë në këtë fazë ju përgjigjeni pyetjes: a do të përpilojë dhe kalojë testet asambleja ime, a është e vlefshme? Kjo mund të duket si një shirit i ulët, por zgjidh shumë probleme.
Nuk ka asgjë më të bukur sesa të shohësh këto rriqra
Për këtë teknologji mund të vlerësoni Github, CircleCI ose Jenkins.
Balancuesit e ngarkesës
Pra, ne duam të ekzekutojmë një balancues të ngarkesës për të ridrejtuar trafikun dhe për të siguruar ngarkesë të barabartë në të gjitha nyjet ose shërbimi vazhdon në rast dështimi:
Një balancues i ngarkesës zakonisht bën një punë të mirë në shpërndarjen e trafikut. Praktika më e mirë është të mbibalanconi në mënyrë që të mos keni një pikë të vetme dështimi.
Në mënyrë tipike, balancuesit e ngarkesës konfigurohen në renë kompjuterike që përdorni.
RayID, ID korrelacioni ose UUID për kërkesat
A keni hasur ndonjëherë në një gabim aplikacioni me një mesazh si ky: "Dicka shkoi keq. Ruaje këtë ID dhe dërgoje te ekipi ynë mbështetës"?
Një identifikues unik, ID korrelacioni, RayID, ose ndonjë nga variacionet, është një identifikues unik që ju lejon të gjurmoni një kërkesë gjatë gjithë ciklit të saj jetësor. Kjo ju lejon të gjurmoni të gjithë rrugën e kërkesës në regjistra.
Përdoruesi bën një kërkesë për sistemin A, më pas A kontakton B, i cili kontakton C, e ruan atë në X dhe më pas kërkesa kthehet në A.
Nëse do të lidheshit në distancë me makinat virtuale dhe do të përpiqeshit të gjurmoni shtegun e kërkesës (dhe të lidhni manualisht se cilat thirrje po bëhen), do të çmendeshit. Të kesh një identifikues unik e bën jetën shumë më të lehtë. 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 mesatar
Këshillat këtu janë më komplekse se ato të mëparshmet, por mjetet e duhura e bëjnë detyrën më të lehtë, duke siguruar një kthim nga investimi edhe për kompanitë e vogla dhe të mesme.
Prerje e centralizuar
urime! Ju keni vendosur 100 makina virtuale. Të nesërmen vjen CEO dhe ankohet për një gabim që ka marrë gjatë testimit të shërbimit. Ai raporton ID-në përkatëse për të cilën folëm më lart, por do të duhet të shikoni regjistrat e 100 makinerive për të gjetur atë që shkaktoi përplasjen. Dhe duhet gjetur para prezantimit të nesërm.
Ndërsa kjo tingëllon si një aventurë argëtuese, është më mirë të siguroheni që të keni aftësinë për të kërkuar të gjitha revistat në një vend. E zgjidha problemin e centralizimit të regjistrave duke përdorur funksionalitetin e integruar të pirgut ELK: ai mbështet mbledhjen e regjistrave të kërkueshëm. Kjo do të ndihmojë vërtet në zgjidhjen e problemit të gjetjes së një ditari të veçantë. Si bonus, ju mund të krijoni tabela dhe gjëra të tjera argëtuese si kjo.
Funksionaliteti i pirgut ELK
Agjentët monitorues
Tani që shërbimi juaj është në funksionim, duhet të siguroheni që të funksionojë pa probleme. Mënyra më e mirë për ta bërë këtë është të ekzekutoni disa agjentët, të cilat punojnë paralelisht dhe kontrollojnë nëse funksionon dhe janë kryer operacionet bazë.
Në këtë pikë ju kontrolloni atë ndërtimi i drejtimit ndihet mirë dhe funksionon mirë.
Për projekte të vogla dhe të mesme, unë rekomandoj Postman për monitorimin dhe dokumentimin e API-ve. Por në përgjithësi, thjesht dëshironi të siguroheni që keni një mënyrë për të ditur se kur ka ndodhur një ndërprerje dhe të njoftoheni në kohën e duhur.
Shkallëzimi automatik në varësi të ngarkesës
Është shumë e thjeshtë. Nëse keni kërkesa për shërbimin e VM-së dhe po i afrohet përdorimit të memories 80%, mund të rrisni burimet e saj ose të shtoni më shumë VM në grup. Ekzekutimi automatik i këtyre operacioneve është i shkëlqyer për ndryshimet elastike të fuqisë nën ngarkesë. Por duhet të jeni gjithmonë të kujdesshëm për sa para shpenzoni dhe të vendosni kufij të arsyeshëm.
Me shumicën e shërbimeve cloud, mund ta konfiguroni atë në shkallëzim automatik duke përdorur më shumë serverë ose serverë më të fuqishëm.
Sistemi i eksperimentit
Një mënyrë e mirë për të nxjerrë në mënyrë të sigurt përditësimet është të jeni në gjendje të testoni diçka për 1% të përdoruesve për një orë. Ju, sigurisht, keni parë në veprim mekanizma të tillë. Për shembull, Facebook u tregon pjesëve të audiencës një ngjyrë të ndryshme ose ndryshon madhësinë e shkronjave për të parë se si përdoruesit i perceptojnë ndryshimet. Ky quhet testim A/B.
Edhe lëshimi i një veçorie të re mund të fillohet si një eksperiment dhe më pas të përcaktohet se si ta lëshojë atë. Ju gjithashtu merrni mundësinë për të "kujtuar" ose ndryshuar konfigurimin menjëherë bazuar në funksionin që po shkakton degradim në shërbimin tuaj.
Niveli i përparuar
Këtu janë këshilla që janë mjaft të vështira për t'u zbatuar. Ju ndoshta do të keni nevojë për pak më shumë burime, kështu që një kompani e vogël ose e mesme do ta ketë të vështirë ta menaxhojë këtë.
Vendosjet blu-jeshile
Kjo është ajo që unë e quaj mënyra "Erlang" e shpalosjes. Erlang u përdor gjerësisht kur u shfaqën kompanitë telefonike. Çelësat e butë filluan të përdoren për të drejtuar thirrjet telefonike. Qëllimi kryesor i softuerit në këta çelësa ishte që të mos hiqte telefonatat gjatë përmirësimeve të sistemit. Erlang ka një mënyrë të mirë për të ngarkuar një modul të ri pa prishur atë të mëparshëm.
Ky hap varet nga prania e një balancuesi të ngarkesës. Le të imagjinojmë se keni versionin N të softuerit tuaj dhe më pas dëshironi të vendosni versionin N+1.
Ju ne mund thjesht ndaloni shërbimin dhe nxirrni versionin tjetër në një kohë që funksionon për përdoruesit tuaj dhe merrni pak kohë joproduktive. Por supozoni se keni vërtet kushte strikte SLA. Pra, SLA 99,99% do të thotë që ju mund të dilni jashtë linje vetëm me 52 minuta në vit.
Nëse vërtet dëshironi të arrini tregues të tillë, ju nevojiten dy vendosje në të njëjtën kohë:
- ai që është tani (N);
- versioni tjetër (N+1).
Ju i thoni balancuesit të ngarkesës të ridrejtojë një përqindje të trafikut në versionin e ri (N+1) ndërkohë që monitoroni në mënyrë aktive për regresione.
Këtu kemi një vendosje të gjelbër N që funksionon mirë. Ne po përpiqemi të kalojmë në versionin tjetër të kësaj vendosjeje
Së pari ne dërgojmë një test vërtet të vogël për të parë nëse vendosja jonë N+1 funksionon me një sasi të vogël trafiku:
Më në fund, ne kemi një grup kontrollesh të automatizuara që ne përfundimisht i kryejmë derisa vendosja jonë të përfundojë. nëse ti shume shume kujdes, ju gjithashtu mund ta ruani vendosjen tuaj N përgjithmonë për një rikthim të shpejtë në rast regresioni të keq:
Nëse doni të shkoni në një nivel edhe më të avancuar, lërini gjithçka në vendosjen blu-jeshile të funksionojë automatikisht.
Zbulimi i anomalive dhe zbutja automatike
Duke pasur parasysh që keni prerje të centralizuar dhe grumbullim të mirë të regjistrave, tashmë mund të vendosni synime më të larta. Për shembull, parashikoni në mënyrë proaktive dështimet. Funksionet gjurmohen në monitorë dhe në regjistra dhe ndërtohen diagrame të ndryshme - dhe mund të parashikoni paraprakisht se çfarë do të shkojë keq:
Pasi të zbulohen anomalitë, ju filloni të ekzaminoni disa nga të dhënat që ofron shërbimi. Për shembull, një rritje në ngarkesën e CPU-së mund të tregojë se një hard disk po dështon, ndërsa një rritje e kërkesave mund të tregojë se duhet të rriteni. Këto lloj të dhënash statistikore ju mundësojnë ta bëni shërbimin proaktiv.
Me këto njohuri, ju mund të shkallëzoni në çdo dimension dhe të ndryshoni në mënyrë proaktive dhe reaktive karakteristikat e makinave, bazave të të dhënave, lidhjeve dhe burimeve të tjera.
Kjo eshte e gjitha!
Kjo listë prioritetesh do t'ju kursejë shumë probleme nëse jeni duke ngritur një shërbim cloud.
Autori i artikullit origjinal fton lexuesit të lënë komentet e tyre dhe të bëjnë ndryshime. Artikulli shpërndahet si burim i hapur, kërkesa tërheqëse nga autori .
Çfarë tjetër për të lexuar në këtë temë:
Burimi: www.habr.com