| gRPC | |
|---|---|
| Sorts | ram för anrop för fjärranrop |
| Utvecklaren | |
| Skrivet i | Android Java, C#, C++, Dart, Go, Java, Kotlin/JVM, Node.js, Objective-C, PHP, Python, Ruby |
| Första upplagan | augusti 2016 |
| senaste versionen | 1.33.2 |
| Licens | Apache-licens 2.0 |
| Hemsida | grpc.io |
gRPC ( Remote Procedure Calls ) är ett RPC -system ( Remote Procedure Call) med öppen källkod som ursprungligen utvecklades av Google 2015. HTTP/2 används som transport, Protocol Buffers används som gränssnittsbeskrivningsspråk . gRPC tillhandahåller funktioner som autentisering, dubbelriktad strömning och flödeskontroll, blockerande eller icke-blockerande bindningar, och annullering och timeout. Genererar plattformsoberoende klient- och serverbindningar för många språk. Det används oftast för att ansluta tjänster i en arkitektur av mikrotjänster och för att ansluta mobila enheter och webbläsarklienter till back-end-tjänster.
Den komplexa användningen av HTTP/2 i gRPC gör det omöjligt att implementera en gRPC-klient i en webbläsare – istället krävs en proxy.
gRPC stöder användningen av TLS och tokenbaserad autentisering . Anslutning till Googles tjänster måste använda TLS . Det finns två typer av autentiseringsuppgifter: kanaluppgifter och anropsuppgifter.
gRPC använder Protocol Buffers för att koda data. Till skillnad från HTTP API med JSON har de en striktare specifikation.
I gRPC kan en klientapplikation direkt anropa en serverapplikationsmetod på en annan maskin som om det vore ett lokalt objekt, vilket gör det lättare att skapa distribuerade applikationer och tjänster. Liksom många RPC-system är gRPC baserad på idén om att definiera en tjänst, definiera metoder som kan anropas på distans med sina parametrar och returtyper. På serversidan implementerar servern detta gränssnitt och startar gRPC-servern för att behandla klientanrop. På klientsidan finns en stubb (som helt enkelt kallas klienten på vissa språk) som exponerar samma metoder som servern.
gRPC- klienter och -servrar kan köras och kommunicera med varandra i en mängd olika miljöer och kan skrivas på något av de gRPC-språk som stöds.
Som standard använder gRPC Protobuf som gränssnittsdefinitionsspråk ( IDL ) för att beskriva tjänstegränssnittet och nyttolastmeddelandestrukturen. Andra alternativ kan användas om så önskas.
gRPC låter dig definiera fyra typer av servicemetoder:
Från och med en tjänstdefinition i .protoen fil tillhandahåller gRPC Protocol Buffers kompilatorplugin som genererar klient- och serverkod. gRPC-användare anropar vanligtvis dessa API:er på klientsidan och implementerar motsvarande API på serversidan.
Synkrona RPC:er, som blockerar tills ett svar tas emot från servern, är den närmaste approximationen till den proceduranropsabstraktion som RPC strävar efter. Å andra sidan är nätverk i sig asynkrona och i många scenarier är det användbart att kunna köra RPC utan att blockera den aktuella tråden.
gRPC programmerings-API på de flesta språk har både synkrona och asynkrona smaker.
Klienten skickar en begäran och returnerar ett svar.
Serverströmmande RPC liknar unär RPC, förutom att servern returnerar en ström av meddelanden som svar på en klientförfrågan. Efter att alla meddelanden har skickats skickas serverstatusinformation (en statuskod och ett valfritt statusmeddelande) och ytterligare slutlig metadata till klienten. Detta slutför bearbetningen på serversidan. Klienten avslutas när den har tagit emot alla meddelanden från servern.
Strömmande klient RPC liknar unär RPC, förutom att klienten skickar en ström av meddelanden till servern istället för ett enda meddelande. Servern svarar med ett enda meddelande (tillsammans med dess statusinformation och ytterligare slutlig metadata), vanligtvis men inte nödvändigtvis efter att den har tagit emot alla klientens meddelanden.
I RPC med dubbelriktad streaming initieras samtalet genom att klienten anropar metoden och servern tar emot klientens metadata, metodnamn och deadline. Servern kan välja att skicka sin ursprungliga metadata, eller vänta på att klienten ska börja streama meddelanden.
Strömbehandling på klientsidan och på serversidan beror på applikationen. Eftersom de två trådarna är oberoende kan klienten och servern läsa och skriva meddelanden i valfri ordning. Servern kan till exempel vänta tills den har tagit emot alla klientens meddelanden innan de skriver sina egna meddelanden, eller så kan servern och klienten spela " ping pong " - servern tar emot en förfrågan, skickar sedan ett svar, sedan skickar klienten en annan begäran baserad på svaret och så vidare.
gRPC tillåter klienter att ange hur länge de är villiga att vänta på att en RPC ska slutföras innan RPC misslyckas. På serversidan kan servern fråga om en viss RPC har tagit timeout eller hur mycket tid som är kvar för RPC att slutföra.
Att ange en deadline eller timeout är språkberoende: vissa språk-API:er fungerar i termer av timeouts (en lång tid), och vissa språk-API:er fungerar i termer av en deadline (en fast tidpunkt) och kan ha eller inte ha en standarddeadline .
I gRPC gör både klienten och servern oberoende och lokala bestämningar om framgången för ett samtal, och deras slutsatser kanske inte stämmer överens. Det betyder att man till exempel skulle kunna ha en RPC som lyckas på serversidan men misslyckas på klientsidan. Servern kan också besluta att avsluta innan klienten har skickat alla sina förfrågningar.
Klienten eller servern kan avbryta RPC när som helst. Avbokning avslutar RPC omedelbart, så inget ytterligare arbete görs.
Metadata är information om ett visst RPC-anrop (som autentiseringsdetaljer) i form av en lista med nyckel-värdepar, där nycklar är strängar och värden vanligtvis är strängar, men kan vara binära data. Metadatan är ogenomskinlig för själva gRPC - den tillåter klienten att tillhandahålla information relaterad till anropet till servern och vice versa.
Metadataåtkomst varierar beroende på språk.
En gRPC-kanal tillhandahåller en anslutning till en gRPC-server på den angivna värden och porten. Används när du skapar en klientstub. Klienter kan ange kanalargument för att ändra standardbeteendet för gRPC, som att aktivera eller inaktivera meddelandekomprimering.
Hur gRPC bestämmer sig för att stänga kanalen beror på språket. Vissa språk låter dig också fråga status för en kanal.
Ett antal olika organisationer har antagit gRPC som Square , Netflix , IBM , CoreOS , Docker , CockroachDB , Cisco , Juniper Networks , [1] Spotify , [2] och Dropbox . [3]
Open source-projektet u-bmc använder gRPC istället för IPMI . Den 8 januari 2019 tillkännagav Dropbox att nästa version av Courier, deras RPC-ramverk i hjärtat av deras SOA-arkitektur, kommer att migreras till gRPC, främst för att det passar bra med deras befintliga anpassade RPC-ramverk.