gRPC

Tip

Deze inhoud is een fragment uit het eBook, Cloud Native .NET Applications for Azure ontwerpen, beschikbaar op .NET Docs of als een gratis downloadbare PDF die offline kan worden gelezen.

PDF downloaden

Tot nu toe hebben we ons gericht op REST-communicatie . We hebben gezien dat REST een flexibele architectuurstijl is die CRUD-bewerkingen definieert op basis van entiteitsresources. Clients communiceren met resources in HTTP met een communicatiemodel voor aanvragen/antwoorden. Hoewel REST op grote schaal wordt geïmplementeerd, heeft een nieuwere communicatietechnologie, gRPC, een enorme impuls gekregen in de cloudeigen community.

Wat is gRPC?

gRPC is een modern, high-performance framework dat het verouderde RPC-protocol (Remote Procedure Call) ontwikkelt. Op toepassingsniveau stroomlijnt gRPC berichten tussen clients en back-endservices. GRPC is afkomstig van Google en maakt deel uit van het CNCF-ecosysteem (Cloud Native Computing Foundation) van cloudeigen producten. CNCF beschouwt gRPC als een incubatingproject. Incubating betekent dat eindgebruikers de technologie in productietoepassingen gebruiken en dat het project een gezond aantal inzenders heeft.

Een typische gRPC-client-app maakt een lokale, in-process functie beschikbaar waarmee een bedrijfsbewerking wordt geïmplementeerd. Onder de dekkingen roept die lokale functie een andere functie aan op een externe computer. Wat een lokale aanroep lijkt te zijn, wordt in feite een transparante out-of-process-aanroep naar een externe service. De RPC-loodgieters abstraheren de point-to-point-netwerkcommunicatie, serialisatie en uitvoering tussen computers.

In cloudeigen toepassingen werken ontwikkelaars vaak in programmeertalen, frameworks en technologieën. Deze interoperabiliteit bemoeilijkt berichtcontracten en het loodgieterwerk dat nodig is voor platformoverschrijdende communicatie. gRPC biedt een 'uniforme horizontale laag' waarmee deze problemen worden geabstraheerd. Ontwikkelaars coderen in hun systeemeigen platform gericht op bedrijfsfunctionaliteit, terwijl gRPC communicatiepruiming afhandelt.

gRPC biedt uitgebreide ondersteuning voor de populairste ontwikkelstacks, waaronder Java, JavaScript, C#, Go, Swift en NodeJS.

gRPC-voordelen

gRPC maakt gebruik van HTTP/2 voor het transportprotocol. Hoewel http 1.1 compatibel is, beschikt HTTP/2 over veel geavanceerde mogelijkheden:

• Een binair frameprotocol voor gegevenstransport, in tegenstelling tot HTTP 1.1, dat is gebaseerd op tekst.
• Multiplexing-ondersteuning voor het verzenden van meerdere parallelle aanvragen via dezelfde verbinding: HTTP 1.1 beperkt de verwerking tot één aanvraag-/antwoordbericht tegelijk.
• Bidirectionele full-duplex communicatie voor het gelijktijdig verzenden van clientaanvragen en serverreacties.
• Ingebouwde streaming waarmee aanvragen en antwoorden asynchroon grote gegevenssets kunnen worden gestreamd.
• Compressie van headers die het netwerkgebruik verminderen.

gRPC is lichtgewicht en zeer goed presterend. Het kan maximaal 8x sneller zijn dan JSON-serialisatie met berichten van 60-80% kleiner. In microsoft Windows Communication Foundation (WCF) -parlance overschrijdt gRPC-prestaties de snelheid en efficiëntie van de uiterst geoptimaliseerde NetTCP-bindingen. In tegenstelling tot NetTCP, dat de Voorkeur geeft aan de Microsoft-stack, is gRPC platformoverschrijdend.

Protocol Buffers

gRPC omarmt een opensource-technologie met de naam Protocol Buffers. Ze bieden een zeer efficiënte en platformneutrale serialisatie-indeling voor het serialiseren van gestructureerde berichten die services naar elkaar verzenden. Met behulp van een platformoverschrijdende Interface Definition Language (IDL) definiëren ontwikkelaars een servicecontract voor elke microservice. Het contract, geïmplementeerd als een tekstbestand .proto , beschrijft de methoden, invoer en uitvoer voor elke service. Hetzelfde contractbestand kan worden gebruikt voor gRPC-clients en -services die zijn gebouwd op verschillende ontwikkelplatforms.

Met behulp van het proto-bestand genereert de Protobuf-compiler, protoczowel client- als servicecode voor uw doelplatform. De code bevat de volgende onderdelen:

• Sterk getypte objecten, gedeeld door de client en service, die de servicebewerkingen en gegevenselementen voor een bericht vertegenwoordigen.
• Een sterk getypte basisklasse met de vereiste netwerkpruimen die de externe gRPC-service kan overnemen en uitbreiden.
• Een client-stub die de vereiste loodgieter bevat om de externe gRPC-service aan te roepen.

Tijdens runtime wordt elk bericht geserialiseerd als een standaard Protobuf-weergave en uitgewisseld tussen de client en externe service. In tegenstelling tot JSON of XML worden Protobuf-berichten geserialiseerd als gecompileerde binaire bytes.

gRPC-ondersteuning in .NET

gRPC is geïntegreerd in .NET Core 3.0 SDK en hoger. De volgende hulpprogramma's ondersteunen het:

• Visual Studio 2022 waarop de workload voor ASP.NET en webontwikkeling is geïnstalleerd
• Visual Studio Code
• De dotnet CLI

De SDK bevat hulpprogramma's voor eindpuntroutering, ingebouwde IoC en logboekregistratie. De opensource-Kestrel-webserver ondersteunt HTTP/2-verbindingen. Afbeelding 4-20 toont een Visual Studio 2022-sjabloon die een skeletproject voor een gRPC-service opstelt. U ziet hoe .NET windows, Linux en macOS volledig ondersteunt.

Afbeelding 4-20. gRPC-ondersteuning in Visual Studio 2022

Afbeelding 4-21 toont de skeleton gRPC-service die is gegenereerd op basis van de ingebouwde scaffolding die is opgenomen in Visual Studio 2022.

Afbeelding 4-21. gRPC-project in Visual Studio 2022

Noteer in de vorige afbeelding het protobeschrijvingsbestand en de servicecode. Zoals u binnenkort ziet, genereert Visual Studio extra configuratie in zowel de opstartklasse als het onderliggende projectbestand.

gRPC-gebruik

Gunst gRPC voor de volgende scenario's:

• Synchrone back-end-microservice-naar-microservicecommunicatie waarbij een onmiddellijke reactie nodig is om de verwerking voort te zetten.
• Polyglot-omgevingen die ondersteuning moeten bieden voor gemengde programmeerplatforms.
• Communicatie met lage latentie en hoge doorvoer, waarbij de prestaties essentieel zijn.
• Point-to-point realtime communicatie - gRPC kan berichten in realtime pushen zonder polling en heeft uitstekende ondersteuning voor bidirectionele streaming.
• Netwerkbeperkingsomgevingen: binaire gRPC-berichten zijn altijd kleiner dan een equivalent JSON-bericht op basis van tekst.

Op dit moment wordt gRPC voornamelijk gebruikt met back-endservices. Moderne browsers kunnen geen HTTP/2-besturingselement bieden dat is vereist voor de ondersteuning van een front-end gRPC-client. Dat gezegd hebbende, is er ondersteuning voor gRPC-Web met .NET waarmee gRPC-communicatie mogelijk is vanuit browser-apps die zijn gebouwd met JavaScript of Blazor WebAssembly technologieën. met gRPC-Web kan een ASP.NET Core gRPC-app ondersteuning bieden voor gRPC-functies in browser-apps:

• Sterk getypte, door code gegenereerde clients
• Compacte Protobuf-berichten
• Serverstreaming

gRPC-implementatie

De referentiearchitectuur voor microservices, eShop on Containers, van Microsoft, laat zien hoe u gRPC-services implementeert in .NET-toepassingen. Afbeelding 4-22 geeft de back-endarchitectuur weer.

Afbeelding 4-22. Back-endarchitectuur voor eShop on Containers

In de vorige afbeelding ziet u hoe eShop het patroon Back-end voor front-ends (BFF) omarmt door meerdere API-gateways beschikbaar te maken. We hebben eerder in dit hoofdstuk het BFF-patroon besproken. Let goed op de Aggregator-microservice (grijs) die zich bevindt tussen de Web-Shopping API Gateway en back-end shopping microservices. De Aggregator ontvangt één aanvraag van een client, verzendt deze naar verschillende microservices, voegt de resultaten samen en stuurt deze terug naar de aanvragende client. Dergelijke bewerkingen vereisen doorgaans synchrone communicatie om een onmiddellijke reactie te produceren. In eShop worden back-end-aanroepen van de Aggregator uitgevoerd met gRPC, zoals weergegeven in afbeelding 4-23.

Afbeelding 4-23. gRPC in eShop on Containers

gRPC-communicatie vereist zowel client- als serveronderdelen. In de vorige afbeelding ziet u hoe de Shopping Aggregator een gRPC-client implementeert. De client maakt synchrone gRPC-aanroepen (rood) naar back-end microservices, die elk een gRPC-server implementeren. Zowel de client als de server profiteren van de ingebouwde gRPC-sanitair van de .NET SDK. Stubs aan de clientzijde bieden de sanitair om externe gRPC-aanroepen aan te roepen. Onderdelen aan de serverzijde bieden gRPC-loodgieters die aangepaste serviceklassen kunnen overnemen en gebruiken.

Microservices die zowel een RESTful-API als gRPC-communicatie beschikbaar maken, vereisen meerdere eindpunten om verkeer te beheren. U opent een eindpunt dat luistert naar HTTP-verkeer voor de RESTful-aanroepen en een ander eindpunt voor gRPC-aanroepen. Het gRPC-eindpunt moet worden geconfigureerd voor het HTTP/2-protocol dat is vereist voor gRPC-communicatie.

Hoewel we ernaar streven om microservices los te koppelen aan asynchrone communicatiepatronen, vereisen sommige bewerkingen directe aanroepen. gRPC moet de primaire keuze zijn voor directe synchrone communicatie tussen microservices. Het krachtige communicatieprotocol, gebaseerd op HTTP/2- en protocolbuffers, maakt het een perfecte keuze.

Vooruitblikkend

Vooruitkijkend zal gRPC nog steeds grip blijven krijgen op cloudeigen systemen. De prestatievoordelen en het gemak van ontwikkeling zijn aantrekkelijk. REST is echter waarschijnlijk al heel lang rond. Het excelt voor openbaar blootgestelde API's en om achterwaartse compatibiliteitsredenen.

VorigeVolgende