gRPC

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.

Ladda ned PDF

Hittills i den här boken har vi fokuserat på REST-baserad kommunikation. Vi har sett att REST är ett flexibelt arkitekturformat som definierar CRUD-baserade åtgärder mot entitetsresurser. Klienter interagerar med resurser i HTTP med en kommunikationsmodell för begäran/svar. Även om REST är allmänt implementerat har en nyare kommunikationsteknik, gRPC, fått en enorm fart i hela den molnbaserade communityn.

Vad är gRPC?

gRPC är ett modernt ramverk med höga prestanda som utvecklar RPC-protokollet (age-old remote procedure call). På programnivå effektiviserar gRPC meddelanden mellan klienter och serverdelstjänster. GRPC kommer från Google och är öppen källkod och en del av CLOUD Native Computing Foundations ekosystem (CNCF) med molnbaserade erbjudanden. CNCF anser att gRPC är ett inkuberande projekt. Inkubering innebär att slutanvändarna använder tekniken i produktionsprogram, och projektet har ett hälsosamt antal deltagare.

En typisk gRPC-klientapp exponerar en lokal, pågående funktion som implementerar en affärsåtgärd. Under täcket anropar den lokala funktionen en annan funktion på en fjärrdator. Det som verkar vara ett lokalt anrop blir i princip ett transparent out-of-process-anrop till en fjärrtjänst. RPC-VVS abstraherar punkt-till-punkt-nätverkskommunikation, serialisering och körning mellan datorer.

I molnbaserade program arbetar utvecklare ofta med programmeringsspråk, ramverk och tekniker. Den här samverkan komplicerar meddelandekontrakt och den VVS som krävs för plattformsoberoende kommunikation. gRPC tillhandahåller ett "enhetligt horisontellt lager" som sammanfattar dessa problem. Utvecklare kodar i sin interna plattform med fokus på affärsfunktioner, medan gRPC hanterar kommunikationsrör.

gRPC erbjuder omfattande stöd för de flesta populära utvecklingsstackar, inklusive Java, JavaScript, C#, Go, Swift och NodeJS.

gRPC-fördelar

gRPC använder HTTP/2 för sitt transportprotokoll. HTTP/2 är kompatibelt med HTTP 1.1 och har många avancerade funktioner:

• Ett binärt inramningsprotokoll för datatransport – till skillnad från HTTP 1.1, som är textbaserat.
• Stöd för multiplexering för att skicka flera parallella begäranden via samma anslutning – HTTP 1.1 begränsar bearbetningen till ett begäran/svar-meddelande i taget.
• Dubbelriktad full duplex-kommunikation för att skicka både klientbegäranden och serversvar samtidigt.
• Inbyggd direktuppspelning som aktiverar begäranden och svar på asynkront strömma stora datamängder.
• Rubrikkomprimering som minskar nätverksanvändningen.

gRPC är lätt och mycket högpresterande. Det kan vara upp till 8 x snabbare än JSON-serialisering med meddelanden som är 60–80 % mindre. I WCF-parlance (Microsoft Windows Communication Foundation) överskrider gRPC-prestanda hastigheten och effektiviteten för de högoptimerade NetTCP-bindningarna. Till skillnad från NetTCP, som gynnar Microsoft-stacken, är gRPC plattformsoberoende.

Protocol Buffers

gRPC omfattar en teknik med öppen källkod som kallas protokollbuffertar. De ger ett mycket effektivt och plattformsneutralt serialiseringsformat för serialisering av strukturerade meddelanden som tjänster skickar till varandra. Med hjälp av ett plattformsoberoende gränssnittsdefinitionsspråk (IDL) definierar utvecklare ett tjänstkontrakt för varje mikrotjänst. Kontraktet, som implementeras som en textbaserad .proto fil, beskriver metoderna, indata och utdata för varje tjänst. Samma kontraktfil kan användas för gRPC-klienter och tjänster som bygger på olika utvecklingsplattformar.

Med proto-filen genererar Protobuf-kompilatorn, protoc, både klient- och tjänstkod för målplattformen. Koden innehåller följande komponenter:

• Starkt inskrivna objekt, som delas av klienten och tjänsten, som representerar tjänståtgärder och dataelement för ett meddelande.
• En starkt skriven basklass med nödvändig nätverks-VVS som fjärr-gRPC-tjänsten kan ärva och utöka.
• En klientstub som innehåller nödvändig VVS för att anropa fjärr-gRPC-tjänsten.

Vid körning serialiseras varje meddelande som en Standard Protobuf-representation och utbyts mellan klienten och fjärrtjänsten. Till skillnad från JSON eller XML serialiseras Protobuf-meddelanden som kompilerade binära byte.

gRPC-stöd i .NET

gRPC är integrerat i .NET Core 3.0 SDK och senare. Följande verktyg stöder det:

• Visual Studio 2022 med arbetsbelastningen ASP.NET och webbutveckling installerad
• Visual Studio-koden
• The dotnet CLI

SDK:t innehåller verktyg för slutpunktsroutning, inbyggd IoC och loggning. Kestrel-webbservern med öppen källkod stöder HTTP/2-anslutningar. Bild 4–20 visar en Visual Studio 2022-mall som skapar ett skelettprojekt för en gRPC-tjänst. Observera hur .NET har fullt stöd för Windows, Linux och macOS.

Bild 4-20. gRPC-stöd i Visual Studio 2022

Bild 4-21 visar skelettet gRPC-tjänsten som genereras från den inbyggda byggnadsställningen som ingår i Visual Studio 2022.

Bild 4-21. gRPC-projekt i Visual Studio 2022

Observera proto-beskrivningsfilen och tjänstkoden i föregående bild. Som du snart ser genererar Visual Studio ytterligare konfiguration i både startklassen och den underliggande projektfilen.

gRPC-användning

Favor gRPC för följande scenarier:

• Synkron serverdels-mikrotjänst-till-mikrotjänst-kommunikation där ett omedelbart svar krävs för att fortsätta bearbetningen.
• Flerspråkiga miljöer som behöver stöd för blandade programmeringsplattformar.
• Låg svarstid och kommunikation med högt dataflöde där prestandan är kritisk.
• Punkt-till-punkt-realtidskommunikation – gRPC kan skicka meddelanden i realtid utan avsökning och har utmärkt stöd för dubbelriktad direktuppspelning.
• Nätverksbegränsade miljöer – binära gRPC-meddelanden är alltid mindre än ett motsvarande textbaserat JSON-meddelande.

När detta skrivs används gRPC främst med serverdelstjänster. Moderna webbläsare kan inte tillhandahålla den nivå av HTTP/2-kontroll som krävs för att stödja en klientdels gRPC-klient. Det finns dock stöd för gRPC-Web med .NET som möjliggör gRPC-kommunikation från webbläsarbaserade appar som skapats med JavaScript eller Blazor WebAssembly tekniker. gRPC-Web gör det möjligt för en ASP.NET Core gRPC-app att stödja gRPC-funktioner i webbläsarappar:

• Starkt skrivna, kodgenererade klienter
• Kompakta Protobuf-meddelanden
• Serverströmning

gRPC-implementering

Referensarkitekturen för mikrotjänster, eShop on Containers, från Microsoft, visar hur du implementerar gRPC-tjänster i .NET-program. Bild 4–22 visar serverdelsarkitekturen.

Bild 4-22. Serverdelsarkitektur för eShop på containrar

I föregående bild bör du notera hur eShop omfattar mönstret Serverdelen för klientdelar (BFF) genom att exponera flera API-gatewayer. Vi diskuterade BFF-mönstret tidigare i det här kapitlet. Var uppmärksam på mikrotjänsten Aggregator (i grått) som finns mellan WEB-Shopping API Gateway och serverdelen Shopping-mikrotjänster. Aggregatorn tar emot en enda begäran från en klient, skickar den till olika mikrotjänster, aggregerar resultatet och skickar tillbaka dem till den begärande klienten. Sådana åtgärder kräver vanligtvis synkron kommunikation för att generera ett omedelbart svar. I eShop utförs serverdelsanrop från Aggregator med hjälp av gRPC enligt bild 4–23.

Bild 4-23. gRPC i eShop på containrar

gRPC-kommunikation kräver både klient- och serverkomponenter. I föregående bild bör du notera hur Shopping Aggregator implementerar en gRPC-klient. Klienten gör synkrona gRPC-anrop (i rött) till serverdelsmikrotjänster, som var och en implementerar en gRPC-server. Både klienten och servern drar nytta av den inbyggda gRPC-VVS från .NET SDK. På klientsidan tillhandahålls VVS för att anropa fjärr-gRPC-anrop. Komponenter på serversidan tillhandahåller gRPC-VVS som anpassade tjänstklasser kan ärva och använda.

Mikrotjänster som exponerar både ett RESTful-API och gRPC-kommunikation kräver flera slutpunkter för att hantera trafik. Du öppnar en slutpunkt som lyssnar efter HTTP-trafik för RESTful-anropen och en annan för gRPC-anrop. GRPC-slutpunkten måste konfigureras för DET HTTP/2-protokoll som krävs för gRPC-kommunikation.

Vi strävar efter att frikoppla mikrotjänster med asynkrona kommunikationsmönster, men vissa åtgärder kräver direkta anrop. gRPC bör vara det primära valet för direkt synkron kommunikation mellan mikrotjänster. Dess högpresterande kommunikationsprotokoll, baserat på HTTP/2 och protokollbuffertar, gör det till ett perfekt val.

Blickar framåt

Framöver kommer gRPC att fortsätta att få dragkraft för molnbaserade system. Prestandafördelarna och den enkla utvecklingen är övertygande. REST kommer dock sannolikt att finnas kvar under en lång tid. Den utmärker sig för offentligt exponerade API:er och av bakåtkompatibilitetsskäl.

FöregåendeNästa