Jämför gRPC-tjänster med HTTP-API:er

Av James Newton-King

Den här artikeln förklarar hur gRPC-tjänster jämförs med HTTP-API:er med JSON (inklusive ASP.NET Core-webb-API:er). Tekniken som används för att tillhandahålla ett API för din app är ett viktigt val, och gRPC erbjuder unika fördelar jämfört med HTTP-API:er. Den här artikeln beskriver styrkor och svagheter i gRPC och rekommenderar scenarier för att använda gRPC framför andra tekniker.

High-level comparison

Följande tabell innehåller en jämförelse på hög nivå av funktioner mellan gRPC- och HTTP-API:er med JSON.

gRPC strengths

Performance

gRPC-meddelanden serialiseras med protobuf, ett effektivt binärt meddelandeformat. Protobuf serialiserar mycket snabbt på servern och klienten. Protobuf-serialisering resulterar i små meddelandenyttolaster, viktiga i scenarier med begränsad bandbredd, till exempel mobilappar.

gRPC är utformat för HTTP/2, en större revision av HTTP som ger betydande prestandafördelar jämfört med HTTP 1.x:

• Binär inramning och komprimering. HTTP/2-protokollet är kompakt och effektivt både när det gäller att skicka och ta emot.
• Multiplexering av flera HTTP/2-anrop via en enda TCP-anslutning. Multiplexering eliminerar blockering av huvudlinjen.

HTTP/2 är inte exklusivt för gRPC. Många typer av begäranden, inklusive HTTP-API:er med JSON, kan använda HTTP/2 och dra nytta av dess prestandaförbättringar.

Code generation

Alla gRPC-ramverk ger förstklassigt stöd för kodgenerering. En kärnfil till gRPC-utveckling är .proto filen, som definierar kontraktet för gRPC-tjänster och -meddelanden. Från den här filen genererar gRPC-ramverk en tjänstbasklass, meddelanden och en komplett klient.

Genom att dela .proto filen mellan servern och klienten kan meddelanden och klientkod genereras från slutpunkt till slutpunkt. Kodgenereringen av klienten eliminerar duplicering av meddelanden på klienten och servern och skapar en starkt skriven klient åt dig. Att inte behöva skriva en klient sparar betydande utvecklingstid i program med många tjänster.

Strict specification

Det finns ingen formell specifikation för HTTP API med JSON. Utvecklare diskuterar det bästa formatet för URL:er, HTTP-verb och svarskoder.

GRPC-specifikationen är normativ för det format som en gRPC-tjänst måste följa. gRPC eliminerar debatten och sparar utvecklartid eftersom gRPC är konsekvent mellan plattformar och implementeringar.

Streaming

HTTP/2 är en grund för långvariga kommunikationsströmmar i realtid. gRPC ger förstklassigt stöd för direktuppspelning via HTTP/2.

En gRPC-tjänst stöder alla strömningskombinationer:

• Unary (ingen direktuppspelning)
• Direktuppspelning från server till klient
• Direktuppspelning från klient till server
• Bi-directional streaming

Tidsgräns/tidsgränser och annullering

med gRPC kan klienter ange hur länge de är villiga att vänta tills en RPC har slutförts. Tidsgränsen skickas till servern och servern kan bestämma vilken åtgärd som ska vidtas om tidsgränsen överskrids. Servern kan till exempel avbryta pågående gRPC/HTTP/databasbegäranden vid tidsgräns.

Genom att sprida tidsgränsen och annulleringen via underordnade gRPC-anrop kan du framtvinga resursanvändningsgränser.

rekommenderade gRPC-scenarier

gRPC passar bra för följande scenarier:

• Mikrotjänster: gRPC är utformat för kommunikation med låg svarstid och högt dataflöde. gRPC är bra för lätta mikrotjänster där effektiviteten är kritisk.
• Punkt-till-punkt-realtidskommunikation: gRPC har utmärkt stöd för dubbelriktad direktuppspelning. gRPC-tjänster kan skicka meddelanden i realtid utan avsökning.
• Flerspråkiga miljöer: gRPC-verktyg stöder alla populära utvecklingsspråk, vilket gör gRPC till ett bra val för miljöer med flera språk.
• Nätverksbegränsade miljöer: gRPC-meddelanden serialiseras med Protobuf, ett enkelt meddelandeformat. Ett gRPC-meddelande är alltid mindre än ett motsvarande JSON-meddelande.
• Kommunikation mellan processer (IPC): IPC-transporter som Unix-domänuttag och namngivna rör kan användas med gRPC för att kommunicera mellan appar på samma dator. Mer information finns i kommunikation mellan processer med gRPC-.

gRPC weaknesses

Begränsat webbläsarstöd

Det är omöjligt att anropa en gRPC-tjänst direkt från en webbläsare i dag. gRPC använder i hög grad HTTP/2-funktioner och ingen webbläsare ger den kontrollnivå som krävs för webbbegäranden för att stödja en gRPC-klient. Webbläsare tillåter till exempel inte att en anropare kräver att HTTP/2 används eller ger åtkomst till underliggande HTTP/2-bildrutor.

gRPC på ASP.NET Core erbjuder två webbläsarkompatibla lösningar:

• gRPC-Web tillåter webbläsarappar att anropa gRPC-tjänster med gRPC-Web-klienten och Protobuf. gRPC-Web kräver att webbläsarappen genererar en gRPC-klient. gRPC-Web tillåter webbläsarappar att dra nytta av hög prestanda och låg nätverksanvändning av gRPC.

  .NET har inbyggt stöd för gRPC-Web. Mer information finns i gRPC-Web i ASP.NET Core gRPC-appar.

• gRPC JSON-omkodning gör att webbläsarappar kan anropa gRPC-tjänster som om de vore RESTful-API:er med JSON. Webbläsarappen behöver inte generera en gRPC-klient eller veta något om gRPC. RESTful-API:er kan skapas automatiskt från gRPC-tjänster genom att .proto kommentera filen med HTTP-metadata. Med transkodning kan en app stödja både gRPC- och JSON-webb-API:er utan att duplicera arbetet med att skapa separata tjänster för båda.

  .NET har inbyggt stöd för att skapa JSON-webb-API:er från gRPC-tjänster. Mer information finns i gRPC JSON-omkodning i ASP.NET Core gRPC-appar.

Inte läsbar för människor

HTTP API-begäranden skickas som text och kan läsas och skapas av människor.

gRPC-meddelanden kodas med Protobuf som standard. Även om Protobuf är effektivt att skicka och ta emot är dess binära format inte läsbart för människor. Protobuf kräver att meddelandets gränssnittsbeskrivning som anges i .proto filen deserialiseras korrekt. Ytterligare verktyg krävs för att analysera Protobuf-nyttolaster på kabeln och för att skapa begäranden för hand.

Funktioner som serverreflektion och gRPC-kommandoradsverktyget finns för att hjälpa till med binära Protobuf-meddelanden. Protobuf-meddelanden stöder också konvertering till och från JSON. Den inbyggda JSON-konverteringen är ett effektivt sätt att konvertera Protobuf-meddelanden till och från läsbar form när du felsöker.

Alternativa ramverksscenarier

Andra ramverk rekommenderas via gRPC i följande scenarier:

• Webbläsartillgängliga API:er: gRPC stöds inte fullt ut i webbläsaren. gRPC-Web kan erbjuda webbläsarstöd, men det har begränsningar och introducerar en serverproxy.
• Sänd realtidskommunikation: gRPC stöder realtidskommunikation via strömning, men begreppet sändning av ett meddelande till registrerade anslutningar finns inte. Till exempel i ett chattrumsscenario där nya chattmeddelanden ska skickas till alla klienter i chattrummet, krävs varje gRPC-samtal för att strömma nya chattmeddelanden individuellt till klienten. SignalR är ett användbart ramverk för det här scenariot. SignalR har begreppet beständiga anslutningar och inbyggt stöd för sändningsmeddelanden.

Additional resources

• Skapa en .NET gRPC-klient och -server i ASP.NET Core
• Översikt över gRPC på .NET
• gRPC-tjänster med C#
• Migrera gRPC från C-core till gRPC för .NET