Bună, Habr! Vă prezint atenției o traducere a articolului „Planul de date cu plasă de serviciu vs planul de control” autor Matt Klein.

De data aceasta, am „dorit și tradus” descrierea ambelor componente ale rețelei de serviciu, planul de date și planul de control. Această descriere mi s-a părut cea mai înțeleasă și interesantă și, cel mai important, a condus la înțelegerea „Este necesar deloc?”

Pe măsură ce ideea de „Mesh de serviciu” a devenit din ce în ce mai populară în ultimii doi ani (Articol original 10 octombrie 2017) și numărul participanților în spațiu a crescut, am observat o creștere proporțională a confuziei în rândul întregului comunitatea tehnologică cu privire la modul de comparare și contrastare a diferitelor soluții.

Situația este cel mai bine rezumată în următoarea serie de tweet-uri pe care le-am scris în iulie:

Confuzia de plasă de serviciu #1: Linkerd ~ = Nginx ~ = Haproxy ~ = Envoy. Niciunul dintre ei nu este egal cu Istio. Istio este cu totul altceva. 1 /

Primele sunt pur și simplu avioane de date. De la sine nu fac nimic. Trebuie să aibă chef de ceva mai mult. 2/

Istio este un exemplu de plan de control care leagă piesele împreună. Acesta este un alt strat. /Sfârşit

Tweeturile anterioare menționează mai multe proiecte diferite (Linkerd, NGINX, HAProxy, Envoy și Istio), dar, mai important, introduc conceptele generale de plan de date, rețea de serviciu și plan de control. În această postare, voi face un pas înapoi și voi vorbi despre ceea ce vreau să spun prin termenii „plan de date” și „plan de control” la un nivel foarte înalt, apoi voi vorbi despre modul în care termenii se aplică proiectelor menționate în tweet-uri.

Ce este o plasă de serviciu, de fapt?

Figura 1: Prezentare generală a rețelei de service

Figura 1 ilustrează conceptul de plasă de serviciu la nivelul său cel mai de bază. Există patru clustere de servicii (AD). Fiecare instanță de serviciu este asociată cu un server proxy local. Tot traficul de rețea (HTTP, REST, gRPC, Redis etc.) de la o singură instanță de aplicație este transmis printr-un proxy local către clusterele de servicii externe corespunzătoare. În acest fel, instanța aplicației nu este conștientă de rețea în ansamblu și numai de proxy-ul local. De fapt, rețeaua sistemului distribuit a fost eliminată din serviciu.

Planul de date

Într-o plasă de servicii, un server proxy situat local pentru aplicație îndeplinește următoarele sarcini:

• Descoperirea serviciului. Ce servicii/aplicații sunt disponibile pentru aplicația dvs.?
• Verificarea sănătății. Instanțele de serviciu returnate de descoperirea serviciului sunt sănătoase și gata să accepte trafic de rețea? Aceasta poate include atât controale de sănătate active (de exemplu răspuns/verificare de sănătate) cât și pasive (de exemplu, utilizarea a 3 erori consecutive 5xx ca indicație a unei stări nesănătoase a serviciului).
• Dirijare. Când primiți o solicitare către „/foo” de la un serviciu REST, către ce cluster de servicii ar trebui trimisă cererea?
• Echilibrarea sarcinii. Odată ce un cluster de servicii a fost selectat în timpul rutării, la ce instanță de serviciu trebuie trimisă cererea? Cu ce ​​timeout? Cu ce ​​setări de întrerupere a circuitului? Dacă cererea eșuează, ar trebui reîncercată?
• Autentificare și autorizare. Pentru cererile primite, serviciul de apelare poate fi identificat/autorizat criptografic folosind mTLS sau alt mecanism? Dacă este recunoscut/autorizat, este permis să apeleze operațiunea solicitată (punctul final) pe serviciu sau ar trebui returnat un răspuns neautentificat?
• Observabilitate. Pentru fiecare solicitare ar trebui generate statistici detaliate, jurnalele/jurnalele și datele de urmărire distribuite, astfel încât operatorii să poată înțelege fluxul de trafic distribuit și problemele de depanare pe măsură ce apar.

Planul de date este responsabil pentru toate punctele anterioare din rețeaua de serviciu. De fapt, proxy-ul local al serviciului (sidecar) este planul de date. Cu alte cuvinte, planul de date este responsabil pentru difuzarea condiționată, redirecționarea și monitorizarea fiecărui pachet de rețea care este trimis către sau de la un serviciu.

Planul de control

Abstracția rețelei pe care o oferă un proxy local în planul de date este magică(?). Cu toate acestea, de unde știe proxy-ul despre ruta „/foo” către serviciul B? Cum pot fi utilizate datele de descoperire a serviciului care sunt populate de solicitările proxy? Cum sunt configurați parametrii pentru echilibrarea sarcinii, timeout, întreruperea circuitului etc.? Cum implementați o aplicație folosind metoda albastru/verde sau metoda de tranziție grațioasă a traficului? Cine configurează setările de autentificare și autorizare la nivel de sistem?

Toate elementele de mai sus sunt sub controlul planului de control al rețelei de serviciu. Planul de control preia un set de proxy apatrizi izolați și le transformă într-un sistem distribuit.

Cred că motivul pentru care mulți tehnologi consideră confuze conceptele separate de plan de date și plan de control este pentru că pentru majoritatea oamenilor planul de date este familiar, în timp ce planul de control este străin/neînțeles. Lucrăm de mult timp cu routere și switch-uri fizice de rețea. Înțelegem că pachetele/cererile trebuie să treacă de la punctul A la punctul B și că putem folosi hardware și software pentru a face acest lucru. Noua generație de proxy software sunt pur și simplu versiuni de lux ale instrumentelor pe care le folosim de mult timp.

Figura 2: Planul de control uman

Cu toate acestea, folosim avioane de control de mult timp, deși majoritatea operatorilor de rețea ar putea să nu asocieze această parte a sistemului cu nicio componentă tehnologică. Motivul este simplu:
Cele mai multe avioane de control folosite astăzi sunt... noi.

Pe Figura 2 arată ceea ce eu numesc „planul de control uman”. În acest tip de implementare, care este încă foarte comun, un operator uman probabil morocănos creează configurații statice - potențial prin scripturi - și le implementează printr-un proces special tuturor proxy-urilor. Apoi, proxy-urile încep să utilizeze această configurație și încep să proceseze planul de date folosind setările actualizate.

Figura 3: Planul de control al rețelei de servicii avansate

Pe Figura 3 arată planul de control „extins” al rețelei de serviciu. Este format din următoarele părți:

• Omul: Mai există o persoană (sperăm mai puțin supărată) care ia decizii la nivel înalt cu privire la întregul sistem în ansamblu.
• Interfața de utilizare a planului de control: O persoană interacționează cu un anumit tip de interfață cu utilizatorul pentru a controla sistemul. Acesta ar putea fi un portal web, o aplicație de linie de comandă (CLI) sau o altă interfață. Utilizând interfața cu utilizatorul, operatorul are acces la parametrii globali de configurare a sistemului, cum ar fi:
  • Controlul implementării, tranziția traficului albastru/verde și/sau treptat
  • Opțiuni de autentificare și autorizare
  • Specificațiile tabelului de rutare, de exemplu atunci când aplicația A solicită informații despre „/foo” ce se întâmplă
  • Setări de echilibrare a sarcinii, cum ar fi timeout-uri, reîncercări, setări de întrerupere a circuitului etc.
• Programator de sarcină de lucru: Serviciile rulează pe infrastructură printr-un anumit tip de sistem de programare/orchestrare, cum ar fi Kubernetes sau Nomad. Programatorul este responsabil pentru încărcarea serviciului împreună cu proxy-ul local.
• Descoperirea serviciului. Când planificatorul pornește și oprește instanțe de serviciu, acesta raportează starea de sănătate către sistemul de descoperire a serviciului.
• API-uri de configurare proxy Sidecar : proxy-urile locale extrag în mod dinamic starea din diferite componente ale sistemului folosind un model coerent în cele din urmă fără intervenția operatorului. Întregul sistem, constând din toate instanțele de servicii care rulează în prezent și serverele proxy locale, converge în cele din urmă într-un singur ecosistem. API-ul universal pentru planul de date al lui Envoy este un exemplu al modului în care funcționează acest lucru în practică.

În esență, scopul planului de control este de a stabili politica care va fi acceptată în cele din urmă de planul de date. Avioane de control mai avansate vor elimina de la operator mai multe părți ale unor sisteme și vor necesita mai puțină operare manuală, cu condiția să funcționeze corect!...

Planul de date și planul de control. Rezumatul planului de date vs. planului de control

• Plan de date cu plasă de serviciu: Afectează fiecare pachet/cerere din sistem. Responsabil pentru descoperirea aplicației/serviciului, verificarea stării de sănătate, rutare, echilibrarea încărcăturii, autentificare/autorizare și observabilitate.
• Plan de control al plasei de serviciu: Oferă politică și configurație pentru toate planurile de date care rulează în rețeaua de servicii. Nu atinge niciun pachet/cereri din sistem. Planul de control transformă toate planurile de date într-un sistem distribuit.

Peisajul actual al proiectului

După ce am înțeles explicația de mai sus, să ne uităm la starea actuală a proiectului de plasă de servicii.

• Avioane de date: Linkerd, NGINX, HAProxy, Envoy, Traefik
• Avioane de control: Istio, Nelson, SmartStack

În loc să intru într-o analiză aprofundată a fiecăreia dintre soluțiile de mai sus, voi aborda pe scurt câteva dintre punctele care cred că provoacă o mare parte a confuziei în ecosistem chiar acum.

Linkerd a fost unul dintre primele servere proxy pentru planul de date pentru rețeaua de servicii la începutul anului 2016 și a făcut o treabă fantastică în creșterea gradului de conștientizare și a atenției asupra modelului de proiectare a rețelei de servicii. La aproximativ 6 luni după aceea, Envoy s-a alăturat lui Linkerd (deși era cu Lyft de la sfârșitul anului 2015). Linkerd și Envoy sunt cele două proiecte care sunt cel mai des menționate atunci când discutăm despre rețelele de servicii.

Istio a fost anunțat în mai 2017. Obiectivele proiectului Istio sunt foarte asemănătoare cu planul de control extins prezentat în Figura 3. Envoy pentru Istio este proxy-ul implicit. Astfel, Istio este planul de control, iar Envoy este planul de date. În scurt timp, Istio a generat multă entuziasm și alte avioane de date au început să se integreze ca înlocuitor pentru Envoy (atât Linkerd, cât și NGINX au demonstrat integrarea cu Istio). Faptul că diferite planuri de date pot fi utilizate în cadrul aceluiași plan de control înseamnă că planul de control și planul de date nu sunt neapărat strâns cuplate. Un API, cum ar fi API-ul pentru planul de date generic al lui Envoy, poate forma o punte între două părți ale sistemului.

Nelson și SmartStack ajută la ilustrarea suplimentară a separării planului de control și a planului de date. Nelson folosește Envoy ca proxy și construiește un plan de control fiabil pentru rețeaua de servicii bazată pe stiva HashiCorp, de exemplu. Nomad, etc. SmartStack a fost probabil primul dintr-un nou val de rețele de servicii. SmartStack construiește un plan de control în jurul HAProxy sau NGINX, demonstrând capacitatea de a decupla planul de control de rețeaua de serviciu de planul de date.

Arhitectura de microservicii cu o plasă de servicii câștigă din ce în ce mai multă atenție (pe bună dreptate!), iar tot mai multe proiecte și furnizori încep să lucreze în această direcție. În următorii câțiva ani, vom vedea o mulțime de inovații atât în ​​planul de date, cât și în planul de control, precum și amestecarea în continuare a diferitelor componente. În cele din urmă, arhitectura de microservicii ar trebui să devină mai transparentă și mai magică (?) pentru operator.
Sper că din ce în ce mai puțin iritați.

Recomandări cheie

• O plasă de serviciu constă din două părți diferite: planul de date și planul de control. Ambele componente sunt necesare și fără ele sistemul nu va funcționa.
• Toată lumea este familiarizată cu planul de control și, în acest moment, planul de control ai putea fi tu!
• Toate planurile de date concurează între ele în funcție de caracteristici, performanță, configurabilitate și extensibilitate.
• Toate planurile de control concurează între ele în funcții, configurabilitate, extensibilitate și ușurință în utilizare.
• Un singur plan de control poate conține abstracțiile și API-urile potrivite, astfel încât să poată fi utilizate mai multe planuri de date.

Sursa: www.habr.com