Hej igen!.. I takt med at kurset starter har vi forberedt endnu en nyttig oversættelse.
Service Mesh er et konfigurerbart infrastruktur lag med lav latenstid, der er nødvendigt for at håndtere et stort volumen af netværks kommunikationer mellem applikationsprogrammeringsgrænseflader (API). Service Mesh sikrer hurtig, pålidelig og sikker kommunikation mellem containeriserede og ofte kortvarige tjenester i applikationens infrastruktur. Service Mesh tilbyder funktioner som tjenesteopdagelse, belastningsfordeling, kryptering, transparens, sporbarhed, autentifikation og autorisation samt støtte til automatisk afbrydelsesmønster (circuit breaker).
Service Mesh implementeres typisk ved at give hver tjenesteinstans en proxyinstans, der kaldes Sidecar. Sidecar behandler kommunikationen mellem tjenester, udfører overvågning og løser sikkerhedsproblemer, altså alt hvad der kan abstraheres fra individuelle tjenester. På den måde kan udviklere skrive, vedligeholde og supportere kode i tjenesterne, mens systemadministratorer kan arbejde med Service Mesh og køre applikationen.
Istio fra Google, IBM og Lyft er i øjeblikket den mest kendte Service Mesh-arkitektur. Kubernetes, som oprindeligt blev udviklet hos Google, er nu det eneste container orkestreringsframework, der understøttes af Istio. Leverandører forsøger at skabe kommercielle understøttede versioner af Istio. Det er interessant, hvad de kan bidrage med til dette open source projekt.
Men Istio er ikke den eneste mulighed, da der også udvikles andre implementeringer af Service Mesh. Mønsteret sidecar proxy er den mest populære implementering, som man kan bedømme ud fra projekterne Buoyant, HashiCorp, Solo.io og andre. Der findes også alternative arkitekturer: Netflix's teknologiske værktøjssæt er en tilgang, hvor funktionaliteten af Service Mesh realiseres gennem biblioteker som Ribbon, Hystrix, Eureka, Archaius samt platforme som Azure Service Fabric.
Service Mesh har også sin egen terminologi for komponenter, tjenester og funktioner:
- Container orkestreringsframework. Efterhånden som der tilføjes flere og flere containere til applikationsinfrastrukturen, opstår behovet for et separat værktøj til overvågning og styring af containere – containerorkestreringsrammen. Kubernetes har taget denne niche, i så høj grad at selv dets primære konkurrenter, Docker Swarm og Mesosphere DC/OS, tilbyder integration med Kubernetes som alternativ.
- Tjenester og instanser (Kubernetes pods). En instans er en enkelt kørende kopi af en mikrotjeneste. Nogle gange er en instans en enkelt container. I Kubernetes består en instans af en lille gruppe uafhængige containere, som kaldes en pod. Klienter henvender sig sjældent direkte til en instans eller pod; oftere retter de henvendelse til en tjeneste, der repræsenterer et sæt identiske skalerbare og fejltolerante instanser eller pods (replikaer).
- Sidecar Proxy. Sidecar Proxy arbejder med en enkelt instans eller pod. Formålet med Sidecar Proxy er at dirigere eller proxy trafikken, der kommer fra den container, som den arbejder med, og den omvendte trafik. Sidecar interagerer med andre Sidecar Proxies og styres af orkestreringsrammen. Mange implementeringer af Service Mesh bruger Sidecar Proxy til at opfange og styre al indgående og udgående trafik fra instancen eller pod'en.
- Tjenesteopdagelse. Når en instans skal interagere med en anden tjeneste, skal den finde (opdage) en fungerende og tilgængelig instans af den anden tjeneste. Som regel udfører instansen en søgning via DNS. Orkestreringsrammen for containere opbevarer en liste over instanser, der er klar til at modtage forespørgsler, og giver et interface til DNS-forespørgsler.
- Load Balancing. De fleste containerorkestreringsrammer tilbyder belastningsbalancering på niveau 4 (transportniveau). Service Mesh implementerer en mere kompleks belastningsbalancering på niveau 7 (applikationsniveau), som er rig på algoritmer og mere effektiv til trafikstyring. Indstillingerne for belastningsbalancering kan ændres via API, hvilket muliggør orkestrering af blue-green eller kanariefugleruligheder.
- Kryptering. Service Mesh kan kryptere og dekryptere forespørgsler og svar, hvilket fjerner denne byrde fra tjenesterne. Service Mesh kan også forbedre ydeevnen ved at prioritere eller genbruge eksisterende vedvarende forbindelser, hvilket mindsker behovet for dyre beregninger for at oprette nye forbindelser. Den mest udbredte implementering af trafik-kryptering er mutual TLS (mTLS), hvor en infrastruktur til offentlige nøgler (PKI) genererer og distribuerer certifikater og nøgler til brug i Sidecar Proxy.
- Autentificering og autorisering. Service Mesh kan godkende og autentificere forespørgsler foretaget udefra eller indefra applikationen ved kun at sende validerede forespørgsler til instanserne.
- Understøttelse af mønsteret for automatisk nedlukning. Service Mesh understøtter , som isolerer usunde instanser og derefter gradvist bringer dem tilbage til puljen af sunde instanser efter behov.
Den del af applikationen Service Mesh, der styrer netværkstrafik mellem instanser, kaldes Data Plane. Oprettelse og implementering af konfiguration, der styrer adfærden Data Plane, udføres med hjælp fra en separat Control Plane. Control Plane der typisk inkluderer eller er designet til at tilslutte sig API, CLI eller GUI til at styre applikationen.
Control Plane i Service Mesh distribuerer konfigurationen mellem Sidecar Proxy og Data Plane.
Ofte anvendes arkitekturen for Service Mesh til at løse komplekse driftsopgaver ved brug af containere og mikroservices. Pionerer inden for er virksomheder som Lyft, Netflix og Twitter, som leverer stabilt fungerende tjenester til millioner af brugere verden over. (). For mindre krævende applikationsopgaver vil det sandsynligvis være tilstrækkeligt med mere enkle arkitekturer.
Arkitekturen for Service Mesh vil næppe nogensinde blive svaret på alle spørgsmål relateret til applikationers drift og levering. Arkitekter og udviklere har en stor værktøjskasse, og kun et af dem er en hammer, der blandt mange opgaver kun skal løse én – at slå søm. , for eksempel omfatter flere forskellige modeller, der giver et kontinuerligt spektrum af tilgange til at løse opgaver ved hjælp af mikrotjenester.
Elementer, der samles i Service Mesh-arkitekturen, såsom NGINX, containere, Kubernetes og mikrotjenester som en arkitektonisk tilgang, kan også udnyttes produktivt i implementeringer uden Service Mesh. For eksempel blev Istio udviklet som en fuldt funktionel Service Mesh-arkitektur, men modulariteten gør det muligt for udviklere at vælge og anvende kun de komponenter, de har brug for. Husk på dette, er det nødvendigt at danne en klar forståelse af konceptet Service Mesh, selvom du ikke er sikker på, at du nogensinde vil kunne implementere det fuldt ud i en applikation.
Kilde: habr.com
