Och återigen, hej!.. Inför starten av kursen har vi förberett en annan användbar översättning.
Service Mesh är en konfigurerbar infrastruktur-nivå med låg latens som behövs för att hantera stora volymer av nätverksinterprocesskommunikation mellan applikationsprogrammeringsgränssnitt (API). Service Mesh säkerställer snabb, pålitlig och säker kommunikation mellan containeriserade och ofta ephemeral tjänster i applikationsinfrastrukturen. Service Mesh erbjuder funktioner som tjänstupptäckter, lastbalansering, kryptering, transparens, spårbarhet, autentisering och auktorisering, samt stöd för mönster som automatisk avstängning (circuit breaker).
Service Mesh implementeras vanligtvis genom att tillhandahålla en proxyinstans för varje tjänstinstans, som kallas Sidecar. Sidecar hanterar kommunikationen mellan tjänster, övervakar och åtgärdar säkerhetsproblem, det vill säga allt som kan abstraheras från individuella tjänster. På så sätt kan utvecklare skriva, underhålla och stötta applikationskod i tjänster, medan systemadministratörer kan arbeta med Service Mesh och köra applikationen.
Istio från Google, IBM och Lyft är för närvarande den mest kända Service Mesh-arkitekturen. Kubernetes, som ursprungligen utvecklades av Google, är nu det enda ramverket för containerorkestrering som stöds av Istio. Leverantörer försöker skapa kommersiella versioner av Istio som har support. Det blir intressant att se vad nytt de kan tillföra till detta öppen källkod-projekt.
Men Istio är inte det enda alternativet, eftersom andra implementeringar av Service Mesh också utvecklas. Mönstret sidecar proxy är den mest populära implementeringen, som man kan bedöma utifrån projekten Buoyant, HashiCorp, Solo.io och andra. Det finns även alternativa arkitekturer: Netflix teknikverktyg är ett av tillvägagångssätten där funktionerna i Service Mesh implementeras genom hjälp av biblioteken Ribbon, Hysterix, Eureka, Archaius, samt plattformar som Azure Service Fabric.
Service Mesh har också sin egen terminologi för komponenttjänster och funktioner:
- Containerorkestreringsramverket. I takt med att fler och fler containrar läggs till i applikationens infrastruktur uppstår behovet av ett separat verktyg för övervakning och hantering av containrar – ramverket för containers orkestrering. Kubernetes har snabbt tagit denna nisch, så mycket att till och med dess främsta konkurrenter Docker Swarm och Mesosphere DC/OS erbjuder integration med Kubernetes som alternativ.
- Tjänster och instanser (Kubernetes pods). En instans är en enda körande kopia av en mikrotjänst. Ibland är en instans en enda container. I Kubernetes består en instans av en liten grupp oberoende containrar som kallas en pod. Kunder kontaktar sällan en instans eller pod direkt, oftare kontaktar de en tjänst som representerar en uppsättning identiska, skalbara och felresilienta instanser eller pods (kopior).
- Sidecar Proxy. Sidecar Proxy arbetar med en enda instans eller pod. Syftet med Sidecar Proxy är att dirigera eller proxa trafik som kommer från containern den arbetar med och omvänd trafik. Sidecar interagerar med andra Sidecar Proxy och hanteras av orkestreringsramverket. Många implementationer av Service Mesh använder Sidecar Proxy för att fånga och hantera all inkommande och utgående trafik från instansen eller podden.
- Tjänstupptäckte. När en instans behöver interagera med en annan tjänst, behöver den hitta (upptäcka) en fungerande och tillgänglig instans av den andra tjänsten. Vanligtvis söker instansen via DNS. Orkestreringsramverket för containrar lagrar en lista över instanser som är redo att ta emot förfrågningar och tillhandahåller ett gränssnitt för DNS-frågor.
- Lastbalansering. De flesta ramverk för containers orkestrering tillhandahåller lastbalansering på nivå 4 (transportnivå). Service Mesh implementerar mer avancerad lastbalansering på nivå 7 (applikationsnivå), rik på algoritmer och mer effektiv i fråga om trafikhantering. Inställningar för lastbalansering kan ändras via API, vilket möjliggör orkestrering av blågröna eller kanariejobsdistribution.
- Kryptering. Service Mesh kan kryptera och dekryptera förfrågningar och svar, vilket avlastar tjänsterna. Service Mesh kan också öka prestandan genom att prioritera eller återanvända befintliga persistenta anslutningar, vilket minskar behovet av kostsamma beräkningar för att skapa nya anslutningar. Den vanligaste implementeringen av trafik kryptering är mutual TLS (mTLS), där en infrastruktur för offentliga nycklar (PKI) genererar och distribuerar certifikat och nycklar för användning i Sidecar Proxy.
- Autentisering och auktorisering. Service Mesh kan auktorisera och autentisera förfrågningar som görs utifrån eller inifrån applikationen, genom att endast skicka validerade förfrågningar till instanserna.
- Stöd för mönster för automatisk avstängning. Service Mesh stöder , som isolerar ohälsosamma instanser och gradvis återför dem till poolen av hälsosamma instanser vid behov.
Den del av Service Mesh-applikationen som hanterar nätverkstrafik mellan instanser kallas Data Plane. Skapandet och distributionen av konfiguration som styr beteendet Data Plane, görs med hjälp av en separat Control Plane. Control Plane som vanligtvis inkluderar eller är utformad för att ansluta till API, CLI eller GUI för att hantera applikationen.
Control Plane i Service Mesh distribuerar konfigurationen mellan Sidecar Proxy och Data Plane.
Ofta tillämpas arkitekturen för Service Mesh för att lösa komplexa driftuppgifter med hjälp av containrar och mikrotjänster. Pionjärer inom är företag som Lyft, Netflix och Twitter, som tillhandahåller stabila tjänster till miljoner användare världen över. (). För mindre krävande applikationsuppgifter är det troligt att enklare arkitekturer räcker.
Arkitekturen för Service Mesh kommer troligtvis aldrig att vara svaret på alla frågor relaterade till applikationers drift och leverans. Arkitekter och utvecklare har en stor uppsättning verktyg, och bara ett av dem är en hammare, vilket bland många uppgifter bör lösa endast ett - att slå i spik. , till exempel, inkluderar flera olika modeller som erbjuder en kontinuerlig spektrum av tillvägagångssätt för att lösa problem med hjälp av mikrotjänster.
Elementen som förenas i Service Mesh-arkitekturen, såsom NGINX, containrar, Kubernetes och mikrotjänster som en arkitektonisk tillvägagångssätt, kan också användas lika produktivt i implementationer utan Service Mesh. Till exempel utvecklades Istio som en fullt fungerande Service Mesh-arkitektur, men modulariteten innebär att utvecklare kan välja och tillämpa endast de komponenter av teknologier som de behöver. Med detta i åtanke är det viktigt att bilda en tydlig förståelse av konceptet Service Mesh, även om du kanske inte är säker på att du någonsin kommer att kunna fullt ut implementera det i din applikation.
Källa: habr.com
