Hej igen!.. På tröskeln till kursstart Vi har förberett en annan användbar översättning.
Ett servicenät är ett konfigurerbart infrastrukturlager med låg latens som behövs för att hantera stora volymer nätverksbaserad interprocesskommunikation mellan applikationsprogrammeringsgränssnitt (API). Service Mesh möjliggör snabb, pålitlig och säker kommunikation mellan containeriserade och ofta tillfälliga applikationsinfrastrukturtjänster. Service Mesh tillhandahåller funktioner som tjänsteupptäckt, lastbalansering, kryptering, transparens, spårbarhet, autentisering och auktorisering och stöd för automatisk avstängning (strömbrytare).
Ett servicenät implementeras vanligtvis genom att förse varje tjänsteinstans med en proxyinstans, anropad Sidvagn. Sidvagn hantera kommunikationer mellan tjänster, övervaka och lösa säkerhetsfrågor, det vill säga allt som kan abstraheras från enskilda tjänster. På så sätt kan utvecklare skriva, underhålla och visa applikationskod i tjänster, och 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. Och 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 kommersiellt stödda versioner av Istio. Det ska bli intressant att se vilka nya saker de kan tillföra open source-projektet.
Istio är dock inte det enda alternativet eftersom andra Service Mesh-implementationer håller på att utvecklas. Mönster sidecar proxy är den mest populära implementeringen, vilket kan bedömas av projekten Buoyant, HashiCorp, Solo.io och andra. Det finns också alternativa arkitekturer: Netflix-teknikverktygssatsen är ett av tillvägagångssätten där Service Mesh-funktionaliteten implementeras genom Ribbon-, Hysterix-, Eureka-, Archaius-biblioteken, såväl som plattformar som Azure Service Fabric.
Service Mesh har också sin egen terminologi för servicekomponenter och funktioner:
- Container orkestrering ram. I takt med att fler och fler containrar läggs till i applikationsinfrastrukturen finns det ett behov av ett separat verktyg för att övervaka och hantera containrar – ett containerorkestreringsramverk. Kubernetes har bestämt ockuperat denna nisch, så mycket att även dess huvudkonkurrenter Docker Swarm och Mesosphere DC/OS erbjuder integration med Kubernetes som ett alternativ.
- Tjänster och instanser (Kubernetes Pods). En instans är en enda körande kopia av en mikrotjänst. Ibland är en instans en behållare. I Kubernetes består en instans av en liten grupp oberoende behållare som kallas en pod. Klienter får sällan tillgång till en instans eller pod direkt; oftare får de tillgång till en tjänst, som är en uppsättning identiska, skalbara och feltoleranta instanser eller pods (repliker).
- Sidecar Proxy. Sidecar Proxy fungerar med en enda instans eller pod. Poängen med Sidecar Proxy är att dirigera eller proxytrafik som kommer från behållaren den arbetar med och returnera trafik. Sidecar interagerar med andra Sidecar Proxies och hanteras av ett orkestreringsramverk. Många Service Mesh-implementeringar använder Sidecar Proxy för att fånga upp och hantera all trafik in och ut ur en instans eller pod.
- Service Discovery. När en instans behöver kommunicera med en annan tjänst måste den hitta (upptäcka) en hälsosam och tillgänglig instans av den andra tjänsten. Vanligtvis utför instansen DNS-uppslagningar. Behållarorkestreringsramverket upprätthåller 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 containerorkestreringsramverk ger lastbalansering vid lager 4 (transport). Service Mesh implementerar mer komplex lastbalansering på lager 7 (applikationsnivå), rik på algoritmer och effektivare för att hantera trafik. Inställningar för lastbalansering kan ändras med hjälp av API:et, så att du kan orkestrera blågröna eller kanariefågelinstallationer.
- Шифрование. Service Mesh kan kryptera och dekryptera förfrågningar och svar, vilket tar bort denna börda från tjänster. Service Mesh kan också förbättra prestandan genom att prioritera eller återanvända befintliga beständiga anslutningar, vilket minskar behovet av dyra beräkningar för att skapa nya anslutningar. Den vanligaste implementeringen av trafikkryptering är ömsesidig TLS (mTLS), där en offentlig nyckelinfrastruktur (PKI) genererar och distribuerar certifikat och nycklar för användning av Sidecar Proxy.
- Autentisering och auktorisering. Servicenätverket kan auktorisera och autentisera förfrågningar som görs utifrån eller inuti applikationen och skickar endast validerade förfrågningar till instanser.
- Stöd för automatisk avstängning. Service Mesh-stöd , som isolerar ohälsosamma instanser och sedan gradvis återför dem till poolen av friska instanser när det behövs.
Den del av en Service Mesh-applikation som hanterar nätverkstrafik mellan instanser anropas Dataplan. Skapa och distribuera konfiguration som styr beteende Dataplan, utförs med hjälp av en separat Kontrollplan. Kontrollplan innehåller vanligtvis eller är utformad för att ansluta till ett API, CLI eller GUI för att styra applikationen.
Kontrollplanet i Service Mesh fördelar konfigurationen mellan sidovagnsproxyn och dataplanet.
Service Mesh-arkitektur används ofta för att lösa komplexa driftsproblem med hjälp av containrar och mikrotjänster. Pionjärer inom området är företag som Lyft, Netflix och Twitter, som tillhandahåller stabila tjänster till miljontals användare över hela världen. (). För mindre krävande applikationer kommer enklare arkitekturer sannolikt att räcka.
Service Mesh-arkitektur kommer sannolikt inte någonsin att vara svaret på alla problem med applikationsdrift och leverans. Arkitekter och utvecklare har en enorm arsenal av verktyg, och bara en av dem är en hammare, som bland många uppgifter bara måste lösa en - hamra spikar. , till exempel, innehåller flera olika modeller som ger ett kontinuum av tillvägagångssätt för att lösa problem med hjälp av mikrotjänster.
Elementen som möts i en Service Mesh-arkitektur, såsom NGINX, containrar, Kubernetes och mikrotjänster som ett arkitektoniskt tillvägagångssätt, kan vara lika produktiva i icke-Service Mesh-implementeringar. Till exempel designades Istio som en komplett servicenätarkitektur, men dess modularitet innebär att utvecklare endast kan välja och implementera de teknologikomponenter de behöver. Med detta i åtanke är det viktigt att utveckla en tydlig förståelse av Service Mesh-konceptet, även om du inte är säker på att du någonsin kommer att kunna implementera det fullt ut i din applikation.
Källa: will.com