Kommunikationsinfrastruktur för Service Mesh
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 det här kapitlet har vi utforskat utmaningarna med kommunikation med mikrotjänster. Vi sa att utvecklingsteam måste vara känsliga för hur serverdelstjänster kommunicerar med varandra. Helst, desto mindre kommunikation mellan tjänster, desto bättre. Undvikande är dock inte alltid möjligt eftersom serverdelstjänster ofta förlitar sig på varandra för att slutföra åtgärder.
Vi har utforskat olika metoder för att implementera synkron HTTP-kommunikation och asynkrona meddelanden. I vart och ett av fallen belastas utvecklaren med att implementera kommunikationskod. Kommunikationskoden är komplex och tidsintensiv. Felaktiga beslut kan leda till betydande prestandaproblem.
En modernare metod för kommunikationscenter för mikrotjänster kring en ny och snabbt föränderlig teknik med titeln Service Mesh. Ett tjänstnät är ett konfigurerbart infrastrukturlager med inbyggda funktioner för att hantera kommunikation från tjänst till tjänst, återhämtning och många övergripande problem. Det flyttar ansvaret för dessa problem från mikrotjänsterna och till service mesh-lagret. Kommunikationen abstraheras bort från dina mikrotjänster.
En nyckelkomponent i ett tjänstnät är en proxy. I ett molnbaserat program är en instans av en proxy vanligtvis samlokaliserad med varje mikrotjänst. Medan de körs i separata processer är de två nära länkade och delar samma livscykel. Det här mönstret, som kallas sidovagnsmönster, visas i bild 4-24.
Bild 4-24. Servicenät med sidobil
Observera i föregående bild hur meddelanden fångas upp av en proxy som körs tillsammans med varje mikrotjänst. Varje proxy kan konfigureras med trafikregler som är specifika för mikrotjänsten. Den förstår meddelanden och kan dirigera dem över dina tjänster och världen utanför.
Förutom att hantera tjänst-till-tjänst-kommunikation ger Service Mesh stöd för tjänstidentifiering och belastningsutjämning.
När det har konfigurerats är ett tjänstnät mycket funktionellt. Mesh hämtar en motsvarande pool med instanser från en tjänstidentifieringsslutpunkt. Den skickar en begäran till en specifik tjänstinstans som registrerar svarstiden och svarstypen för resultatet. Den väljer den instans som mest sannolikt returnerar ett snabbt svar baserat på olika faktorer, inklusive den observerade svarstiden för de senaste begärandena.
Ett servicenät hanterar trafik-, kommunikations- och nätverksproblem på programnivå. Den förstår meddelanden och begäranden. Ett servicenät integreras vanligtvis med en containerorkestrerare. Kubernetes stöder en utökningsbar arkitektur där ett tjänstnät kan läggas till.
I kapitel 6 fördjupar vi oss i Service Mesh-tekniker, inklusive en diskussion om dess arkitektur och tillgängliga implementeringar med öppen källkod.
Sammanfattning
I det här kapitlet diskuterade vi molnbaserade kommunikationsmönster. Vi började med att undersöka hur klientdelsklienter kommunicerar med serverdelsmikrotjänster. Längs vägen pratade vi om API Gateway-plattformar och realtidskommunikation. Sedan tittade vi på hur mikrotjänster kommunicerar med andra serverdelstjänster. Vi har tittat på både synkron HTTP-kommunikation och asynkrona meddelanden mellan tjänster. Vi har gått igenom gRPC, en kommande teknik i den molnbaserade världen. Slutligen introducerade vi en ny och snabbt utvecklande teknik med titeln Service Mesh som kan effektivisera mikrotjänstkommunikationen.
Särskild vikt låg på hanterade Azure-tjänster som kan bidra till att implementera kommunikation i molnbaserade system:
- Azure Application Gateway
- Azure API Management
- Azure SignalR Service
- Azure Storage-köer
- Azure Service Bus
- Azure Event Grid
- Azure Event Hubs
Vi går sedan vidare till distribuerade data i molnbaserade system och de fördelar och utmaningar som de medför.
