Elastisk kommunikation
Dricks
Det här innehållet är ett utdrag från eBook, Architecting Cloud Native .NET Applications for Azure, tillgängligt på .NET Docs eller som en kostnadsfri nedladdningsbar PDF som kan läsas offline.
I den här boken har vi anammat en mikrotjänstbaserad arkitekturmetod. Även om en sådan arkitektur ger viktiga fördelar innebär den många utmaningar:
Out-of-process-nätverkskommunikation. Varje mikrotjänst kommunicerar via ett nätverksprotokoll som introducerar nätverksbelastning, svarstid och tillfälliga fel.
Tjänstidentifiering. Hur identifierar och kommunicerar mikrotjänster med varandra när de körs över ett kluster med datorer med sina egna IP-adresser och portar?
Återhämtning. Hur hanterar du kortvariga fel och håller systemet stabilt?
Belastningsutjämning. Hur distribueras inkommande trafik över flera instanser av en mikrotjänst?
Säkerhet. Hur tillämpas säkerhetsproblem som kryptering på transportnivå och certifikathantering?
Distribuerad övervakning. – Hur korrelerar och avbildar du spårningsbarhet och övervakning för en enskild begäran över flera förbrukande mikrotjänster?
Du kan åtgärda dessa problem med olika bibliotek och ramverk, men implementeringen kan vara dyr, komplex och tidskrävande. Du får även infrastrukturproblem kopplade till affärslogik.
Tjänstnät
En bättre metod är en teknik som utvecklas med titeln Service Mesh. Ett tjänstnät är ett konfigurerbart infrastrukturlager med inbyggda funktioner för att hantera tjänstkommunikation och andra utmaningar som nämns ovan. Den frikopplar dessa problem genom att flytta dem till en tjänstproxy. Proxyn distribueras i en separat process (kallas sidovagn) för att tillhandahålla isolering från affärskod. Sidovagnen är dock länkad till tjänsten – den skapas med den och delar dess livscykel. Bild 6–7 visar det här scenariot.
Bild 6-7. Servicenät med sidobil
I föregående bild bör du notera hur proxyn fångar upp och hanterar kommunikationen mellan mikrotjänsterna och klustret.
Ett tjänstnät är logiskt uppdelat i två olika komponenter: ett dataplan och ett kontrollplan. Bild 6–8 visar dessa komponenter och deras ansvarsområden.
Bild 6-8. Service Mesh-kontroll och dataplan
När det har konfigurerats är ett tjänstnät mycket funktionellt. Den kan hämta en motsvarande pool med instanser från en tjänstidentifieringsslutpunkt. Mesh kan sedan skicka en begäran till en specifik instans och registrera svarstid och svarstyp för resultatet. Ett nät kan välja den instans som mest sannolikt returnerar ett snabbt svar baserat på många faktorer, inklusive dess observerade svarstid för de senaste begärandena.
Om en instans inte svarar eller misslyckas, försöker mesh igen begäran på en annan instans. Om det returnerar fel avlägsnar ett nät instansen från belastningsutjämningspoolen och återställer den när den har läkt. Om en begäran överskrider tidsgränsen kan ett nät misslyckas och sedan försöka begära igen. Ett nät samlar in och genererar mått och distribuerad spårning till ett centraliserat måttsystem.
Istio och Envoy
Det finns för närvarande några service mesh-alternativ, men Istio är den mest populära när det här skrivs. Istio är ett joint venture från IBM, Google och Lyft. Det är ett erbjudande med öppen källkod som kan integreras i ett nytt eller befintligt distribuerat program. Tekniken ger en konsekvent och fullständig lösning för att skydda, ansluta och övervaka mikrotjänster. Dess funktioner är:
- Säker tjänst-till-tjänst-kommunikation i ett kluster med stark identitetsbaserad autentisering och auktorisering.
- Automatisk belastningsutjämning för HTTP-, gRPC-, WebSocket- och TCP-trafik.
- Detaljerad kontroll av trafikbeteende med omfattande routningsregler, återförsök, redundans och felinmatning.
- Ett anslutningsbart principlager och konfigurations-API som stöder åtkomstkontroller, hastighetsbegränsningar och kvoter.
- Automatiska mått, loggar och spårningar för all trafik i ett kluster, inklusive ingress och utgående kluster.
En nyckelkomponent för en Istio-implementering är en proxytjänst med titeln Envoy proxy. Den körs tillsammans med varje tjänst och ger en plattformsoberoende grund för följande funktioner:
- Dynamisk tjänstidentifiering.
- Belastningsutjämning.
- TLS-avslutning.
- HTTP- och gRPC-proxyservrar.
- Kretsbrytarens återhämtning.
- Hälsokontroller.
- Löpande uppdateringar med kanariedistributioner .
Som tidigare diskuterats distribueras Envoy som en sidovagn till varje mikrotjänst i klustret.
Integrering med Azure Kubernetes Services
Azure-molnet omfattar Istio och ger direkt support för det i Azure Kubernetes Services. Följande länkar kan hjälpa dig att komma igång:
