Hej Habr! Vašoj pozornosti predstavljam prijevod članka Autor Matt Klein.
Ovaj put sam “htio i preveo” opis obje komponente servisne mreže, podatkovne ravnine i kontrolne ravnine. Ovaj opis mi se činio najrazumljivijim i najzanimljivijim, i što je najvažnije dovodi do razumijevanja "Je li to uopće potrebno?"
Kako je ideja o "Service mesh" postala sve popularnija tijekom posljednje dvije godine (Izvorni članak 10. listopada 2017.) i kako se broj sudionika u prostoru povećao, vidio sam razmjeran porast zbunjenosti među cijelim tehničku zajednicu o tome kako usporediti različita rješenja.
Situacija je najbolje sažeta sljedećim nizom tweetova koje sam napisao u srpnju:
Zbunjenost mrežne mreže #1: Linkerd ~ = Nginx ~ = Haproxy ~ = Envoy. Nijedan od njih nije ravan Istiu. Istio je nešto sasvim drugo. 1 /
Prvi su jednostavno podatkovne ravnine. Sami po sebi ne rade ništa. Sigurno su raspoloženi za nešto više. 2/
Istio je primjer kontrolne ravnine koja povezuje dijelove zajedno. Ovo je drugi sloj. /kraj
Prethodni tweetovi spominju nekoliko različitih projekata (Linkerd, NGINX, HAProxy, Envoy i Istio), ali što je još važnije predstavljaju opće koncepte podatkovne ravnine, servisne mreže i kontrolne ravnine. U ovom ću postu napraviti korak unatrag i govoriti o tome što mislim pod pojmovima "podatkovna razina" i "kontrolna razina" na vrlo visokoj razini, a zatim ću govoriti o tome kako se ti pojmovi primjenjuju na projekte spomenute u tweetovima.
Što je zapravo servisna mreža?
Slika 1: Pregled servisne mreže
Slika 1 ilustrira koncept servisne mreže na najosnovnijoj razini. Postoje četiri klastera usluga (AD). Svaka instanca usluge povezana je s lokalnim proxy poslužiteljem. Sav mrežni promet (HTTP, REST, gRPC, Redis itd.) iz jedne instance aplikacije prolazi kroz lokalni proxy do odgovarajućih klastera vanjskih usluga. Na ovaj način, instanca aplikacije nije svjesna mreže kao cjeline i svjesna je samo svog lokalnog proxyja. Zapravo, mreža distribuiranog sustava uklonjena je iz usluge.
Podatkovna ravnina
U servisnoj mreži, proxy poslužitelj smješten lokalno za aplikaciju obavlja sljedeće zadatke:
- Otkrivanje usluge. Koje su usluge/aplikacije dostupne za vašu aplikaciju?
- Provjera zdravlja. Jesu li instance usluge vraćene otkrivanjem usluge ispravne i spremne za prihvaćanje mrežnog prometa? To može uključivati i aktivne (npr. odgovor/zdravstvena provjera) i pasivne (npr. korištenje 3 uzastopne 5xx pogreške kao pokazatelja nezdravog stanja usluge) provjere ispravnosti.
- Usmjeravanje. Kada primite zahtjev za "/foo" od REST usluge, kojem klasteru usluga treba poslati zahtjev?
- Balansiranje opterećenja. Nakon što je klaster usluga odabran tijekom usmjeravanja, kojoj instanci usluge treba poslati zahtjev? S kojim timeoutom? S kojim postavkama prekida strujnog kruga? Ako zahtjev ne uspije, treba li pokušati ponovo?
- Autentifikacija i autorizacija. Za dolazne zahtjeve, može li se usluga pozivanja kriptografski identificirati/autorizirati pomoću mTLS-a ili nekog drugog mehanizma? Ako je prepoznat/autoriziran, je li dopušteno pozvati traženu operaciju (krajnju točku) na usluzi ili treba vratiti neautentificirani odgovor?
- Uočljivost. Detaljna statistika, zapisnici/dnevnici i podaci o distribuiranom praćenju trebaju se generirati za svaki zahtjev kako bi operateri mogli razumjeti distribuirani protok prometa i probleme s otklanjanjem pogrešaka čim se pojave.
Podatkovna ravnina odgovorna je za sve prethodne točke u servisnoj mreži. Zapravo, proxy lokalna usluga (sidecar) je podatkovna ravnina. Drugim riječima, podatkovna razina odgovorna je za uvjetno emitiranje, prosljeđivanje i praćenje svakog mrežnog paketa koji je poslan na ili iz usluge.
Kontrolna ravnina
Mrežna apstrakcija koju lokalni proxy pruža u podatkovnoj ravni je čarobna(?). Međutim, kako proxy zapravo zna za "/foo" rutu do usluge B? Kako se mogu koristiti podaci o otkrivanju usluge koji se popunjavaju proxy zahtjevima? Kako su konfigurirani parametri za uravnoteženje opterećenja, vremensko ograničenje, prekid strujnog kruga itd.? Kako implementirati aplikaciju koristeći plavo/zelenu metodu ili metodu elegantnog prijelaza prometa? Tko konfigurira postavke provjere autentičnosti i autorizacije za cijeli sustav?
Sve gore navedene stavke su pod kontrolom kontrolne ravnine servisne mreže. Kontrolna razina uzima skup izoliranih proxyja bez stanja i pretvara ih u distribuirani sustav.
Mislim da je razlog zašto mnogi tehnolozi smatraju da su odvojeni koncepti podatkovne i kontrolne ravni zbunjujući taj što je većini ljudi podatkovna razina poznata, dok je kontrolna razina strana/nerazumijeva. Dugo radimo s fizičkim mrežnim usmjerivačima i preklopnicima. Razumijemo da paketi/zahtjevi moraju ići od točke A do točke B i da za to možemo koristiti hardver i softver. Nova generacija softverskih proxyja jednostavno su otmjene verzije alata koje koristimo već dugo vremena.
Slika 2: Ljudska kontrolna ravnina
Međutim, već dugo koristimo kontrolne ravnine, iako većina mrežnih operatera možda ne povezuje ovaj dio sustava s bilo kojom tehnološkom komponentom. Razlog je jednostavan:
Većina kontrolnih zrakoplova koji se danas koriste smo... mi.
Na Slika 2 pokazuje ono što ja zovem "ljudska kontrolna ravnina". U ovoj vrsti implementacije, koja je još uvijek vrlo uobičajena, vjerojatno mrzovoljni ljudski operater stvara statičke konfiguracije - potencijalno putem skripti - i postavlja ih kroz neki poseban proces na sve proxy poslužitelje. Proxiji zatim počinju koristiti ovu konfiguraciju i počinju obrađivati podatkovnu razinu pomoću ažuriranih postavki.
Slika 3: Kontrolna ravnina napredne servisne mreže
Na Slika 3 prikazuje "proširenu" kontrolnu ravninu servisne mreže. Sastoji se od sljedećih dijelova:
- Čovjek: Još uvijek postoji osoba (nadam se manje ljuta) koja donosi odluke na visokoj razini u vezi sa cijelim sustavom u cjelini.
- UI upravljačke ravnine: Osoba komunicira s nekom vrstom korisničkog sučelja kako bi kontrolirala sustav. To može biti web portal, aplikacija naredbenog retka (CLI) ili neko drugo sučelje. Korištenjem korisničkog sučelja operater ima pristup globalnim parametrima konfiguracije sustava kao što su:
- Kontrola postavljanja, plavo/zeleno i/ili postupni prometni prijelaz
- Mogućnosti provjere autentičnosti i autorizacije
- Specifikacije tablice usmjeravanja, na primjer kada aplikacija A zatraži informacije o "/foo" što se događa
- Postavke balansera opterećenja, kao što su vremensko ograničenje, ponovni pokušaji, postavke prekida strujnog kruga itd.
- Planer radnog opterećenja: Usluge se pokreću na infrastrukturi putem neke vrste sustava za raspoređivanje/orkestriranje, kao što je Kubernetes ili Nomad. Planer je odgovoran za učitavanje usluge zajedno sa svojim lokalnim proxyjem.
- Otkrivanje usluge. Kada planer pokrene i zaustavi instance usluge, on prijavljuje status ispravnosti sustavu za otkrivanje usluge.
- Sidecar proxy konfiguracijski API-ji : Lokalni proxyji dinamički izdvajaju stanje iz različitih komponenti sustava koristeći na kraju dosljedan model bez intervencije operatera. Cijeli sustav, koji se sastoji od svih trenutno pokrenutih instanci usluge i lokalnih proxy poslužitelja, na kraju se spaja u jedan ekosustav. Envoyjev API univerzalne podatkovne ravnine jedan je primjer kako to funkcionira u praksi.
U biti, svrha kontrolne razine je postaviti politiku koja će na kraju biti prihvaćena od podatkovne ravnine. Naprednije kontrolne razine uklonit će više dijelova nekih sustava od operatera i zahtijevati manje ručnog rada, pod uvjetom da rade ispravno!...
Podatkovna i upravljačka ravnina. Sažetak podatkovne ravnine u odnosu na kontrolnu ravninu
- Podatkovna ravnina servisne mreže: Utječe na svaki paket/zahtjev u sustavu. Odgovoran za otkrivanje aplikacija/usluga, provjeru ispravnosti, usmjeravanje, balansiranje opterećenja, autentifikaciju/autorizaciju i vidljivost.
- Kontrolna ravnina servisne mreže: Pruža politiku i konfiguraciju za sve pokrenute podatkovne razine unutar servisne mreže. Ne dira nikakve pakete/zahtjeve na sustavu. Kontrolna ravnina pretvara sve podatkovne ravnine u distribuirani sustav.
Trenutačni pejzaž projekta
Nakon što smo razumjeli gornje objašnjenje, pogledajmo trenutno stanje projekta servisne mreže.
- Podatkovne ravnine: Linkerd, NGINX, HAProxy, Envoy, Traefik
- Kontrolne ravnine: Istio, Nelson, SmartStack
Umjesto da idem u dubinsku analizu svakog od gore navedenih rješenja, ukratko ću se pozabaviti nekim točkama za koje vjerujem da trenutno uzrokuju veliku zbrku u ekosustavu.
Linkerd je početkom 2016. bio jedan od prvih proxy poslužitelja podatkovne ravnine za servisnu mrežu i obavio je fantastičan posao podizanja svijesti i pozornosti na model dizajna servisne mreže. Oko 6 mjeseci nakon toga, Envoy se pridružio Linkerdu (iako je bio s Lyftom od kraja 2015.). Linkerd i Envoy su dva projekta koja se najčešće spominju kada se govori o servisnim mrežama.
Istio je najavljen u svibnju 2017. Ciljevi projekta Istio vrlo su slični proširenoj kontrolnoj ravni prikazanoj na Slika 3. Envoy za Istio je zadani proxy. Dakle, Istio je kontrolna ravan, a Envoy je podatkovna ravan. Istio je u kratkom vremenu izazvao veliko uzbuđenje, a drugi podatkovni planovi počeli su se integrirati kao zamjena za Envoy (i Linkerd i NGINX pokazali su integraciju s Istiom). Činjenica da se različite podatkovne ravnine mogu koristiti unutar iste kontrolne ravnine znači da kontrolna i podatkovna ravnina nisu nužno čvrsto povezane. API kao što je Envoyjev API generičke podatkovne ravnine može formirati most između dva dijela sustava.
Nelson i SmartStack pomažu dodatno ilustrirati odvajanje kontrolne ravnine i podatkovne ravnine. Nelson koristi Envoy kao svoj proxy i gradi pouzdanu kontrolnu ravninu za servisnu mrežu temeljenu na HashiCorp steku, tj. Nomad, itd. SmartStack je možda bio prvi u novom valu servisnih mreža. SmartStack gradi kontrolnu ravninu oko HAProxy-ja ili NGINX-a, demonstrirajući sposobnost odvajanja kontrolne ravnine od servisne mreže od podatkovne ravnine.
Mikroservisna arhitektura s servisnom mrežom dobiva sve više pozornosti (s pravom!), a sve više projekata i dobavljača počinje raditi u tom smjeru. Tijekom sljedećih nekoliko godina vidjet ćemo mnogo inovacija u podatkovnoj i upravljačkoj ravni, kao i daljnje miješanje različitih komponenti. U konačnici bi arhitektura mikroservisa trebala postati transparentnija i čarobnija (?) za operatera.
Nadajmo se sve manje iritirani.
Ključni podaci za van
- Servisna mreža sastoji se od dva različita dijela: podatkovne ravnine i kontrolne ravnine. Obje komponente su potrebne i bez njih sustav neće raditi.
- Svi su upoznati s kontrolnom ravninom, a u ovom trenutku, kontrolna ravnina biste mogli biti vi!
- Sve podatkovne razine međusobno se natječu u značajkama, performansama, mogućnostima konfiguracije i proširivosti.
- Sve se kontrolne razine natječu jedna s drugom u značajkama, mogućnostima konfiguracije, proširivosti i jednostavnosti korištenja.
- Jedna kontrolna ravnina može sadržavati prave apstrakcije i API-je tako da se može koristiti više podatkovnih ravnina.
Izvor: www.habr.com