Salut din nou!.. În ajunul începerii cursului am pregătit o altă traducere utilă.
Service Mesh este un nivel de infrastructură configurabil, cu latență scăzută, necesar pentru a gestiona un volum mare de comunicații între procesele din rețea, între interfețele programului aplicației (API-uri). Service Mesh asigură comunicații rapide, fiabile și sigure între serviciile containerizate și, adesea, efemere ale infrastructurii aplicațiilor. Service Mesh oferă capabilități precum descoperirea serviciilor, echilibrarea încărcăturii, criptarea, transparența, trasabilitatea, autentificarea și autorizarea, precum și suport pentru modelul de oprire automată (circuit breaker).
Service Mesh 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 elimină problemele de securitate, adică tot ceea ce poate fi abstractizat de serviciile individuale. Astfel, dezvoltatorii pot scrie, întreține și oferi suport pentru codul aplicației în servicii, iar administratorii de sistem pot lucra cu Service Mesh și lansa aplicația.
Istio de la Google, IBM și Lyft este în prezent cea mai cunoscută arhitectură Service Mesh. Kubernetes, care a fost inițial dezvoltat de Google, este acum singurul cadru de orchestrare a containerelor care este susținut de Istio. Vânzătorii încearcă să creeze versiuni comerciale susținute ale Istio. Este interesant ce noutăți vor putea aduce în proiectul open source.
Însă Istio nu este singura opțiune, deoarece sunt dezvoltate și alte implementări de Service Mesh. Modelul proxy sidecar este cea mai populară implementare, după cum se poate observa din proiectele Buoyant, HashiCorp, Solo.io și altele. Există și arhitecturi alternative: setul de instrumente tehnologice de la Netflix este una dintre abordări, unde funcționalitatea Service Mesh este realizată prin intermediul bibliotecilor Ribbon, Hysterix, Eureka, Archaius, precum și a unor platforme precum Azure Service Fabric.
Service Mesh are, de asemenea, propria sa terminologie pentru componentele serviciilor și funcțiile acestora:
- Cadru de orchestrare a containerelor. Pe măsură ce tot mai multe containeere sunt adăugate în infrastructura aplicației, apare necesitatea unui instrument dedicat pentru monitorizarea și gestionarea containerelor – un cadru de orchestrare a containerelor. Kubernetes a ocupat această nișă într-un mod atât de strâns, încât chiar și principalii săi concurenți, Docker Swarm și Mesosphere DC/OS, oferă ca alternativă integrarea cu Kubernetes.
- Servicii și instanțe (poduri Kubernetes). Instanța este o singură copie activă a unui microserviciu. Uneori, o instanță este un singur container. În Kubernetes, o instanță este constituită dintr-un grup mic de containere independente, numit pod. Clienții se adresează rar direct unei instanțe sau unui pod, de obicei, ei se adresează unui serviciu, care reprezintă un set de instanțe sau poduri (replici) identice, scalabile și rezistente la defecțiuni.
- Proxy Sidecar. Proxy Sidecar lucrează cu o singură instanță sau pod. Scopul Proxy-ului Sidecar este de a directiona sau a proxifica traficul venit de la containerul cu care lucrează și traficul de întoarcere. Sidecar interacționează cu alte Proxy-uri Sidecar și este gestionat de cadrul de orchestrare. Multe implementări de Service Mesh utilizează Proxy-uri Sidecar pentru a intercepta și gestiona tot traficul de intrare și ieșire al instanței sau pod-ului.
- Descoperirea serviciilor. Când o instanță trebuie să interacționeze cu un alt serviciu, aceasta trebuie să găsească (să descopere) o instanță funcțională și disponibilă a celuilalt serviciu. De regulă, instanța efectuează căutarea prin DNS. Cadrul de orchestrare a containerelor menține o listă de instanțe care sunt pregătite să primească cereri și oferă o interfață pentru solicitările DNS.
- Încărcarea echilibrată. Majoritatea cadrelor de orchestrare a containerelor oferă echilibrarea încărcării la nivelul 4 (transport). Service Mesh implementează o echilibrare a încărcării mai complexă la nivelul 7 (aplicație), bogată în algoritmi și mai eficientă în gestionarea traficului. Opțiunile de echilibrare a încărcării pot fi modificate prin API, ceea ce permite orchestrarea unei desfășurări blue-green sau canary.
- Criptare. Service Mesh poate cripta și decripta cererile și răspunsurile, eliminând această povară de pe servicii. De asemenea, Service Mesh poate îmbunătăți performanța prin prioritizarea sau reutilizarea conexiunilor persistente existente, ceea ce reduce necesitatea calculelor costisitoare pentru a crea noi conexiuni. Cea mai comună implementare a criptării traficului este mutual TLS (mTLS), unde infrastructura de chei publice (PKI) generează și distribuie certificate și chei pentru a fi utilizate în Sidecar Proxy.
- Autentificarea și autorizarea. Service Mesh poate autoriza și autentifica cereri făcute din exterior sau din interiorul aplicației, trimițând instanțelor doar cereri validate.
- Suport pentru modelul de oprire automată. Service Mesh suportă , care izolează instanțele nesănătoase și apoi le restabilește treptat în grupul de instanțe sănătoase, atunci când este necesar.
Partea aplicației Service Mesh care gestionează traficul de rețea între instanțe se numește Data Plane. Crearea și desfășurarea configurației care gestionează comportamentul Data Plane, se realizează cu ajutorul unei Control Plane. Control Plane de obicei include sau este proiectat pentru a se conecta la API, CLI sau GUI pentru gestionarea aplicației.
Control Plane în Service Mesh distribuie configurația între Sidecar Proxy și Data Plane.
Adesea, arhitectura Service Mesh este aplicată pentru a rezolva sarcini operaționale complexe folosind containere și microservicii. Pionierii din acest domeniu sunt companii precum Lyft, Netflix și Twitter, care oferă servicii care funcționează constant pentru milioane de utilizatori din întreaga lume. (). Pentru sarcini aplicaționale mai puțin exigente, cel mai probabil va fi suficient un set de arhitecturi mai simple.
Arhitectura Service Mesh nu va fi niciodată răspunsul la toate întrebările legate de funcționarea aplicațiilor și livrarea acestora. Arhitecții și dezvoltatorii dispun de un arsenal imens de instrumente, iar doar unul dintre ele este ciocanul, care, printre numeroasele sarcini, trebuie să rezolve doar una – să bată cuie. , de exemplu, include mai multe modele diferite care oferă un spectru continuu de abordări pentru rezolvarea problemelor cu ajutorul microserviciilor.
Elementele care se combină în arhitectura Service Mesh, cum ar fi NGINX, containerele, Kubernetes și microserviciile ca abordare arhitecturală, pot fi utilizate la fel de productiv și în implementările fără Service Mesh. De exemplu, Istio a fost dezvoltat ca o arhitectură completă Service Mesh, dar modularitatea indică faptul că dezvoltatorii pot alege și aplica doar componentele tehnologice de care au nevoie. Ținând cont de acest lucru, este necesar să formăm o înțelegere clară a conceptului Service Mesh, chiar dacă nu sunteți sigur că veți putea vreodată să îl implementați pe deplin în aplicația dumneavoastră.
Sursa: habr.com
