Acest articol conține câteva modele comune pentru a ajuta inginerii să lucreze cu servicii la scară largă care sunt accesate de milioane de utilizatori.
Din experiența autorului, aceasta nu este o listă exhaustivă, dar într-adevăr eficace sfat. Deci, să începem.
Tradus cu sprijin .
Primul nivel
Măsurile enumerate mai jos sunt relativ simplu de implementat, dar au un impact ridicat. Dacă nu le-ați încercat până acum, veți fi surprins de îmbunătățirile semnificative.
Infrastructura ca cod
Prima parte a sfaturilor este să implementați infrastructura ca cod. Aceasta înseamnă că trebuie să aveți o modalitate programatică de a implementa întreaga infrastructură. Sună complicat, dar vorbim de fapt despre următorul cod:
Implementarea a 100 de mașini virtuale
- cu Ubuntu
- 2 GB RAM fiecare
- vor avea următorul cod
- cu acești parametri
Puteți urmări modificările aduse infrastructurii dvs. și puteți reveni rapid la ele folosind controlul versiunilor.
Modernistul din mine spune că poți folosi Kubernetes/Docker pentru a face toate cele de mai sus și are dreptate.
În plus, puteți oferi automatizare folosind Chef, Puppet sau Terraform.
Integrare și livrare continuă
Pentru a crea un serviciu scalabil, este important să aveți o conductă de compilare și testare pentru fiecare cerere de extragere. Chiar dacă testul este foarte simplu, se va asigura cel puțin că codul pe care îl implementați este compilat.
De fiecare dată în această etapă răspundeți la întrebarea: ansamblul meu va compila și va trece teste, este valid? Poate părea o bară scăzută, dar rezolvă o mulțime de probleme.
Nu este nimic mai frumos decât să vezi aceste căpușe
Pentru această tehnologie puteți evalua Github, CircleCI sau Jenkins.
Echilibratoare de sarcină
Deci, dorim să rulăm un echilibrator de încărcare pentru a redirecționa traficul și a asigura o încărcare egală pe toate nodurile sau serviciul continuă în caz de eșec:
Un echilibrator de încărcare face de obicei o treabă bună în distribuirea traficului. Cea mai bună practică este să supraechilibrați, astfel încât să nu aveți un singur punct de eșec.
De obicei, echilibratoarele de încărcare sunt configurate în cloud-ul pe care îl utilizați.
RayID, ID de corelare sau UUID pentru solicitări
Ați întâmpinat vreodată o eroare de aplicație cu un mesaj ca acesta: "Ceva n-a mers bine. Salvați acest id și trimiteți-l echipei noastre de asistență"?
Un identificator unic, ID de corelare, RayID sau oricare dintre variante, este un identificator unic care vă permite să urmăriți o solicitare pe tot parcursul ciclului său de viață. Acest lucru vă permite să urmăriți întreaga cale de solicitare în jurnale.
Utilizatorul face o cerere către sistemul A, apoi A contactează B, care contactează C, o stochează în X, iar apoi cererea este returnată la A
Dacă ar fi să vă conectați de la distanță la mașinile virtuale și să încercați să urmăriți calea solicitării (și să corelați manual apelurile efectuate), ați înnebuni. Având un identificator unic, viața este mult mai ușoară. Acesta este unul dintre cele mai simple lucruri pe care le puteți face pentru a economisi timp pe măsură ce serviciul dvs. crește.
Nivel mediu
Sfaturile de aici sunt mai complexe decât cele anterioare, dar instrumentele potrivite ușurează sarcina, oferind o rentabilitate a investiției chiar și pentru companiile mici și mijlocii.
Înregistrare centralizată
Felicitări! Ați implementat 100 de mașini virtuale. A doua zi, CEO-ul vine și se plânge de o eroare pe care a primit-o la testarea serviciului. Raportează ID-ul corespunzător despre care am vorbit mai sus, dar va trebui să te uiți prin jurnalele a 100 de mașini pentru a-l găsi pe cel care a provocat accidentul. Și trebuie găsit înainte de prezentarea de mâine.
Deși pare o aventură distractivă, cel mai bine este să vă asigurați că aveți capacitatea de a căuta toate revistele într-un singur loc. Am rezolvat problema centralizării jurnalelor utilizând funcționalitatea încorporată a stivei ELK: acceptă colecția de jurnale care poate fi căutată. Acest lucru va ajuta cu adevărat la rezolvarea problemei de a găsi un anumit jurnal. Ca bonus, puteți crea diagrame și alte lucruri distractive de genul.
Funcționalitatea stivă ELK
Agenți de monitorizare
Acum că serviciul dvs. este în funcțiune, trebuie să vă asigurați că funcționează fără probleme. Cel mai bun mod de a face acest lucru este să rulați mai multe agenţi, care lucrează în paralel și verifică dacă funcționează și se efectuează operațiunile de bază.
În acest moment verificați asta construcția de rulare se simte bine și funcționează bine.
Pentru proiectele de dimensiuni mici spre mijlocii, recomand Postman pentru monitorizarea și documentarea API-urilor. Dar, în general, doriți doar să vă asigurați că aveți o modalitate de a afla când a avut loc o întrerupere și de a fi notificat în timp util.
Autoscaling în funcție de sarcină
E foarte simplu. Dacă aveți solicitări de service pentru o VM și se apropie de 80% de utilizare a memoriei, puteți fie să-i creșteți resursele, fie să adăugați mai multe VM-uri în cluster. Execuția automată a acestor operații este excelentă pentru modificări elastice de putere sub sarcină. Dar ar trebui să fii întotdeauna atent la câți bani cheltuiți și să stabiliți limite rezonabile.
Cu cele mai multe servicii cloud, îl puteți configura la scalare automată folosind mai multe servere sau servere mai puternice.
Sistemul de experimente
O modalitate bună de a lansa actualizări în siguranță este să poți testa ceva pentru 1% dintre utilizatori timp de o oră. Desigur, ați văzut astfel de mecanisme în acțiune. De exemplu, Facebook arată părți ale publicului o culoare diferită sau modifică dimensiunea fontului pentru a vedea cum percep utilizatorii modificările. Aceasta se numește testare A/B.
Chiar și lansarea unei noi funcții poate fi începută ca un experiment și apoi se poate determina cum să o lanseze. De asemenea, aveți posibilitatea de a vă „aminti” sau de a modifica configurația din mers pe baza funcției care provoacă degradarea serviciului dumneavoastră.
Nivel avansat
Iată sfaturi care sunt destul de greu de implementat. Probabil că veți avea nevoie de puțin mai multe resurse, așa că o companie mică sau mijlocie va avea dificultăți în gestionarea asta.
Implementări albastru-verde
Aceasta este ceea ce eu numesc modul de desfășurare „Erlang”. Erlang a devenit utilizat pe scară largă când au apărut companiile de telefonie. Softswitch-urile au început să fie folosite pentru a direcționa apelurile telefonice. Scopul principal al software-ului de pe aceste comutatoare a fost să nu renunțe la apeluri în timpul upgrade-urilor de sistem. Erlang are o modalitate drăguță de a încărca un modul nou fără a-l bloca pe cel anterior.
Acest pas depinde de prezența unui echilibrator de încărcare. Să ne imaginăm că aveți versiunea N a software-ului dvs. și apoi doriți să implementați versiunea N+1.
Tu am putea doar opriți serviciul și lansați următoarea versiune la un moment care funcționează pentru utilizatorii dvs. și obțineți ceva timp de nefuncționare. Dar să presupunem că ai într-adevăr condiții stricte SLA. Deci, SLA 99,99% înseamnă că puteți merge offline numai cu 52 de minute pe an.
Dacă doriți cu adevărat să obțineți astfel de indicatori, aveți nevoie de două implementări în același timp:
- cel care este chiar acum (N);
- versiunea următoare (N+1).
Îi spuneți echilibratorului de încărcare să redirecționeze un procent din trafic către noua versiune (N+1) în timp ce monitorizați în mod activ regresiile.
Aici avem o implementare N verde care funcționează bine. Încercăm să trecem la următoarea versiune a acestei implementări
Mai întâi trimitem un test foarte mic pentru a vedea dacă implementarea noastră N+1 funcționează cu o cantitate mică de trafic:
În cele din urmă, avem un set de verificări automate pe care în cele din urmă le rulăm până la finalizarea implementării noastre. daca tu foarte, foarte Atenție, vă puteți salva, de asemenea, implementarea N pentru totdeauna pentru o derulare rapidă în caz de regresie greșită:
Dacă doriți să mergeți la un nivel și mai avansat, lăsați totul din implementarea albastru-verde să ruleze automat.
Detectarea anomaliilor și atenuarea automată
Având în vedere că aveți o înregistrare centralizată și o bună colectare a jurnalelor, vă puteți stabili deja obiective mai mari. De exemplu, anticipați în mod proactiv eșecurile. Funcțiile sunt urmărite pe monitoare și în jurnale și sunt construite diverse diagrame - și puteți prezice din timp ce va merge prost:
Odată ce anomaliile sunt detectate, începeți să examinați unele dintre indicii pe care le oferă serviciul. De exemplu, o creștere a încărcăturii procesorului poate indica că un hard disk se defectează, în timp ce o creștere a solicitărilor poate indica faptul că trebuie să creșteți. Acest tip de date statistice vă permit să faceți serviciul proactiv.
Cu aceste informații, puteți scala în orice dimensiune și puteți modifica în mod proactiv și reactiv caracteristicile mașinilor, bazelor de date, conexiunilor și altor resurse.
Asta e tot!
Această listă de priorități vă va scuti de multe probleme dacă creați un serviciu cloud.
Autorul articolului original invită cititorii să-și lase comentariile și să facă modificări. Articolul este distribuit ca sursă deschisă, solicitări de extragere din partea autorului .
Ce să mai citești pe această temă:
Sursa: www.habr.com