Questu articulu cuntene parechji mudelli cumuni per aiutà l'ingegneri à travaglià cù servizii di grande scala chì sò accessu da milioni di utilizatori.
In l'esperienza di l'autore, questu ùn hè micca una lista exhaustiva, ma veramente efficace cunsigliu. Allora, cuminciamu.
Traduttu cù supportu .
Primu livellu
E misure elencate quì sottu sò relativamente simplici per implementà, ma anu un impattu altu. Se ùn l'avete micca pruvatu prima, sarete sorpresu di e migliorie significative.
Infrastruttura cum'è codice
A prima parte di u cunsigliu hè di implementà l'infrastruttura cum'è codice. Questu significa chì duvete avè un modu programmaticu per implementà tutta l'infrastruttura. Sembra complicatu, ma in realtà parlemu di u codice seguente:
Implementazione di 100 macchine virtuali
- cù Ubuntu
- 2 GB di RAM ognunu
- anu da avè u codice seguente
- cù sti paràmetri
Pudete seguità i cambiamenti à a vostra infrastruttura è torna rapidamente à elli cù u cuntrollu di versione.
U mudernista in mè dice chì pudete aduprà Kubernetes / Docker per fà tuttu ciò chì sopra, è hà ghjustu.
Inoltre, pudete furnisce l'automatizazione cù Chef, Puppet o Terraform.
Integrazione Cuntinuu è Consegna
Per creà un serviziu scalabile, hè impurtante avè un pipeline di custruzzione è di prova per ogni dumanda di pull. Ancu s'è a prova hè assai simplice, almenu assicurarà chì u codice chì implementate compile.
Ogni volta in questu stadiu, risponde à a quistione: a mo assemblea compilerà è passà i testi, hè validu? Questu pò parè una barra bassa, ma risolve assai prublemi.
Ùn ci hè nunda di più bellu chè vede sti ticks
Per questa tecnulugia pudete evaluà Github, CircleCI o Jenkins.
Equilibrati di carica
Dunque, vulemu eseguisce un equilibratore di carica per reindirizzà u trafficu è assicurà a carica uguale in tutti i nodi o u serviziu cuntinueghja in casu di fallimentu:
Un balancer di carica generalmente faci un bonu travagliu di distribuzione di u trafficu. A megliu pratica hè di overbalance per ùn avè micca un puntu di fallimentu.
Di genere, i balancers di carica sò cunfigurati in u nuvulu chì utilizate.
RayID, ID di correlazione o UUID per e richieste
Avete mai scontru un errore di l'applicazione cù un missaghju cum'è questu: "Qualcosa hè andatu male. Salvate questu id è mandate à a nostra squadra di supportu "?
Un identificatore unicu, ID di correlazione, RayID, o qualsiasi di e variazioni, hè un identificatore unicu chì permette di seguità una dumanda in tuttu u so ciclu di vita. Questu permette di seguità a strada di a dumanda sana in i logs.
L'utilizatore fa una dumanda à u sistema A, dopu A cuntatta B, chì cuntatta C, l'almacene in X, è poi a dumanda hè tornata à A.
Sè avete da cunnette remotamente à e macchine virtuali è pruvate à traccia u percorsu di a dumanda (è correlate manualmente quali chjamate sò state fatte), andate pazzo. Avè un identificatore unicu rende a vita assai più faciule. Questa hè una di e cose più simplici chì pudete fà per risparmià tempu mentre u vostru serviziu cresce.
U livellu mediu
I cunsiglii quì sò più cumplessi di quelli precedenti, ma l'arnesi ghjusti facenu u travagliu più faciule, furnisce un ritornu di l'investimentu ancu per e cumpagnie chjuche è mediane.
Logging centralizatu
Felicitazioni! Avete implementatu 100 macchine virtuali. U ghjornu dopu, u CEO vene è si lamenta di un errore chì hà ricevutu mentre pruvava u serviziu. Riporta l'ID currispundenti chì avemu parlatu sopra, ma vi tuccherà à circà à traversu i logs di 100 machini per truvà quellu chì hà causatu u crash. È ci vole à truvà prima di a presentazione di dumane.
Mentre chì questu sona cum'è una avventura divertente, hè megliu per assicurà chì avete a capacità di circà tutte e riviste in un locu. Aghju risoltu u prublema di centralizà i logs cù a funziunalità integrata di a pila ELK: sustene a cullizzioni di log di ricerca. Questu veramente aiutà à risolve u prublema di truvà un ghjurnale specificu. Comu bonus, pudete creà grafici è altre cose divertenti cusì.
Funzionalità di stack ELK
Agenti di monitoraghju
Avà chì u vostru serviziu hè in funziunamentu, avete bisognu di assicurassi chì u vostru serviziu funziona bè. U megliu modu per fà questu hè di eseguisce parechji agenti, chì travaglia in parallelu è verificate chì funziona è l'operazioni basi sò realizate.
À questu puntu, verificate chì a custruzione in esecuzione si sente bè è funziona bè.
Per prughjetti chjuchi à mediu, ricumandemu Postman per u monitoraghju è a documentazione di l'API. Ma in generale, solu vulete assicurà chì avete un modu per sapè quandu un outage hè accadutu è esse avvisatu in una manera puntuale.
Autoscaling secondu a carica
Hè assai simplice. Sì avete una dumanda di serviziu di VM è si avvicina à l'80% di l'usu di memoria, pudete aumentà e so risorse o aghjunghje più VM à u cluster. L'esecuzione automatica di queste operazioni hè eccellente per i cambiamenti di putenza elastica sottu carica. Ma duvete sempre esse attentu à quantu soldi spende è stabilisce limiti raghjone.
Cù a maiò parte di i servizii di nuvola, pudete cunfigurà per autoscala utilizendu più servitori o servitori più putenti.
Sistema di esperimentu
Una bona manera di mette in sicurezza l'aghjurnamenti hè di pudè pruvà qualcosa per 1% di l'utilizatori per una ora. Avete, sicuru, vistu tali miccanismi in azzione. Per esempiu, Facebook mostra parte di l'audienza un culore diversu o cambia a dimensione di font per vede cumu l'utilizatori percepiscenu i cambiamenti. Questu hè chjamatu test A / B.
Ancu a liberazione di una nova funzione pò esse iniziata cum'è un esperimentu è poi determinate cumu liberallu. Avete ancu l'abilità di "ricordà" o cambià a cunfigurazione nantu à a mosca basatu annantu à a funzione chì causa a degradazione in u vostru serviziu.
Livellu avanzatu
Eccu cunsiglii chì sò abbastanza difficiuli di implementà. You Mulateri Di L'bisognu di un pocu di più risorse, cusì una piccula o mediana cumpagnia avarà un tempu difficiuli di gestisce questu.
Impiegazioni blu-verde
Questu hè ciò chì chjamu u modu "Erlang" di sviluppà. Erlang hè diventatu largamente utilizatu quandu e cumpagnie telefoniche apparsu. Softswitches cuminciaru à esse aduprati per indirizzà e telefonate. U scopu principale di u software nantu à questi switches era di ùn abbandunà e chjama durante l'aghjurnamenti di u sistema. Erlang hà una bella manera di carricà un novu modulu senza crashing u precedente.
Stu passu dipende da a presenza di un balancer di carica. Imagine chì avete a versione N di u vostru software, è dopu vulete implementà a versione N + 1.
Voi puderemu basta à piantà u serviziu è lanciate a prossima versione à u mumentu chì travaglia per i vostri utilizatori è uttene un pocu di downtime. Ma suppone chì avete veramente cundizioni strette SLA. Allora, SLA 99,99% significa chì pudete andà offline solu da 52 minuti à l'annu.
Se vulete veramente ottene tali indicatori, avete bisognu di duie implementazioni à u stessu tempu:
- quellu chì hè avà (N);
- versione successiva (N+1).
Dite à u balancer di carica per redirige un percentinu di u trafficu à a nova versione (N + 1) mentre monitorate attivamente i regressioni.
Eccu avemu una implementazione N verde chì funziona bè. Pruvamu di passà à a prossima versione di sta implementazione
Prima mandemu una prova veramente chjuca per vede se a nostra implementazione N + 1 funziona cù una piccula quantità di trafficu:
Infine, avemu un inseme di cuntrolli automatizati chì eventualmente eseguimu finu à chì a nostra implementazione hè cumpleta. Si tù assai assai Attenzione, pudete ancu salvà a vostra implementazione N per sempre per un rollback rapidu in casu di mala regressione:
Se vulete andà à un livellu ancu più avanzatu, lasciate chì tuttu in a implementazione blu-verde corre automaticamente.
Rilevazione di anomalie è mitigazione automatica
Dapoi chì avete un logu centralizatu è una bona cullizzioni di log, pudete digià stabilisce scopi più alti. Per esempiu, predice proattivamente i fallimenti. E funzioni sò tracciate nantu à i monitori è in i logs è parechji diagrammi sò custruiti - è pudete predichendu in anticipu ciò chì andarà male:
Una volta chì l'anomali sò rilevati, cuminciate à esaminà alcune di e piste chì u serviziu furnisce. Per esempiu, un piccu in a carica di CPU pò indicà chì un discu duru hè fallimentu, mentre chì un spike in richieste pò indicà chì avete bisognu di scala. Stu tipu di dati statistichi permette di fà u serviziu proattivu.
Cù questi insights, pudete scala in ogni dimensione è cambià in modu proattivu è reattivu e caratteristiche di e macchine, basa di dati, cunnessione è altre risorse.
Eccu tuttu!
Sta lista di priurità vi salvà assai di prublemi s'è vo sò risuscitatu un serviziu nuvola.
L'autore di l'articulu originale invita i lettori à lascià i so cumenti è fà cambiamenti. L'articulu hè distribuitu cum'è open source, pull requests da l'autore .
Cosa altru à leghje nantu à u tema:
Source: www.habr.com