Hei igjen!.. På tampen av kursstart Vi har utarbeidet en annen nyttig oversettelse.
Et tjenestenett er et konfigurerbart infrastrukturlag med lav latens som er nødvendig for å håndtere store mengder nettverksbasert interprosesskommunikasjon mellom applikasjonsprogrammeringsgrensesnitt (API). Service Mesh muliggjør rask, pålitelig og sikker kommunikasjon mellom containeriserte og ofte flyktige applikasjonsinfrastrukturtjenester. Service Mesh gir funksjoner som tjenesteoppdagelse, lastbalansering, kryptering, transparens, sporbarhet, autentisering og autorisasjon og støtte for automatisk avslutningsmønster (effektbryter).
Et tjenestenettverk implementeres vanligvis ved å gi hver tjenesteforekomst en proxy-forekomst, kalt Sidevogn. Sidevogn håndtere kommunikasjon mellom tjenester, overvåke og løse sikkerhetsproblemer, det vil si alt som kan abstraheres fra individuelle tjenester. På denne måten kan utviklere skrive, vedlikeholde og betjene applikasjonskode i tjenester, og systemadministratorer kan jobbe med Service Mesh og kjøre applikasjonen.
Istio fra Google, IBM og Lyft er for tiden den mest kjente service mesh-arkitekturen. Og Kubernetes, som opprinnelig ble utviklet hos Google, er nå det eneste rammeverket for containerorkestrering som støttes av Istio. Leverandører prøver å lage kommersielt støttede versjoner av Istio. Det blir interessant å se hvilke nye ting de kan bringe til åpen kildekode-prosjektet.
Istio er imidlertid ikke det eneste alternativet ettersom andre Service Mesh-implementeringer er under utvikling. Mønster sidecar proxy er den mest populære implementeringen, som kan bedømmes av prosjektene Buoyant, HashiCorp, Solo.io og andre. Det finnes også alternative arkitekturer: Netflix-teknologiverktøysettet er en av tilnærmingene der Service Mesh-funksjonaliteten implementeres gjennom Ribbon-, Hysterix-, Eureka-, Archaius-bibliotekene, samt plattformer som Azure Service Fabric.
Service Mesh har også sin egen terminologi for servicekomponenter og funksjoner:
- Container orkestrering rammeverk. Ettersom flere og flere containere legges til applikasjonsinfrastrukturen, er det behov for et eget verktøy for å overvåke og administrere containere – et containerorkestreringsrammeverk. Kubernetes har godt okkupert denne nisjen, så mye at selv hovedkonkurrentene Docker Swarm og Mesosphere DC/OS tilbyr integrasjon med Kubernetes som et alternativ.
- Tjenester og forekomster (Kubernetes Pods). En forekomst er en enkelt kjørende kopi av en mikrotjeneste. Noen ganger er én forekomst én beholder. I Kubernetes består en forekomst av en liten gruppe uavhengige beholdere kalt en pod. Klienter får sjelden tilgang til en forekomst eller pod direkte; oftere får de tilgang til en tjeneste, som er et sett med identiske, skalerbare og feiltolerante forekomster eller pods (replikaer).
- Sidevogns proxy. Sidecar Proxy fungerer med en enkelt forekomst eller pod. Poenget med Sidecar Proxy er å rute eller proxy-trafikk som kommer fra containeren den jobber med og returnere trafikk. Sidecar samhandler med andre Sidecar Proxies og administreres av et orkestreringsrammeverk. Mange Service Mesh-implementeringer bruker Sidecar Proxy for å fange opp og administrere all trafikk inn og ut av en forekomst eller pod.
- Tjenesteoppdagelse. Når en instans trenger å kommunisere med en annen tjeneste, må den finne (oppdage) en sunn og tilgjengelig instans av den andre tjenesten. Vanligvis utfører forekomsten DNS-oppslag. Beholderorkestreringsrammeverket opprettholder en liste over forekomster som er klare til å motta forespørsler og gir et grensesnitt for DNS-spørringer.
- Lastbalansering. De fleste containerorkestreringsrammer gir lastbalansering ved lag 4 (transport). Service Mesh implementerer mer kompleks lastbalansering på lag 7 (applikasjonsnivå), rik på algoritmer og mer effektiv i å administrere trafikk. Innstillinger for belastningsbalansering kan endres ved hjelp av API-en, slik at du kan orkestrere blågrønne eller kanarifuglutrullinger.
- Kryptering. Service Mesh kan kryptere og dekryptere forespørsler og svar, og fjerne denne byrden fra tjenestene. Service Mesh kan også forbedre ytelsen ved å prioritere eller gjenbruke eksisterende vedvarende tilkoblinger, noe som reduserer behovet for kostbar beregning for å opprette nye tilkoblinger. Den vanligste implementeringen av trafikkkryptering er gjensidig TLS (mTLS), der en offentlig nøkkelinfrastruktur (PKI) genererer og distribuerer sertifikater og nøkler for bruk av Sidecar Proxy.
- Autentisering og autorisasjon. Tjenestenettverket kan autorisere og autentisere forespørsler fra utsiden eller innsiden av applikasjonen, og sende kun validerte forespørsler til instanser.
- Støtte for automatisk avslutningsmønster. Service Mesh støtter , som isolerer usunne tilfeller og deretter gradvis returnerer dem til utvalget av sunne tilfeller når det er nødvendig.
Den delen av en Service Mesh-applikasjon som administrerer nettverkstrafikk mellom instanser kalles Dataplan. Opprett og distribuer konfigurasjon som kontrollerer atferd Dataplan, utføres ved hjelp av en separat Kontrollplan. Kontrollplan inkluderer vanligvis eller er designet for å koble til en API, CLI eller GUI for å kontrollere applikasjonen.
Kontrollplanet i Service Mesh distribuerer konfigurasjonen mellom Sidecar Proxy og Dataplanet.
Service Mesh-arkitektur brukes ofte til å løse komplekse driftsproblemer ved å bruke containere og mikrotjenester. Pionerer på feltet er selskaper som Lyft, Netflix og Twitter, som leverer stabile tjenester til millioner av brukere over hele verden. (). For mindre krevende applikasjoner vil sannsynligvis enklere arkitekturer være tilstrekkelig.
Service Mesh-arkitektur vil neppe noen gang være svaret på alle applikasjonsdrift og leveringsproblemer. Arkitekter og utviklere har et enormt arsenal av verktøy, og bare en av dem er en hammer, som blant mange oppgaver bare må løse én - å hamre spiker. inkluderer for eksempel flere forskjellige modeller som gir et kontinuum av tilnærminger til å løse problemer ved hjelp av mikrotjenester.
Elementene som kommer sammen i en Service Mesh-arkitektur, som NGINX, containere, Kubernetes og mikrotjenester som en arkitektonisk tilnærming, kan være like produktive i ikke-Service Mesh-implementeringer. For eksempel ble Istio designet som en komplett tjenestenettarkitektur, men dens modularitet betyr at utviklere kan velge og implementere bare de teknologikomponentene de trenger. Med dette i tankene er det viktig å utvikle en klar forståelse av Service Mesh-konseptet, selv om du ikke er sikker på at du noen gang vil kunne implementere det fullt ut i applikasjonen din.
Kilde: www.habr.com