Hej igen!.. På tærsklen til kursusstart Vi har forberedt endnu en nyttig oversættelse.
Et servicemesh er et konfigurerbart infrastrukturlag med lav latens, der er nødvendigt for at håndtere store mængder netværksbaseret interproceskommunikation mellem applikationsprogrammeringsgrænseflader (API'er). Service Mesh muliggør hurtig, pålidelig og sikker kommunikation mellem containeriserede og ofte flygtige applikationsinfrastrukturtjenester. Service Mesh giver funktioner såsom serviceopdagelse, belastningsbalancering, kryptering, gennemsigtighed, sporbarhed, godkendelse og autorisation og understøttelse af auto-shutdown-mønster (afbryder).
Et servicemesh implementeres typisk ved at give hver serviceinstans en proxyinstans, kaldet Sidevogn. Sidevogn håndtere kommunikation mellem tjenester, overvåge og løse sikkerhedsproblemer, det vil sige alt, hvad der kan abstraheres fra individuelle tjenester. På denne måde kan udviklere skrive, vedligeholde og betjene applikationskode i tjenester, og systemadministratorer kan arbejde med Service Mesh og køre applikationen.
Istio fra Google, IBM og Lyft er i øjeblikket den mest berømte service mesh-arkitektur. Og Kubernetes, som oprindeligt blev udviklet hos Google, er nu den eneste containerorkestreringsramme, der understøttes af Istio. Leverandører forsøger at skabe kommercielt understøttede versioner af Istio. Det bliver interessant at se, hvilke nye ting de kan bringe til open source-projektet.
Istio er dog ikke den eneste mulighed, da andre Service Mesh-implementeringer er under udvikling. Mønster sidecar proxy er den mest populære implementering, som det kan bedømmes af projekterne Buoyant, HashiCorp, Solo.io og andre. Der er også alternative arkitekturer: Netflix-teknologiværktøjssættet er en af de tilgange, hvor Service Mesh-funktionaliteten implementeres gennem Ribbon-, Hysterix-, Eureka-, Archaius-bibliotekerne samt platforme som Azure Service Fabric.
Service Mesh har også sin egen terminologi for servicekomponenter og funktioner:
- Container orkestreringsramme. Efterhånden som flere og flere containere tilføjes til applikationsinfrastrukturen, er der behov for et separat værktøj til overvågning og styring af containere - en containerorkestreringsramme. Kubernetes har fast besat denne niche, så meget, at selv dets hovedkonkurrenter Docker Swarm og Mesosphere DC/OS tilbyder integration med Kubernetes som et alternativ.
- Tjenester og forekomster (Kubernetes Pods). En instans er en enkelt kørende kopi af en mikrotjeneste. Nogle gange er én instans én beholder. I Kubernetes består en instans af en lille gruppe af uafhængige beholdere kaldet en pod. Klienter får sjældent adgang til en instans eller pod direkte; oftere får de adgang til en service, som er et sæt identiske, skalerbare og fejltolerante instanser eller pods (replikaer).
- Sidevogns proxy. Sidecar Proxy fungerer med en enkelt instans eller pod. Pointen med Sidecar Proxy er at dirigere eller proxy-trafik, der kommer fra den container, den arbejder med, og returnere trafik. Sidecar interagerer med andre Sidecar Proxies og styres af en orkestreringsramme. Mange Service Mesh-implementeringer bruger Sidecar Proxy til at opfange og administrere al trafik ind og ud af en instans eller pod.
- Tjenesteopdagelse. Når en instans skal kommunikere med en anden service, skal den finde (opdage) en sund og tilgængelig instans af den anden service. Typisk udfører instansen DNS-opslag. Containerorkestreringsrammen vedligeholder en liste over forekomster, der er klar til at modtage anmodninger, og giver en grænseflade til DNS-forespørgsler.
- Lastbalancering. De fleste containerorkestreringsrammer giver belastningsbalancering ved lag 4 (transport). Service Mesh implementerer mere kompleks belastningsbalancering på lag 7 (applikationsniveau), rig på algoritmer og mere effektiv til at styre trafik. Indstillinger for belastningsbalancering kan ændres ved hjælp af API'et, så du kan orkestrere blågrønne eller kanariske installationer.
- kryptering. Service Mesh kan kryptere og dekryptere anmodninger og svar og fjerne denne byrde fra tjenester. Service Mesh kan også forbedre ydeevnen ved at prioritere eller genbruge eksisterende vedvarende forbindelser, hvilket reducerer behovet for dyre beregninger for at skabe nye forbindelser. Den mest almindelige implementering af trafikkryptering er gensidig TLS (mTLS), hvor en offentlig nøgleinfrastruktur (PKI) genererer og distribuerer certifikater og nøgler til brug for Sidecar Proxy.
- Autentificering og autorisation. Servicenetværket kan godkende og autentificere anmodninger lavet udefra eller inde i applikationen og kun sende validerede anmodninger til instanser.
- Understøttelse af automatisk nedlukningsmønster. Service Mesh understøtter , som isolerer usunde tilfælde og derefter gradvist returnerer dem til puljen af sunde tilfælde, når det er nødvendigt.
Den del af en Service Mesh-applikation, der styrer netværkstrafik mellem instanser, kaldes Datafly. Opret og implementer konfiguration, der styrer adfærd Datafly, udføres ved hjælp af en separat Kontrolplan. Kontrolplan omfatter typisk eller er designet til at oprette forbindelse til en API, CLI eller GUI for at styre applikationen.
Kontrolplanet i Service Mesh distribuerer konfigurationen mellem Sidecar Proxy og Dataplanet.
Service Mesh-arkitektur bruges ofte til at løse komplekse driftsproblemer ved hjælp af containere og mikrotjenester. Pionerer på området er virksomheder som Lyft, Netflix og Twitter, der leverer stabile tjenester til millioner af brugere verden over. (). For mindre krævende applikationer vil simplere arkitekturer sandsynligvis være tilstrækkelige.
Service Mesh-arkitektur vil næppe nogensinde være svaret på alle applikationsdrift og leveringsproblemer. Arkitekter og udviklere har et enormt arsenal af værktøjer, og kun én af dem er en hammer, som blandt mange opgaver kun skal løse én - at hamre søm. omfatter for eksempel flere forskellige modeller, der giver et kontinuum af tilgange til at løse problemer ved hjælp af mikrotjenester.
De elementer, der samles i en Service Mesh-arkitektur, såsom NGINX, containere, Kubernetes og mikrotjenester som en arkitektonisk tilgang, kan være lige så produktive i ikke-Service Mesh-implementeringer. For eksempel blev Istio designet som en komplet service mesh-arkitektur, men dens modularitet betyder, at udviklere kun kan vælge og implementere de teknologikomponenter, de har brug for. Med dette i tankerne er det vigtigt at udvikle en klar forståelse af Service Mesh-konceptet, selvom du ikke er sikker på, at du nogensinde vil være i stand til at implementere det fuldt ud i din applikation.
Kilde: www.habr.com