Hva er Service Mesh?

Hei igjen!.. I forkant av kursstarten «Programvarearkitekt» har vi forberedt en nyttig oversettelse.

Service Mesh er et konfigurerbart infrastrukturlag med lav forsinkelse, som er nødvendig for å håndtere store mengder nettverksprosesskommunikasjon mellom programvaregrensesnittene (API). Service Mesh sikrer rask, pålitelig og sikker kommunikasjon mellom containeriserte og ofte flyktige tjenester i programvareinfrastrukturen. Service Mesh tilbyr funksjoner som tjenesteoppdagelse, lastbalansering, kryptering, gjennomsiktighet, sporing, autentisering og autorisasjon, samt støtte for mønsteret for automatisk avstengning (circuit breaker).
Service Mesh implementeres vanligvis ved å gi hver tjenesteinstans en proxy-instans, som kalles Sidecar. Sidecar håndterer kommunikasjonen mellom tjenestene, overvåker og løser sikkerhetsproblemer, det vil si alt som kan abstrakteres fra de enkelte tjenestene. Dermed kan utviklere skrive, vedlikeholde og betjene applikasjonskode i tjenestene, mens systemadministratorer kan arbeide med Service Mesh og kjøre applikasjonen.

Istio fra Google, IBM og Lyft er for tiden den mest kjente Service Mesh-arkitekturen. Kubernetes, som opprinnelig ble utviklet av Google, er nå den eneste rammeverket for orkestrering av containere som støttes av Istio. Leverandører prøver å lage kommersielt støttede versjoner av Istio. Det er interessant hva nytt de vil kunne bidra med til prosjektet med åpen kildekode.

Imidlertid er ikke Istio det eneste alternativet, ettersom andre implementeringer av Service Mesh også utvikles. Mønsteret for sidecar proxy er den mest populære implementeringen, ut fra prosjektene til Buoyant, HashiCorp, Solo.io og andre. Det finnes også alternative arkitekturer: Netflix-teknologiverktøy er en av tilnærmingene, hvor funksjonaliteten til Service Mesh implementeres ved hjelp av bibliotekene Ribbon, Hysterix, Eureka, Archaius, samt plattformer som Azure Service Fabric.

Service Mesh har også sitt eget terminologi for komponenter, tjenester og funksjoner:

• Rammeverk for orkestrering av containere. Etter hvert som flere og flere containere legges til infrastruktur for applikasjoner, oppstår det et behov for et eget verktøy for overvåkning og administrasjon av containere - et rammeverk for orkestrering av containere. Kubernetes har tett inntatt denne nisjen, så mye at selv hovedkonkurrentene Docker Swarm og Mesosphere DC/OS tilbyr integrasjon med Kubernetes som et alternativ.
• Tjenester og instanser (Kubernetes-poder). En instans er en enkelt kjørende kopi av mikrotjenesten. Noen ganger er en instans en enkelt container. I Kubernetes består en instans av en liten gruppe uavhengige containere som kalles en pod. Klientene henvender seg sjelden direkte til en instans eller pod, de går oftere til en tjeneste som representerer et sett med identiske, skalerbare og feiltolerante instanser eller podder (replikater).
• Sidecar Proxy. Sidecar Proxy arbeider med én instans eller pod. Poenget med Sidecar Proxy er å dirigere eller proxy trafikken som kommer fra containeren som den jobber med, samt tilbaketrafikken. Sidecar interagerer med andre Sidecar Proxy-er og styres av orkestreringsrammeverket. Mange implementeringer av Service Mesh bruker Sidecar Proxy for å fange og styre all innkommende og utgående trafikk fra instansen eller poden.
• Tjenesteoppdagelse. Når en instans trenger å interagere med en annen tjeneste, må den finne (oppdage) en fungerende og tilgjengelig instans av den andre tjenesten. Som regel utfører instansen et DNS-søk. Orkestreringsrammeverket for containere lagrer en liste over instanser som er klare til å motta forespørselen, og gir et grensesnitt for DNS-forespørselen.
• Lastbalancering. De fleste rammeverk for orkestrering av containere tilbyr lastbalansering på lag 4 (transportlag). Service Mesh implementerer mer kompleks lastbalansering på lag 7 (applikasjonslag), med rike algoritmer og mer effektiv trafikkadministrasjon. Lastbalanseringsparametrene kan justeres med API-er, noe som muliggjør orkestrering av blå-grønn eller kanarifugledistribusjon.
• Kryptering. Service Mesh kan kryptere og dekryptere forespørslene og svarene, og dermed fjerne denne byrden fra tjenestene. Service Mesh kan også øke ytelsen ved å prioritere eller gjenbruke eksisterende vedvarende forbindelser, noe som reduserer behovet for dyre beregninger for å opprette nye forbindelser. Den mest utbredte implementeringen av kryptering av trafikk er mutual TLS (mTLS), hvor infrastruktur for offentlig nøkkel (PKI) genererer og distribuerer sertifikater og nøkler til bruk i Sidecar Proxy.
• Autentisering og autorisasjon. Service Mesh kan autorisere og autentisere forespørslene som er gjort fra utsiden eller innsiden av applikasjonen, og sende bare validerte forespørsler til instansene.
• Støtte for automatisk nedstengningsmal. Service Mesh støtter automatisk nedstengningsmal, som isolerer usunne instanser, og deretter gradvis returnerer dem til bunken av sunne instanser etter behov.

Den delen av applikasjonen Service Mesh som håndterer nettverkstrafikken mellom instanser kalles Data Plane. Opprettelse og distribusjon av konfigurasjon som styrer atferden Data Plane, utføres med hjelp av en egen Control Plane. Control Plane som vanligvis inkluderer eller er utformet for å koble seg til API, CLI eller GUI for å administrere applikasjonen.

Control Plane i Service Mesh distribuerer konfigurasjonen mellom Sidecar Proxy og Data Plane.

Ofte brukes arkitekturen til Service Mesh for å løse komplekse operasjonelle oppgaver ved bruk av containere og mikrotjenester. Pionerer innen mikrotjenester er selskaper som Lyft, Netflix og Twitter, som leverer stabilt fungerende tjenester til millioner av brukere over hele verden. (Her kan du bli kjent med en detaljert beskrivelse av noen arkitektoniske utfordringer som Netflix har møtt). For mindre krevende applikasjonsoppgaver vil sannsynligvis enklere arkitekturer være tilstrekkelig.

Arkitekturen til Service Mesh vil neppe noen gang bli svaret på alle spørsmål knyttet til applikasjonsdrift og levering. Arkitekter og utviklere har et enormt arsenal av verktøy, og kun ett av dem er hammeren, som blant mange oppgaver kun skal løse én – å slå spikre. Microservices Reference Architecture fra NGINX, for eksempel, inkluderer flere forskjellige modeller som gir et kontinuerlig spekter av tilnærminger til å løse problemer med mikrotjenester.

Elementene som samles i Service Mesh-arkitekturen, som NGINX, containere, Kubernetes og mikrotjenester som en arkitektonisk tilnærming, kan også brukes produktivt i implementeringer uten Service Mesh. For eksempel ble Istio utviklet som en fullverdig Service Mesh-arkitektur, men modulisering antyder at utviklere kan velge og bruke bare de nødvendige teknologikomponentene. Når vi husker dette, er det viktig å utvikle en klar forståelse av konseptet Service Mesh, selv om du ikke er sikker på om du noen gang vil kunne implementere det fullt ut i applikasjonen.

Modulære monolitter og DDD

Kilde: habr.com