Google’s gRPC - ett nyare kommunikationsprotokoll

25 May 2018 // Magnus Ekstrand

I början av maj gick KubeCon + CloudNativeCon Europe 2018 i Köpenhamn av stapeln. Ett ämne som fick stort utrymme på konferensen var gRPC som lades fram some ett super-snabbt och effektivt Remote Procedure Call-system (RPC) som ska göra att microservices pratar med varandra med ljusets hastighet…

Vad är gRPC?

gRPC är en RPC-plattform med som utvecklats av Google och som blev öppen källkod i början av 2015. Vid första anblicken påminde mig gRPC om CORBA. Båda ramverken deklarerar tjänster i ett språk-agnostiskt gränssnitt (IDL) för att sedan generera språkspecifika bindningar.

Både CORBA och gRPC är utformade för att klienterna ska tro att servern är på samma maskin. Klienter anropar en metod på stubben, som hanteras transparent genom det underliggande protokollet. Men där slutar också likheterna. För att förstå vad gRPC egentligen är, låt oss titta på se på vad vi är vana vid, d.v.s REST API, och göra en jämförelse.

Det som används i många tillämpningar idag

 REST API = HTTP1.1 + REST + JSON

gRPC

gRPC = Google + RPC Framework
gRPC = Google + (HTTP2 + Remote Procedure Call + Protobuf)

Remote Procedure Call

Remote Procedure Call eller RPC är när “… en procedur (subrutin) i ett dataprogram utföras i ett annat adressutrymme (vanligtvis på en annan dator i ett gemensamt nätverk) som om det var ett normalt (lokalt) proceduranrop utan att programmeraren kodar explicita detaljer för (fjärr)interaktionen.”

Vi är vana att göra detta med våra REST API-server / klienter. Vi exekverar kod på en annan dator utan att uttryckligen skriva kommandon på just den datorn. Skillnaden mellan REST och RPC är i huvudsak hur du exponerar serverns endpoints. Som exempel kanske en REST-server endast tillhandahåller CRUD-operationer på ett objekt, medan en RPC-server kan exponera mer allmänna funktioner som t.ex genHash().

gRPC-protokollet

Protokollet är baserat på HTTP2 som är nästa generation WWW-protokoll. gRPC stödjer flera inbyggda funktioner ärvda från HTTP2. Till exempel går det att ha duplexkommunikationen (dubbelriktad) över en enda anslutning vilket är en av anledningarna till att gRPC sägs vara “högpresterande”. I andra ord; med en (1) anslutning mellan server och klient kan data överföras i båda riktningarna samtidigt.

En annan bieffekt av HTTP2 är att gRPC kräver en TLS-anslutning. Det betyder emellertid inte att din anslutning alltid är säker, utan det betyder att om (och endast om) du har en säker anslutning så kan du använda HTTP2.

gRPC erbjuder två typer för klient/server-kommunikation

Unär

I huvudsak är det synkrona förfrågningar som görs till gRPC-servern med en request som blockerar tills ett svar tas emot.

Strömmar

Strömmar är riktigt kraftfullt och kan användas på tre olika sätt:

• klient pushar meddelanden till en ström
• server pushar meddelanden till en ström
• dubbelriktad: både klient och server skickar data i två strömmar i samma metod.

En ström ger ingen kvittens för mottagande av meddelande förrän strömmen slutförts. Men det går att lösa genom att använda en dubbelriktad ström för att returnera ACKs.

Serialisering

Protocol Buffers eller Protobufs är en av Googles metoder för att serialisera strukturerad data. Med Protobuf kan vi definiera strukturen (eller vågar jag säga schema) för vår data i .proto-filer. Med hjälp av en Protobuf Compiler kan vi sedan generea datastrukturen på önskat programmeringsspråk. På så sätt går det att definiera strukturen en gång och använda den för många språk.

Protobuf gör det möjligt att skicka små meddelande med snabb kodning/avkodning. Till skillnad från andra serialiseringsformat som JSON eller XML försöker Protobuf att minimera tiden för kodning/avkodning genom att tillhandahålla starkt typade fält i ett binärt format som snabbt kan läsas på ett förutsägbart sätt.

Den senaste versionen av Protocol Buffer är proto3, som stöder (antingen officiellt eller via tredjeparts applikationer) kodgenerering för C++, Java, Python, JavaNano, Go, Ruby, Objective-C, C#, JavaScript, Perl, PHP, Scala, Julia.

REST vs. gRPC

Så vad betyder allt detta för API-design? Och mer specifikt, vad betyder detta för REST? Skillnaden mellan REST och RPC är enkel - REST exponerar data som resurser som man agerar på, medan RPC exponerar operationer som en metod för att agera på data.

Problemet är att vi kan få RPC-liknande funktionalitet med hjälp av REST, och att vi kan få REST-liknande funktionalitet med hjälp av RPC. Att använda REST med HTTP har till exempel fördelarna med den förutsägbarhet som kommer från dess HTTP-arv. RPC har inte denna fördel men kan omvänt utnyttja nyare lösningar såsom HTTP2 i fallet med gRPC. Diskussionen REST över RPC och vise versa är egentligen ointressant. Det är problemets sammanhang som bör avgöra vilken lösning som är bättre. Och som med alla applikationer så kokar detta ned till de specifika användningsfall som man har att ta ställning till.

Summering

Jämfört med REST + JSON ska gRPC ge en bättre prestanda och säkerhet. gRPC främjar användning av SSL / TLS för server-autentisering och kryptering av den data som utväxlas mellan klient och server.

Är man van vid REST APIs där HTTP1.1, REST, och JSON används och vill börja använda gRPC krävs nya tekniker

HTTP1.1 => HTTP2
REST => RPC
JSON => Protobuf

gRPC är en utveckling av den klassiska RPC-strukturen men nyttjar moderna protokoll för en ny generation av högeffektiv och smidig interoperabilitet. När vi numer börjar använda fler och mindre enheter med högre efterfrågan på bearbetning kommer lösningar som gRPC att utmana det REST-centrerade paradigmet som hittills varit ganska ohotat.

Men en övergång från REST till gRPC har emellertid vissa smärtpunkter för alla utvecklare på grund av saknade alternativ för vanliga verktyg. Att skicka JSON över cURL fungerar inte. Det finns ingen integration med Swagger / OpenAPI. Alternativ till grafiska gränssnitt som Postman eller Swagger UI existerar inte. Allt sådant som vi vant oss vid i vårt dagliga arbete är borta.