Hoi Habr! Ik presintearje jo oandacht de oersetting fan it artikel skriuwer Matt Klein.
Dizze kear haw ik de beskriuwing fan beide tsjinstmesh-komponinten, gegevensfleantúch en kontrôlefleanmasine "wolle en oerset". Dizze beskriuwing like my de meast begryplike en ynteressante, en it wichtichste liedt ta it begryp fan "Is it überhaupt nedich?"
Om't it idee fan in "Service mesh" yn 'e lêste twa jier hieltyd populêrder wurden is (Oarspronklik artikel 10 oktober 2017) en it oantal dielnimmers yn' e romte is tanommen, haw ik in evenredige ferheging fan betizing sjoen ûnder de heule tech-mienskip oangeande hoe't jo ferskate oplossingen kinne fergelykje en kontrastearje.
De situaasje wurdt it bêste gearfette troch de folgjende searje tweets dy't ik yn july skreau:
Tsjinstmesh-ferwarring #1: Linkerd ~ = Nginx ~ = Haproxy ~ = Envoy. Gjin fan harren is gelyk oan Istio. Istio is wat folslein oars. 1 /
De earste binne gewoan gegevensfleantugen. Ut harsels dogge se neat. Se moatte yn 'e stimming wêze foar wat mear. 2/
Istio is in foarbyld fan in kontrôle fleantúch dat bûn de dielen byinoar. Dit is in oare laach. /ein
De foarige tweets neame ferskate ferskillende projekten (Linkerd, NGINX, HAProxy, Envoy, en Istio), mar wichtiger yntrodusearje de algemiene begripen fan gegevensfleantúch, tsjinstmesh en kontrôlefleanmasine. Yn dizze post sil ik in stap werom nimme en prate oer wat ik bedoel mei de termen "datafleantúch" en "kontrôlefleantúch" op in heul heech nivo, en dan prate oer hoe't de betingsten jilde foar de projekten neamd yn tweets.
Wat is in tsjinstmesh, echt?
figuer 1: Service mesh oersjoch
Ofbylding 1 yllustrearret it konsept fan in tsjinstmesh op syn meast basale nivo. D'r binne fjouwer tsjinstklusters (AD). Elke tsjinst eksimplaar is ferbûn mei in lokale proxy-tsjinner. Alle netwurkferkear (HTTP, REST, gRPC, Redis, ensfh.) Fan in inkele applikaasje-eksimplaar wurdt troch in lokale proxy trochjûn nei de passende eksterne tsjinstklusters. Op dizze manier is de applikaasje-eksimplaar net bewust fan it netwurk as gehiel en allinich bewust fan syn lokale proxy. Yn feite waard it ferspraat systeemnetwurk fan 'e tsjinst fuortsmiten.
Data fleantúch
Yn in tsjinstmesh fiert in proxy-tsjinner lokaal foar de applikaasje de folgjende taken:
- Service ûntdekking. Hokker tsjinsten/applikaasjes binne beskikber foar jo applikaasje?
- Health kontrôle. Binne de tsjinstynstânsjes weromjûn troch tsjinstûntdekking sûn en ree om netwurkferkear te akseptearjen? Dit kin sawol aktive (bgl
- Routing. By it ûntfangen fan in fersyk oan "/ foo" fan in REST-tsjinst, nei hokker tsjinstkluster moat it fersyk stjoerd wurde?
- Load balancing. Nei hokker tsjinsteksimplaar moat it fersyk stjoerd wurde as ienris in tsjinstkluster selektearre is by routing? Mei hokker timeout? Mei hokker circuit breaking ynstellings? As it fersyk mislearret, moat it dan opnij besocht wurde?
- Autentikaasje en autorisaasje. Foar ynkommende oanfragen, kin de oproptsjinst kryptografysk identifisearre / autorisearre wurde mei mTLS as in oar meganisme? As it wurdt werkend / autorisearre, is it tastien te roppen de frege operaasje (einpunt) op 'e tsjinst of moat in net authentisearre antwurd wurde weromjûn?
- Observabiliteit. Detaillearre statistiken, logs / logs, en ferspraat spoargegevens moatte wurde generearre foar elke oanfraach, sadat operators ferdielde ferkearsstream en debuggen kinne begripe as se ûntsteane.
It gegevensfleantúch is ferantwurdlik foar alle foarige punten yn it tsjinstmesh. Yn feite is de proxy lokaal foar de tsjinst (sidecar) it gegevensfleantúch. Mei oare wurden, it gegevensfleantúch is ferantwurdlik foar betingst útstjoeren, trochstjoeren en kontrolearjen fan elk netwurkpakket dat nei of fan in tsjinst wurdt stjoerd.
De kontrôle fleanmasine
It netwurk abstraksje dat in lokale proxy jout yn it gegevens fleantúch is magysk (?). Hoe wit de proxy lykwols eins oer de "/foo" rûte nei tsjinst B? Hoe kinne de tsjinstûntdekkingsgegevens dy't wurde befolke troch proxy-oanfragen wurde brûkt? Hoe binne de parameters ynsteld foar load balancing, timeout, circuit breaking, ensfh? Hoe kinne jo in applikaasje ynsette mei de blauwe / griene metoade as de sierlike metoade foar ferkearstransysje? Wa konfigurearret systeem-wide autentikaasje- en autorisaasjeynstellingen?
Alle boppesteande items binne ûnder de kontrôle fan it kontrôlefleanmasine fan it tsjinstmesh. It kontrôleflak ûntfangt in set isolearre proxy'sservers steatleas en feroaret se yn in ferspraat systeem.
Ik tink dat de reden dat in protte technologen de aparte begripen fan gegevensfleantúch en kontrôlefleanmasine betiizjend fine, is om't foar de measte minsken it gegevensfleantúch bekend is, wylst it kontrôlefleantúch frjemd is / net begrepen. Wy hawwe in lange tiid wurke mei fysike netwurkrouters en switches. Wy begripe dat pakketten/oanfragen moatte gean fan punt A nei punt B en dat wy hardware en software kinne brûke om dit te dwaan. De nije generaasje softwareproxy's binne gewoan fancy ferzjes fan 'e ark dy't wy in lange tiid hawwe brûkt.
figuer 2: Human control plane
Lykwols, wy hawwe brûkt kontrôle fleantugen foar in lange tiid, hoewol't de measte netwurk operators meie net assosjearje dit diel fan it systeem mei in technology komponint. De reden is simpel:
De measte kontrôle fleantugen yn gebrûk hjoed binne ... wy.
op Figuer 2 lit sjen wat ik it "Minsklike kontrôlefleantúch neam." Yn dit type ynset, dat noch altyd heul gewoan is, makket in wierskynlik norsige minsklike operator statyske konfiguraasjes - mooglik fia skripts - en set se yn troch wat spesjaal proses nei alle proxy's. De proxy's begjinne dan dizze konfiguraasje te brûken en begjinne it gegevensfleantúch te ferwurkjen mei de bywurke ynstellings.
figuer 3: Avansearre tsjinst mesh kontrôle fleanmasine
op Figuer 3 toant de "útwreide" kontrôle fleanmasine fan de tsjinst mesh. It bestiet út de folgjende dielen:
- De minske: Der is noch in persoan (hooplik minder lilk) dy't hege nivo besluten nimt oangeande it hiele systeem as gehiel.
- Kontrôle fleanmasine UI: In persoan ynteraksje mei in soarte fan brûkersynterface foar in kontrôle it systeem. Dit kin in webportaal wêze, in kommandorigelapplikaasje (CLI), of in oare ynterface. Mei de brûkersynterface hat de operator tagong ta globale systeemkonfiguraasjeparameters lykas:
- Deployment control, blau / grien en / of stadichoan ferkear oergong
- Opsjes foar ferifikaasje en autorisaasje
- Routing tabel spesifikaasjes, bygelyks as applikaasje A freget ynformaasje oer "/ foo" wat bart
- Load balancer-ynstellingen, lykas time-outs, opnij besykjen, circuit breaking-ynstellingen, ensfh.
- Workload scheduler: Tsjinsten wurde útfierd op 'e ynfrastruktuer fia in soarte fan skema- / orkestraasjesysteem, lykas Kubernetes of Nomad. De planner is ferantwurdlik foar it laden fan de tsjinst tegearre mei syn lokale proxy.
- Service ûntdekking. As de planner begjint en stopet tsjinstynstânsjes, rapportearret it de sûnensstatus oan it tsjinstûntdekkingssysteem.
- Sidecar proxy konfiguraasje APIs : Lokale folmacht dynamysk extract steat út ferskate systeem ûnderdielen mei help fan in úteinlik konsekwint model sûnder operator yntervinsje. It hiele systeem, besteande út alle op it stuit rinnende tsjinstynstânsjes en lokale proxy-tsjinners, konvergeart úteinlik yn ien ekosysteem. Envoy's universele dataplane API is ien foarbyld fan hoe't dit yn 'e praktyk wurket.
Yn essinsje is it doel fan it kontrôlefleanmasine om it belied yn te stellen dat úteinlik sil wurde akseptearre troch it gegevensfleantúch. Mear avansearre kontrôlefleantugen sille mear dielen fan guon systemen fan 'e operator ferwiderje en minder manuele operaasje fereaskje, as se goed wurkje!...
Data fleanmasine en kontrôle fleanmasine. Gegevens fleanmasine vs kontrôle fleanmasine gearfetting
- Service mesh gegevens fleanmasine: Beynfloedet elk pakket / fersyk yn it systeem. Ferantwurdlik foar ûntdekking fan applikaasjes / tsjinst, sûnenskontrôle, routing, loadbalancing, autentikaasje / autorisaasje en observabiliteit.
- Service mesh kontrôle fleanmasine: Jout belied en konfiguraasje foar alle rinnende gegevens fleantugen binnen de tsjinst netwurk. Raakt gjin pakketten / fersiken op it systeem oan. De kontrôle fleanmasine feroaret alle gegevens fleantugen yn in ferspraat systeem.
Aktueel projekt lânskip
Nei it begrepen fan 'e útlis hjirboppe, litte wy sjen nei de hjoeddeistige steat fan it tsjinstmeshprojekt.
- Data fleantugen: Linkerd, NGINX, HAProxy, Envoy, Traefik
- Kontrolearje fleantugen: Istio, Nelson, SmartStack
Yn stee fan in yngeande analyse fan elk fan 'e boppesteande oplossingen te gean, sil ik koart guon fan' e punten oanpakke dy't ik leau dat in protte fan 'e betizing yn it ekosysteem op it stuit feroarsaakje.
Linkerd wie ien fan 'e earste proxy-tsjinners foar gegevensfleantúch foar it tsjinstmesh yn' e iere 2016 en hat in fantastysk wurk dien om bewustwêzen en oandacht te ferheegjen foar it ûntwerpmodel fan servicemesh. Sawat 6 moannen dêrnei kaam Envoy by Linkerd (hoewol hy sûnt ein 2015 by Lyft west hie). Linkerd en Envoy binne de twa projekten dy't it meast wurde neamd by it besprekken fan tsjinstmeshes.
Istio waard yn maaie 2017 oankundige. De doelen fan it Istio-projekt binne heul gelyk oan it útwreide kontrôlefleanmasine werjûn yn Figuer 3. Envoy foar Istio is de standert proxy. Sa is Istio it kontrôlefleanmasine, en Envoy is it gegevensfleantúch. Yn in koarte tiid generearre Istio in protte opwining, en oare gegevensfleantugen begûnen te yntegrearjen as ferfanging foar Envoy (sawol Linkerd as NGINX demonstrearre yntegraasje mei Istio). It feit dat ferskate gegevensfleantugen kinne wurde brûkt binnen itselde kontrôlefleanmasine betsjut dat it kontrôlefleanmasine en it gegevensfleantúch net needsaaklik strak keppele binne. In API lykas Envoy's generike dataplane API kin in brêge foarmje tusken twa dielen fan it systeem.
Nelson en SmartStack helpe de skieding fan it kontrôlefleanmasine en it gegevensfleantúch fierder te yllustrearjen. Nelson brûkt Envoy as syn proxy en bout in betrouber kontrôlefleanmasine foar it tsjinstmesh basearre op 'e HashiCorp-stapel, d.w.s. Nomad, etc. SmartStack wie miskien de earste fan in nije weach fan tsjinstmeshes. SmartStack bout in kontrôlefleantúch om HAProxy of NGINX, en demonstrearret de mooglikheid om it kontrôlefleanmasine te ûntkoppelen fan it tsjinstmesh fan it gegevensfleantúch.
Microservice-arsjitektuer mei in tsjinstmesh krijt mear en mear omtinken (terjocht!), En mear en mear projekten en leveransiers begjinne yn dizze rjochting te wurkjen. Yn 'e kommende jierren sille wy in protte ynnovaasje sjen yn sawol it gegevensfleantúch as it kontrôlefleanmasine, lykas ek fierdere mingen fan ferskate komponinten. Uteinlik moat mikroservicearsjitektuer transparanter en magysker wurde (?) foar de operator.
Hooplik minder en minder yrritearre.
Key takeaways
- In tsjinstmesh bestiet út twa ferskillende dielen: it gegevensfleantúch en it kontrôlefleanmasine. Beide komponinten binne nedich, en sûnder harren sil it systeem net wurkje.
- Elkenien is bekend mei it kontrôlefleanmasine, en op dit punt kin it kontrôlefleanmasine jo wêze!
- Alle gegevensfleantugen konkurrearje mei elkoar op funksjes, prestaasjes, konfigurearberens en útwreidzjen.
- Alle kontrôlefleantugen konkurrearje mei elkoar yn funksjes, konfigurearberens, útbreidberens en gebrûksgemak.
- Ien kontrôlefleanmasine kin de juste abstraksjes en API's befetsje, sadat meardere gegevensfleantugen kinne wurde brûkt.
Boarne: www.habr.com
