Bună din nou!.. În ajunul începerii cursului Am pregătit o altă traducere utilă.
O rețea de servicii este un strat de infrastructură configurabil, cu latență scăzută, care este necesar pentru a gestiona volume mari de comunicații inter-procese bazate pe rețea între interfețele de programare a aplicațiilor (API). Service Mesh permite comunicarea rapidă, fiabilă și sigură între serviciile de infrastructură de aplicații containerizate și adesea efemere. Service Mesh oferă capabilități precum descoperirea serviciului, echilibrarea încărcăturii, criptarea, transparența, trasabilitatea, autentificarea și autorizarea și suport pentru modele de oprire automată (întrerupător de circuit).
O rețea de servicii este de obicei implementată prin furnizarea fiecărei instanțe de serviciu cu o instanță proxy, numită Sidecar. Sidecar gestionează comunicațiile între servicii, monitorizează și rezolvă problemele de securitate, adică tot ceea ce poate fi extras din serviciile individuale. În acest fel, dezvoltatorii pot scrie, întreține și servi codul aplicației în servicii, iar administratorii de sistem pot lucra cu Service Mesh și rula aplicația.
Istio de la Google, IBM și Lyft este în prezent cea mai faimoasă arhitectură de rețea de servicii. Și Kubernetes, care a fost dezvoltat inițial la Google, este acum singurul cadru de orchestrare a containerelor susținut de Istio. Furnizorii încearcă să creeze versiuni de Istio acceptate comercial. Va fi interesant de văzut ce lucruri noi pot aduce în proiectul open source.
Cu toate acestea, Istio nu este singura opțiune, deoarece sunt dezvoltate alte implementări Service Mesh. Model sidecar proxy este cea mai populară implementare, după cum poate fi judecată de proiectele Buoyant, HashiCorp, Solo.io și altele. Există și arhitecturi alternative: setul de instrumente tehnologice Netflix este una dintre abordările în care funcționalitatea Service Mesh este implementată prin bibliotecile Ribbon, Hysterix, Eureka, Archaius, precum și platforme precum Azure Service Fabric.
Service Mesh are, de asemenea, propria terminologie pentru componentele și funcțiile de service:
- Cadru de orchestrare a containerelor. Pe măsură ce tot mai multe containere sunt adăugate la infrastructura aplicației, este nevoie de un instrument separat pentru monitorizarea și gestionarea containerelor - un cadru de orchestrare a containerelor. Kubernetes a ocupat ferm această nișă, atât de mult încât până și principalii săi concurenți Docker Swarm și Mesosphere DC/OS oferă integrarea cu Kubernetes ca alternativă.
- Servicii și instanțe (Kubernetes Pods). O instanță este o singură copie care rulează a unui microserviciu. Uneori, o singură instanță este un container. În Kubernetes, o instanță constă dintr-un grup mic de containere independente numite pod. Clienții accesează rareori o instanță sau un pod direct; mai des, accesează un serviciu, care este un set de instanțe sau pod-uri (replicate) identice, scalabile și tolerante la erori.
- Proxy Sidecar. Sidecar Proxy funcționează cu o singură instanță sau pod. Scopul Sidecar Proxy este să direcționeze sau să proxy traficul care vine din containerul cu care lucrează și să returneze traficul. Sidecar interacționează cu alți proxy Sidecar și este gestionat de un cadru de orchestrare. Multe implementări Service Mesh folosesc Sidecar Proxy pentru a intercepta și gestiona tot traficul din și dinspre o instanță sau pod.
- Descoperirea serviciului. Când o instanță trebuie să comunice cu un alt serviciu, trebuie să găsească (descopere) o instanță sănătoasă și disponibilă a celuilalt serviciu. De obicei, instanța efectuează căutări DNS. Cadrul de orchestrare a containerului menține o listă de instanțe care sunt gata să primească cereri și oferă o interfață pentru interogări DNS.
- Echilibrarea sarcinii. Majoritatea cadrelor de orchestrare a containerelor asigură echilibrarea sarcinii la nivelul 4 (transport). Service Mesh implementează o echilibrare a sarcinii mai complexă la nivelul 7 (nivel de aplicație), bogat în algoritmi și mai eficient în gestionarea traficului. Setările de echilibrare a încărcăturii pot fi modificate folosind API-ul, permițându-vă să orchestrați implementări albastru-verde sau canary.
- Criptare. Service Mesh poate cripta și decripta cererile și răspunsurile, eliminând această povară de pe servicii. Service Mesh poate îmbunătăți, de asemenea, performanța prin prioritizarea sau reutilizarea conexiunilor persistente existente, reducând nevoia de calcul costisitor pentru a crea conexiuni noi. Cea mai comună implementare a criptării traficului este TLS reciproc (mTLS), unde o infrastructură cu chei publice (PKI) generează și distribuie certificate și chei pentru a fi utilizate de către Sidecar Proxy.
- Autentificare și autorizare. Service Mesh poate autoriza și autentifica cererile făcute din exterior sau din interiorul aplicației, trimițând doar cereri validate către instanțe.
- Suport model de oprire automată. Suporturi Service Mesh , care izolează instanțele nesănătoase și apoi le readuce treptat la grupul de instanțe sănătoase atunci când este necesar.
Este apelată partea unei aplicații Service Mesh care gestionează traficul de rețea între instanțe Planul de date. Creați și implementați o configurație care controlează comportamentul Planul de date, se efectuează folosind un separat Planul de control. Planul de control de obicei include sau este conceput pentru a se conecta la un API, CLI sau GUI pentru a controla aplicația.
Planul de control din rețeaua de servicii distribuie configurația între proxy-ul Sidecar și planul de date.
Arhitectura Service Mesh este adesea folosită pentru a rezolva probleme operaționale complexe folosind containere și microservicii. Pionierii în domeniu sunt companii precum Lyft, Netflix și Twitter, care oferă servicii stabile milioanelor de utilizatori din întreaga lume. (). Pentru aplicațiile mai puțin solicitante, arhitecturile mai simple vor fi probabil suficiente.
Este puțin probabil ca arhitectura Service Mesh să fie vreodată răspunsul la toate problemele de operare și livrare a aplicațiilor. Arhitecții și dezvoltatorii au un arsenal imens de instrumente și doar unul dintre ele este un ciocan, care, printre multe sarcini, trebuie să rezolve doar una - baterea cuielor. , de exemplu, include mai multe modele diferite care oferă un continuum de abordări pentru rezolvarea problemelor folosind microservicii.
Elementele care se reunesc într-o arhitectură Service Mesh, cum ar fi NGINX, containere, Kubernetes și microservicii ca abordare arhitecturală, pot fi la fel de productive în implementările non-Service Mesh. De exemplu, Istio a fost conceput ca o arhitectură completă a rețelei de servicii, dar modularitatea sa înseamnă că dezvoltatorii pot selecta și implementa doar componentele tehnologice de care au nevoie. Având în vedere acest lucru, este important să dezvolți o înțelegere clară a conceptului Service Mesh, chiar dacă nu ești sigur că îl vei putea implementa pe deplin în aplicația ta.
Sursa: www.habr.com