Notă. transl.: Autorul acestui articol (Luc Perkins) este un avocat al dezvoltatorilor la organizația CNCF, care găzduiește proiecte Open Source precum Linkerd, SMI (Service Mesh Interface) și Kuma (apropo, v-ați întrebat și de ce Istio este nu este pe această listă? Încă o dată încercând să aducă comunității DevOps o mai bună înțelegere a hype-ului la modă numit „service mesh”, el enumeră 16 capabilități caracteristice pe care le oferă astfel de soluții.
Azi ― unul dintre cele mai fierbinți subiecte din domeniul ingineriei software (și pe bună dreptate!). Cred că această tehnologie este incredibil de promițătoare și mi-ar plăcea să o vadă adoptată pe scară largă (când are sens, desigur). Cu toate acestea, este încă înconjurat de o aură de mister pentru majoritatea oamenilor. În același timp, chiar și cei care bine cunoscute cu ea, este adesea dificil să-i formulezi avantajele și ce este exact (inclusiv pe al tău cu adevărat). În acest articol voi încerca să corectez situația prin enumerarea diverselor cazuri de utilizare „ochiuri de serviciu”*.
* Notă transl.: aici și mai departe în articol exact această traducere („service mesh”) va fi folosită pentru termenul încă nou de service mesh.
Dar mai întâi vreau să fac câteva comentarii:
- Nu am lucrat niciodată cu rețele de serviciu sau nu le-am folosit în afara proiectelor începute pentru propria mea educație. Pe de altă parte, eu am fost cel care a scris o grămadă de documentație pentru rețeaua de servicii interne a Twitter în 2015 (pe atunci nici măcar nu se numea „serviciu de plasă”) și am participat la dezvoltarea site-ului web și a documentației pentru , deci asta înseamnă ceva.
- Lista mea este aproximativă și incompletă. Cazurile de utilizare necunoscute pentru mine sunt destul de posibile și, probabil, vor apărea noi opțiuni în timp pe măsură ce tehnologia se dezvoltă și popularitatea acesteia crește.
- În același timp, nu fiecare implementare existentă a rețelei de servicii acceptă toate cazurile de utilizare enumerate. Prin urmare, afirmațiile mele precum „serviciu de plasă poate...” ar trebui să fie citite ca „individual și, probabil, toate implementările populare de servicii de plasă pot...”.
- Ordinea exemplelor nu face nicio diferență.
Lista finaliștilor:
- descoperirea serviciului;
- criptare;
- autentificare și autorizare;
- echilibrarea sarcinii;
- întreruperea circuitului;
- autoscaling;
- desfășurări canare;
- implementări albastru-verde;
- control medical;
- debarasarea sarcinii;
- oglindirea traficului;
- izolatie;
- limitarea ratei de solicitare, reîncercări și timeout-uri;
- telemetrie;
- audit;
- vizualizare.
1. Descoperirea serviciului
TL;DR: Conectați-vă la alte servicii din rețea folosind nume simple.
Serviciile ar trebui să se poată „găsi” automat între ele folosind nume adecvate - de exemplu, service.api.production, pets/staging sau cassandra. Mediile cloud sunt elastice, iar un singur nume poate ascunde multe instanțe ale unui serviciu. Este clar că într-o astfel de situație este imposibil din punct de vedere fizic să codificați toate adresele IP.
În plus, atunci când un serviciu găsește altul, ar trebui să poată trimite cereri către acel serviciu fără teama că acestea vor ajunge la intrarea instanței sale rupte. Cu alte cuvinte, rețeaua de servicii trebuie să monitorizeze starea tuturor instanțelor de serviciu și să mențină lista de gazde cât mai actualizată posibil.
Fiecare mesh de servicii implementează mecanismul de descoperire a serviciului în mod diferit. În prezent, cea mai comună modalitate este de a delega proceselor externe precum DNS Kubernetes. În trecut, pe Twitter am folosit un sistem de denumire în acest scop . În plus, tehnologia service mesh face posibilă apariția mecanismelor de denumire personalizate (deși nu am văzut încă nicio implementare SM cu o astfel de funcționalitate).
2. Criptare
TL;DR: Scăpați de traficul necriptat dintre servicii și faceți acest proces automatizat și scalabil.
Este plăcut să știi că atacatorii nu pot pătrunde în rețeaua ta internă. Firewall-urile fac o treabă grozavă în acest sens. Dar ce se întâmplă dacă un hacker intră înăuntru? Va putea face ce vrea cu traficul intraserviciu? Să sperăm că asta nu se va întâmpla până la urmă. Pentru a preveni acest scenariu, ar trebui să implementați o rețea de încredere zero în care tot traficul dintre servicii este criptat. Cele mai multe rețele de servicii moderne realizează acest lucru prin reciprocitate (TLS reciproc, mTLS). În unele cazuri, mTLS funcționează în nori întregi și clustere (cred că comunicațiile interplanetare vor fi într-o zi aranjate similar).
Desigur, pentru rețeaua de serviciu mTLS opțional. Fiecare serviciu poate avea grijă de propriul TLS, dar aceasta înseamnă că va trebui să găsiți o modalitate de a genera certificate, de a le distribui pe gazdele de servicii și de a include cod în aplicație care va încărca aceste certificate din fișiere. Da, nu uitați să reînnoiți aceste certificate la intervale regulate. Rețelele de servicii automatizează mTLS cu sisteme precum , care, la rândul lor, automatizează procesul de eliberare și rotație a certificatelor.
3. Autentificare și autorizare
TL;DR: Stabiliți cine este solicitantul și definiți ce este permis să facă înainte ca cererea să ajungă chiar la serviciu.
Serviciile doresc adesea să știe care efectuează cererea (autentificare), iar folosind aceste informații, decide că unui subiect dat are voie să facă (autorizare). În acest caz, pronumele „cine” poate ascunde:
- Alte servicii. Aceasta se numește „autentificare” egal" De exemplu, serviciul
webdorește să acceseze serviciuldb. Rețelele de servicii rezolvă de obicei astfel de probleme folosind mTLS: certificatele în acest caz acționează ca identificator necesar. - Unii utilizatori umani. Aceasta se numește „autentificare” cerere" De exemplu, utilizator
haxor69vrea să cumpere o lampă nouă. Rețelele de serviciu oferă diverse mecanisme, de ex. .Mulți dintre noi am făcut acest lucru în codul aplicației. Vine o cerere, ne uităm prin masă
users, găsiți utilizatorul și comparați parola, apoi verificați coloanapermissionsetc. În cazul unei rețele de servicii, acest lucru se întâmplă înainte ca cererea să ajungă chiar la serviciu.
Odată ce am stabilit de la cine a venit cererea, trebuie să stabilim ce are voie să facă această entitate. Unele rețele de servicii vă permit să setați politici de bază (despre cine poate face ce) ca fișiere YAML sau pe linia de comandă, în timp ce altele oferă integrare cu cadre precum . Scopul final este ca serviciile dvs. să accepte orice solicitare, presupunând că aceasta provine dintr-o sursă de încredere и această acțiune este permisă.
4. Echilibrarea sarcinii
TL;DR: Distribuiți încărcarea între instanțele de serviciu conform unui model specific.
Un „Serviciu” dintr-o secțiune de servicii constă foarte adesea din multe cazuri identice. De exemplu, astăzi serviciul cache este format din 5 exemplare, iar mâine numărul acestora poate crește la 11. Solicitări trimise la cache, trebuie distribuite în conformitate cu un scop anume. De exemplu, minimizați latența sau maximizați probabilitatea de a ajunge la o instanță de lucru. Cel mai des folosit algoritm este Round-robin, dar există multe altele - de exemplu, metoda ponderată (ponderat) interogări (puteți selecta ținte preferate), sună (inel) hashing (folosind hashing consecvent între gazdele din amonte) sau metoda cu cele mai puține cereri (se acordă preferință instanței cu cele mai puține solicitări).
Echilibratoarele clasice au alte funcții, cum ar fi cachingul HTTP și protecția DDoS, dar nu sunt foarte relevante pentru traficul est-vest (adică pentru traficul care circulă într-un centru de date - aprox. traducere) (sfera tipică a rețelei de servicii). Desigur, nu este necesar să utilizați o rețea de serviciu pentru echilibrarea încărcăturii, dar vă permite să setați și să controlați politicile de echilibrare pentru fiecare serviciu dintr-un nivel de control centralizat, eliminând astfel necesitatea de a rula și configura echilibrare de încărcare separate în stiva de rețea. .
5. Întreruperea circuitului
TL;DR: Opriți traficul către serviciul problematic și controlați daunele în cel mai rău caz.
Dacă din anumite motive serviciul nu poate face față traficului, rețeaua de servicii oferă mai multe opțiuni pentru rezolvarea acestei probleme (altele vor fi discutate în secțiunile corespunzătoare). Întreruperea circuitului este cea mai gravă opțiune pentru deconectarea unui serviciu de la trafic. Cu toate acestea, în sine nu are sens - este nevoie de un plan de rezervă. Se poate asigura contrapresiune () la serviciile care fac solicitări (nu uitați să vă configurați rețeaua de servicii pentru asta!), sau, de exemplu, colorați pagina de stare în roșu și redirecționați utilizatorii către o altă versiune a paginii cu „balena care căde” („Twitter este jos").
Rețelele de serviciu nu vă permit doar să definiți când va urma oprirea și că aceasta va urma. În acest caz, „când” poate include orice combinație de parametri specificați: numărul total de solicitări pentru o anumită perioadă, numărul de conexiuni paralele, solicitări în așteptare, reîncercări active etc.
Probabil că nu doriți să abuzați de întrerupere, dar este bine să știți că aveți un plan de rezervă în caz de urgență.
6. Autoscaling
TL;DR: Creșteți sau micșorați numărul de instanțe de serviciu în funcție de criteriile specificate.
Rețelele de servicii nu sunt programatoare, așa că nu executa scalandu-te. Cu toate acestea, ei pot oferi informații pe care planificatorii își vor baza deciziile. Deoarece rețelele de servicii au acces la tot traficul dintre servicii, acestea au informații extinse despre ceea ce se întâmplă: ce servicii întâmpină probleme, ce servicii sunt încărcate foarte puțin (capacitatea alocată acestora este irosită) etc.
De exemplu, Kubernetes scalează serviciile pe baza CPU-ului și a utilizării memoriei (vezi raportul nostru "„- aprox. traducere), dar dacă decideți să scalați pe baza oricărei alte valori (în cazul nostru, legată de trafic), veți avea nevoie de o măsură specială. management arată cum să faci asta cu , и , dar procesul în sine este destul de complicat. Ne-am dori ca reteaua de servicii să simplifice acest lucru, permițându-ne să setăm pur și simplu condiții precum „creșterea numărului de instanțe de serviciu auth, dacă numărul de solicitări în așteptare depășește pragul într-un minut."
7. Desfăşurări Canary
TL;DR: Testați noi funcții sau versiuni de servicii pe un subset de utilizatori.
Să presupunem că dezvoltați un produs SaaS și intenționați să lansați o nouă versiune cool a acestuia. L-ai testat în scenă și a funcționat grozav. Dar există încă anumite preocupări cu privire la comportamentul ei în condiții reale. Cu alte cuvinte, trebuie să testați noua versiune pe probleme reale, fără a risca încrederea utilizatorilor. Implementările Canary sunt grozave pentru asta. Acestea vă permit să demonstrați o nouă caracteristică unui subset de utilizatori. Acest subset poate consta din cei mai fideli utilizatori sau cei care lucrează cu versiunea gratuită a produsului sau utilizatori care și-au exprimat dorința de a fi „cobai”.
Rețelele de servicii implementează acest lucru permițându-vă să specificați criterii care determină cine va vedea ce versiune a aplicației și direcționând traficul în consecință. Cu toate acestea, nu se schimbă nimic pentru serviciile în sine. Versiunea 1.0 a serviciului consideră că toate solicitările provin de la utilizatori care ar trebui să-l vadă, iar versiunea 1.1 consideră același lucru pentru utilizatorii săi. Între timp, puteți modifica procentul de trafic între versiunea veche și cea nouă, redirecționând un număr tot mai mare de utilizatori către cea nouă dacă funcționează stabil și „cobaii” tăi dau voie.
8. Implementări albastru-verde
TL;DR: Lansați o nouă funcție interesantă, dar fiți pregătit să luați imediat totul înapoi.
sens este de a lansa un nou serviciu „albastru”, lansându-l în paralel cu cel vechi, „verde”. Dacă totul merge bine și noul serviciu funcționează bine, atunci cel vechi poate fi dezactivat treptat. (Vai, într-o zi acest nou serviciu „albastru” va repeta soarta celui „verde” și va dispărea...) Implementările albastru-verde diferă de cele canare prin faptul că noua funcție acoperă dintr-o dată utilizatori (nu fac parte); Ideea aici este să aveți un „port sigur” pregătit în cazul în care ceva nu merge bine.
Rețelele de serviciu oferă o modalitate foarte convenabilă de a testa un serviciu „albastru” și de a trece instantaneu la unul „verde” funcțional în caz de probleme. Ca să nu mai vorbim de faptul că pe parcurs oferă o mulțime de informații (vezi „Telemetrie” de mai jos) despre munca „albastrului”, ceea ce ajută la înțelegerea dacă este gata pentru funcționare completă.
Notă. transl.: Puteți citi mai multe despre diferite strategii de implementare în Kubernetes (inclusiv canarul menționat, albastru/verde și altele) în .
9. Controlul de sănătate
TL;DR: Urmăriți care instanțe de serviciu sunt funcționale și răspundeți la cele care nu mai sunt funcționale.
Control medical (control medical) vă ajută să decideți dacă instanțe de serviciu sunt pregătite să accepte și să proceseze traficul. De exemplu, în cazul serviciilor HTTP, o verificare a stării de sănătate poate arăta ca o solicitare GET către punctul final /health. Răspuns 200 OK va însemna că instanța este sănătoasă, oricare alta - că nu este pregătită să primească trafic. Rețelele de serviciu vă permit să specificați atât modul în care va fi verificată funcționalitatea, cât și frecvența cu care va fi efectuată această verificare. Aceste informații pot fi apoi utilizate în alte scopuri - de exemplu, pentru echilibrarea sarcinii și întreruperea circuitului.
Astfel, verificarea sănătății nu este un caz de utilizare de sine stătător, ci este de obicei folosită pentru a atinge alte obiective. De asemenea, în funcție de rezultatele verificărilor de sănătate, pot fi necesare acțiuni externe altor ținte ale rețelei de servicii: de exemplu, actualizarea paginii de stare, crearea unei probleme pe GitHub sau completarea unui bilet JIRA. Și rețeaua de serviciu oferă un mecanism convenabil pentru a automatiza toate acestea.
10. Reducerea sarcinii
TL;DR: redirecționează traficul ca răspuns la o creștere temporară a utilizării.
Dacă un anumit serviciu este supraîncărcat cu trafic, puteți redirecționa temporar o parte din acest trafic către o altă locație (adică „dump”, „transfer” (magazin) el acolo). De exemplu, către un serviciu de rezervă sau centru de date sau către un permanent subiect. Ca urmare, serviciul va continua să proceseze unele solicitări în loc să se blocheze și să oprească procesarea totul. Deversarea sarcinii este de preferat în locul întreruperii circuitului, dar totuși nu este indicat să abuzați de ea. Ajută la prevenirea defecțiunilor în cascadă care cauzează blocarea serviciilor din aval.
11. Paralelizarea/oglindirea traficului
TL;DR: Trimiteți o solicitare în mai multe locuri deodată.
Uneori este nevoie să trimiteți o solicitare (sau o anumită selecție de solicitări) către mai multe servicii simultan. Un exemplu tipic este trimiterea unei părți din traficul de producție către un serviciu de staging. Serverul web de producție principal trimite o solicitare către serviciul din aval products.production si numai lui. Și rețeaua de servicii copiază în mod inteligent această solicitare și o trimite către products.staging, despre care serverul web nici măcar nu știe.
Un alt caz de utilizare a rețelei de servicii care poate fi implementat pe lângă paralelizarea traficului este . Aceasta implică trimiterea acelorași solicitări către diferite versiuni ale serviciului și verificarea dacă toate versiunile se comportă la fel. Nu am întâlnit încă o implementare a rețelei de servicii cu un sistem integrat de testare a regresiei, cum ar fi , dar ideea în sine pare promițătoare.
12. Izolație
TL;DR: Împărțiți-vă reteaua de servicii în mini-rețele.
De asemenea cunoscut ca si segmentareIzolarea este arta de a împărți o rețea de servicii în segmente distincte din punct de vedere logic, care nu știu nimic unul despre celălalt. Izolarea este un pic ca crearea de rețele private virtuale. Diferența fundamentală este că vă puteți bucura în continuare de toate beneficiile unei rețele de servicii (cum ar fi descoperirea de servicii), dar cu un plus de securitate. De exemplu, dacă un atacator reușește să pătrundă într-un serviciu de pe una dintre subrețele, el nu va putea vedea ce servicii rulează pe alte subrețele sau să le intercepteze traficul.
În plus, beneficiile pot fi și organizaționale. Poate doriți să vă subrețea serviciile pe baza structurii companiei și să eliberați dezvoltatorii de sarcina cognitivă de a avea în vedere o întreagă rețea de servicii.
13. Solicitați limitarea ratei, reîncercări și expirări
TL;DR: Nu mai trebuie să includeți sarcini de gestionare a cererilor de apăsare în baza de cod.
Toate aceste lucruri ar putea fi considerate cazuri de utilizare separate, dar am decis să le combin din cauza unei singure caracteristici comune: preiau sarcinile de gestionare a ciclului de viață al cererilor, gestionate de obicei de bibliotecile de aplicații. Dacă dezvoltați un server web în Ruby on Rails (nu este integrat cu o rețea de servicii) care face cereri către serviciile de backend prin , aplicația va trebui să decidă ce să facă dacă N cereri eșuează. De asemenea, va trebui să aflați cât trafic vor putea aceste servicii să proceseze și să codificați acești parametri folosind o bibliotecă specială. În plus, aplicația va trebui să decidă când este timpul să renunțe și să lase cererea să epuizeze (în funcție de timeout). Și pentru a modifica oricare dintre parametrii de mai sus, serverul web va trebui oprit, reconfigurat și repornit.
Descărcarea acestor sarcini într-o rețea de servicii nu înseamnă doar că dezvoltatorii de servicii nu vor trebui să se gândească la ele, ci și că pot fi vizualizate într-un mod mai global. Dacă se utilizează un lanț complex de servicii, să spunem A -> B -> C -> D -> E, trebuie luat în considerare întregul ciclu de viață al cererii. Dacă sarcina este de a extinde timeout-urile în serviciul C, este logic să faceți acest lucru dintr-o dată, și nu în părți: prin actualizarea codului de serviciu și așteptând până când cererea de extragere este acceptată și sistemul CI implementează serviciul actualizat.
14. Telemetrie
TL;DR: Colectați toate informațiile necesare (și nu chiar) de la servicii.
Telemetria este un termen general care include valorile, urmărirea distribuită și jurnalele. Rețelele de servicii oferă mecanisme de colectare și procesare a tuturor celor trei tipuri de date. Aici lucrurile devin puțin neclare, deoarece numărul de opțiuni posibile este prea mare. Pentru a colecta valori există și alte instrumente care pot fi folosite pentru a colecta bușteni , , etc (de exemplu ClickHouse cu sistemul nostru pentru K8s - aprox. traducere), pentru urmărirea distribuită există și așa mai departe. Fiecare rețea de serviciu poate accepta unele instrumente și nu altele. Va fi interesant de văzut dacă proiectul poate oferă o oarecare convergență.
În acest caz, avantajul tehnologiei service mesh este că containerele sidecar pot, în principiu, să colecteze toate datele de mai sus de la serviciile lor. Cu alte cuvinte, aveți la dispoziție un singur sistem de colectare a telemetriei, iar rețeaua de servicii poate procesa toate aceste informații în diverse moduri. De exemplu:
- jurnalele de coadă de la un anumit serviciu din CLI;
- monitorizează volumul solicitărilor din tabloul de bord al rețelei de servicii;
- colectați urme distribuite și transmiteți-le către un sistem precum Jaeger.
Atentie, judecata subiectiva: În general, telemetria este un domeniu în care interferența puternică din rețeaua de serviciu este nedorită. Colectarea informațiilor de bază și urmărirea din mers a unor valori de aur, cum ar fi ratele de succes a cererilor și latența, este bine, dar să sperăm că nu vedem stive Frankenstein care încearcă să înlocuiască sisteme specializate, dintre care unele s-au dovedit deja și au fost bine studiate. .
15. Audit
TL;DR: Cei care uită lecțiile istoriei sunt sortiți să le repete.
Auditul este arta de a observa evenimente importante dintr-un sistem. În cazul unei rețele de servicii, aceasta ar putea însemna urmărirea cine a făcut solicitări către anumite puncte finale pentru anumite servicii sau de câte ori a avut loc un eveniment legat de securitate în ultima lună.
Este clar că auditul este foarte strâns legat de telemetrie. Diferența este că telemetria este de obicei asociată cu lucruri precum productivitatea și integritatea tehnică, în timp ce auditul se poate referi la aspecte juridice și de altă natură care depășesc sfera strict tehnică (de exemplu, conformitatea cu GDPR - Regulamentul general al UE privind protecția datelor).
16. Vizualizare
TL;DR: Trăiască React.js - o sursă inepuizabilă de interfețe fanteziste.
Poate că există un termen mai bun, dar nu îl știu. Mă refer doar la o reprezentare grafică a unei rețele de serviciu sau a unor componente ale acesteia. Aceste vizualizări pot include indicatori cum ar fi latențe medii, informații de configurare sidecar, rezultate ale verificărilor de sănătate și alerte.
Lucrul într-un mediu orientat spre servicii implică o încărcătură cognitivă mult mai mare în comparație cu Majestatea Sa Monolitul. Prin urmare, presiunea cognitivă ar trebui redusă cu orice preț. O interfață grafică simplă pentru o rețea de serviciu cu posibilitatea de a face clic pe un buton și de a obține rezultatul dorit ar putea fi decisivă pentru creșterea popularității acestei tehnologii.
Nu au fost incluse în listă
Inițial am intenționat să mai includ câteva cazuri de utilizare în listă, dar apoi am decis să nu o fac. Iată-le, împreună cu motivele deciziei mele:
- Centru de date multiple. În opinia mea, acesta nu este atât un caz de utilizare, cât o zonă îngustă și specifică de aplicare a rețelelor de servicii sau un set de funcții precum descoperirea serviciului.
- Intrare și ieșire. Aceasta este o zonă înrudită, dar m-am limitat (poate artificial) la cazul de utilizare „trafic est-vest”. Intrarea și ieșirea merită un articol separat.
Concluzie
Asta este tot pentru acum! Din nou, această listă este foarte arbitrară și cel mai probabil incompletă. Dacă credeți că am omis ceva sau am greșit ceva, vă rugăm să mă contactați pe Twitter (). Vă rugăm să respectați regulile decenței.
PS de la traducator
Ilustrația titlului articolului se bazează pe o imagine din articol „„(de Gregory MacKinnon). Acesta arată cum unele funcționalități din aplicații (în verde) s-au mutat într-o plasă de servicii care asigură interconexiuni între ele (în albastru).
Citește și pe blogul nostru:
- «»;
- «»;
- «".
Sursa: www.habr.com
