Ehi Habr! Prestu à a vostra attenzione a traduzzione di l'articulu autore Matt Klein.
Sta volta, aghju "vulutu è traduttu" a descrizzione di i dui cumpunenti di rete di serviziu, u pianu di dati è u pianu di cuntrollu. Sta descrizzione mi pareva a più comprensibile è interessante, è u più impurtante chì porta à a cunniscenza di "Hè necessariu in tuttu?"
Siccomu l'idea di una "Maglia di serviziu" hè diventata sempri più populari in l'ultimi dui anni (Articulu originale 10 d'ottobre 2017) è u numeru di i participanti in u spaziu hè aumentatu, aghju vistu un aumentu proporzionale di cunfusione in tuttu u mondu. cumunità tecnologica in quantu à paragunà è cuntrastà diverse soluzioni.
A situazione hè megliu riassunta da a seguente serie di tweets chì aghju scrittu in lugliu:
Confusione di rete di serviziu #1: Linkerd ~ = Nginx ~ = Haproxy ~ = Envoy. Nisunu d'elli sò uguali à Istio. Istio hè qualcosa di completamente diversu. 1/
I primi sò solu piani di dati. Per elli stessi ùn facenu nunda. Deve esse in umore per qualcosa di più. 2/
Istio hè un esempiu di un pianu di cuntrollu chì unisce e parti. Questu hè un altru stratu. / fine
I tweets precedenti menzionanu parechji prughjetti diffirenti (Linkerd, NGINX, HAProxy, Envoy, è Istio), ma più importantemente introducenu i cuncetti generali di u pianu di dati, a rete di serviziu è u pianu di cuntrollu. In questu post, faraghju un passu in daretu è parleraghju di ciò chì vogliu dì cù i termini "pianu di dati" è "aviò di cuntrollu" à un livellu assai altu, è poi parlerà di cumu i termini s'applicanu à i prughjetti citati in i tweets.
Chì ghjè una rete di serviziu, veramente?
Figura 1: Panoramica di a rete di serviziu
Disegnu 1 illustra u cuncettu di una rete di serviziu à u so livellu più basicu. Ci sò quattru gruppi di serviziu (AD). Ogni istanza di serviziu hè assuciata à un servitore proxy locale. Tuttu u trafficu di a rete (HTTP, REST, gRPC, Redis, etc.) da una sola istanza di l'applicazione hè passatu per un proxy locale à i clusters di servizii esterni appropritati. In questu modu, l'istanza di l'applicazione ùn hè micca cunnisciuta di a reta cum'è un sanu è cunnosci solu di u so proxy lucale. In effetti, a reta di u sistema distribuitu hè stata eliminata da u serviziu.
Pianu di dati
In una rete di serviziu, un servitore proxy situatu in u locu per l'applicazione esegue e seguenti attività:
- Scuperta di serviziu. Chì servizii / applicazioni sò dispunibili per a vostra applicazione?
- Cuntrolla di salute. Sò l'istanze di serviziu restituite da a scuperta di serviziu sani è pronti per accettà u trafficu di a rete? Questu pò include sia attivi (per esempiu risposta / cuntrolu di salute) è passivi (per esempiu utilizendu 3 errori consecutivi 5xx cum'è indicazione di un statu di serviziu malsanu) cuntrolli di salute.
- Routing. Quandu riceve una dumanda à "/foo" da un serviziu REST, à quale cluster di serviziu deve esse mandatu a dumanda?
- Equilibratu di carica. Una volta chì un cluster di serviziu hè statu sceltu durante u routing, à quale istanza di serviziu deve esse mandata a dumanda? Cù chì timeout? Cù quali paràmetri di circuit breaking? Se a dumanda falla, deve esse ripruvata?
- Autentificazione è auturizazione. Per e dumande entrate, u serviziu di chjama pò esse identificatu / autorizatu criptograficamente cù mTLS o un altru mecanismu? S'ellu hè ricunnisciutu / autorizatu, hè permessu di chjamà l'operazione dumandata (endpoint) nantu à u serviziu o deve esse restituita una risposta micca autenticata?
- Osservabilità. Statistiche dettagliate, logs / logs, è dati di traccia distribuiti devenu esse generati per ogni dumanda in modu chì l'operatori ponu capisce u flussu di trafficu distribuitu è i prublemi di debugging quandu si sviluppanu.
U pianu di dati hè rispunsevule per tutti i punti precedenti in a rete di serviziu. In fattu, u proxy locale à u serviziu (sidecar) hè u pianu di dati. In altri palori, u pianu di dati hè rispunsevuli di trasmette in cundizzioni, invià è monitorà ogni pacchettu di rete chì hè mandatu à o da un serviziu.
U pianu di cuntrollu
L'astrazione di a rete chì un proxy locale furnisce in u pianu di dati hè magicu (?). Tuttavia, cumu u proxy cunnosce veramente a strada "/foo" à u serviziu B? Cumu ponu esse utilizati i dati di scuperta di serviziu chì sò populati da e dumande di proxy? Cumu sò i paràmetri cunfigurati per l'equilibriu di carica, timeout, circuit breaking, etc.? Cumu implementà una applicazione cù u metudu blu / verde o u metudu di transizione di trafficu graziosu? Quale cunfigura i paràmetri di l'autentificazione è l'autorizazione in tuttu u sistema?
Tutti l'articuli sopra sò sottu à u cuntrollu di u pianu di cuntrollu di a rete di serviziu. U pianu di cuntrollu piglia un inseme di proxy senza statu isolati è li trasforma in un sistema distribuitu.
Pensu chì a raghjoni chì parechji tecnulugichi trovanu i cuncetti separati di u pianu di dati è u pianu di cuntrollu cunfusu hè perchè per a maiò parte di a ghjente, u pianu di dati hè familiarizatu mentre u pianu di cuntrollu hè straneru / incomprisu. Avemu travagliatu cù routers è switches di rete fisica per un bellu pezzu. Capemu chì i pacchetti / richieste anu da andà da u puntu A à u puntu B è chì pudemu usà hardware è software per fà questu. A nova generazione di proxy software sò solu versioni fantastiche di l'arnesi chì avemu usatu per un bellu pezzu.
Figura 2: Pianu di cuntrollu umanu
In ogni casu, avemu usatu piani di cuntrollu per un bellu pezzu, ancu s'è a maiò parte di l'operatori di rete ùn ponu micca assuciatu sta parte di u sistema cù qualsiasi cumpunente di tecnulugia. U mutivu hè simplice:
A maiò parte di i piani di cuntrollu in usu oghje sò... noi.
nantu Figura 2 mostra ciò chì chjamu u "pianu di cuntrollu umanu". In questu tipu di implementazione, chì hè sempre assai cumuna, un operatore umanu prubabilmente grumpy crea cunfigurazioni statiche - potenzalmentu via scripts - è li implementa attraversu un prucessu speciale à tutti i proxy. I proxy allora cumincianu à aduprà sta cunfigurazione è cumincianu à trasfurmà u pianu di dati utilizendu i paràmetri aghjurnati.
Figura 3: Pianu di cuntrollu di maglia di serviziu avanzatu
nantu Figura 3 mostra u pianu di cuntrollu "estesa" di a rete di serviziu. Hè custituitu di e seguenti parti:
- U umanu: Ci hè sempre una persona (sperendu menu arrabbiata) chì face decisioni d'altu livellu in quantu à tuttu u sistema in tuttu.
- UI di u pianu di cuntrollu: Una persona interagisce cù qualchì tipu d'interfaccia d'utilizatore per cuntrullà u sistema. Questu puderia esse un portale web, una applicazione di linea di cumanda (CLI), o una altra interfaccia. Utilizendu l'interfaccia d'utilizatore, l'operatore hà accessu à i paràmetri di cunfigurazione di u sistema globale cum'è:
- Cuntrolu di implementazione, transizione di trafficu blu / verde è / o graduale
- Opzioni di autenticazione è d'autorizazione
- Specificazioni di a tabella di routing, per esempiu quandu l'applicazione A dumanda infurmazione nantu à "/foo" ciò chì succede
- Paràmetri di equilibriu di carica, cum'è timeouts, retry, paràmetri di circuit breaking, etc.
- Pianificatore di carichi di travagliu: I servizii sò eseguiti nantu à l'infrastruttura attraversu qualchì tipu di sistema di pianificazione / orchestrazione, cum'è Kubernetes o Nomad. U pianificatore hè rispunsevule per carricà u serviziu cù u so proxy lucale.
- Scuperta di serviziu. Quandu u pianificatore principia è ferma l'istanze di serviziu, informa u statu di salute à u sistema di scuperta di serviziu.
- API di cunfigurazione di proxy sidecar : I proxy lucali estrae dinamicamente u statu da diversi cumpunenti di u sistema utilizendu un mudellu eventualmente coherente senza intervenzione di l'operatore. Tuttu u sistema, custituitu da tutte l'istanze di serviziu attualmente in esecuzione è i servitori proxy lucali, infine cunverge in un ecosistema. L'API universale di u pianu di dati Envoy hè un esempiu di cumu funziona in pratica.
Essenzialmente, u scopu di u pianu di cuntrollu hè di stabilisce a pulitica chì ultimamente serà accettata da u pianu di dati. I piani di cuntrollu più avanzati sguassate più parte di certi sistemi da l'operatore è necessitanu menu operazione manuale, sempre chì travaglianu bè!...
Pianu di dati è pianu di cuntrollu. Riassuntu di u pianu di dati versus u pianu di cuntrollu
- Pianu di dati di rete di serviziu: Affetta ogni pacchettu / dumanda in u sistema. Responsabile per a scuperta di l'applicazione / serviziu, u cuntrollu di a salute, u routing, l'equilibriu di carica, l'autentificazione / l'autorizazione è l'osservabilità.
- Pianu di cuntrollu di rete di serviziu: Fornisce pulitica è cunfigurazione per tutti i piani di dati in esecuzione in a reta di serviziu. Ùn tocca micca i pacchetti / dumande nantu à u sistema. U pianu di cuntrollu trasforma tutti i piani di dati in un sistema distribuitu.
U paisaghju di u prughjettu attuale
Dopu avè capitu a spiegazione sopra, fighjemu u statu attuale di u prughjettu di a rete di serviziu.
- I piani di dati: Linkerd, NGINX, HAProxy, Envoy, Traefik
- I piani di cuntrollu: Istio, Nelson, SmartStack
Piuttostu chè entre in un'analisi approfondita di ognuna di e soluzioni sopra, aghju da indirizzà brevemente alcuni di i punti chì crede chì causanu assai di a cunfusione in l'ecosistema avà.
Linkerd era unu di i primi servitori proxy di u pianu di dati per a rete di serviziu à principiu di 2016 è hà fattu un travagliu fantasticu per sensibilizà è attente à u mudellu di design di rete di serviziu. Circa 6 mesi dopu, Envoy s'unì à Linkerd (ancu era statu cù Lyft da a fine di u 2015). Linkerd è Envoy sò i dui prughjetti chì sò più spessu citati in discussione di e rete di serviziu.
Istio hè statu annunziatu in maghju 2017. I scopi di u prughjettu Istio sò assai simili à u pianu di cuntrollu allargatu mostratu in Figura 3. Envoy for Istio hè u proxy predeterminatu. Cusì, Istio hè u pianu di cuntrollu, è Envoy hè u pianu di dati. In pocu tempu, Istio hà generatu assai eccitazione, è altri piani di dati cuminciaru à integrà cum'è un sustitutu di Envoy (sia Linkerd è NGINX dimustratu integrazione cù Istio). U fattu chì diversi piani di dati ponu esse aduprati in u stessu pianu di cuntrollu significa chì u pianu di cuntrollu è u pianu di dati ùn sò micca necessariamente strettamente accoppiati. Un API cum'è l'API di u pianu di dati genericu di Envoy pò furmà un ponte trà duie parti di u sistema.
Nelson è SmartStack aiutanu à illustrà più a separazione di u pianu di cuntrollu è u pianu di dati. Nelson usa Envoy cum'è u so proxy è custruisce un pianu di cuntrollu affidabile per a rete di serviziu basatu annantu à a pila HashiCorp, i.e. Nomade, ecc. SmartStack era forse u primu di una nova onda di rete di serviziu. SmartStack custruisce un pianu di cuntrollu intornu à HAProxy o NGINX, dimustrendu a capacità di disaccoppià u pianu di cuntrollu da a rete di serviziu da u pianu di dati.
L'architettura di u microserviziu cù una maglia di serviziu riceve più è più attenzione (ghjustu!), è più prughjetti è venditori cumincianu à travaglià in questa direzzione. In i prossimi anni, vedemu assai innuvazioni in u pianu di dati è in u pianu di cuntrollu, è ancu in più mischjà e diverse cumpunenti. In ultimamente, l'architettura di microserviziu deve diventà più trasparente è magica (?) per l'operatore.
Spergu di menu è menu irritati.
Pigliate chjave
- Una maglia di serviziu hè custituita da dui parti diffirenti: u pianu di dati è u pianu di cuntrollu. I dui cumpunenti sò necessarii, è senza elli u sistema ùn funziona micca.
- Tutti sò familiarizati cù u pianu di cuntrollu, è à questu puntu, u pianu di cuntrollu puderia esse voi!
- Tutti i piani di dati cumpetenu l'una cù l'altri nantu à e caratteristiche, prestazioni, cunfigurabilità è estensibilità.
- Tutti i piani di cuntrollu cumpetenu cù l'altri in caratteristiche, cunfigurabilità, estensibilità è facilità d'utilizazione.
- Un pianu di cuntrollu pò cuntene l'astrazioni ghjustificate è l'API per chì parechji piani di dati ponu esse utilizati.
Source: www.habr.com