RPC, JSON-RPC és gRPC

Célok

A lecke végére el tudod magyarázni az RPC műveletközpontú modelljét, meg tudod különböztetni a JSON-RPC-t és a gRPC-t, és a hét szempont szerint jellemezni tudod őket.

Miért kell?

Nem minden együttműködés illik erőforrásmodellbe. Ha a hívó egy műveletet akar végrehajtani („foglalj”, „számolj árat”), a művelet természetes központja az interfésznek. Az RPC ezt a modellt viszi át hálózatra.

Mi az RPC?

Az RPC (távoli eljáráshívás) esetén az interfész központjában a távolról meghívható művelet áll: a hívó megmondja a műveletet és a paramétereket, a protokoll továbbítja a paramétereket, az eredményt és a hibát. A hálózati határhoz megfelelő műveletméret kell: az RPC nem jogosít fel finom belső metódusok publikálására.

A JSON-RPC 2.0 specifikáció szerint a kérés tagjai: jsonrpc (értéke „2.0”), method (a hívott eljárás neve), params (pozíció vagy név szerinti paraméterek, opcionális) és id (a kliens állítja be, a válasz összepárosítására). A szerver a válaszban ugyanazt az id-t adja vissza. Az id nélküli kérés notification, amelyre a szerver nem válaszolhat. A kérésazonosító a válasz párosítására szolgál, nem automatikusan üzleti idempotenciakulcs.

{ "jsonrpc": "2.0", "method": "ReserveSeats",
  "params": { "eventId": "e-12", "seatIds": ["a-1", "a-2"] }, "id": "call-17" }

gRPC

A gRPC (az RPC egy gyakori keretrendszere) alapértelmezetten Protocol Buffers nyelven (az IDL, azaz interface definition language, interfészleíró nyelv szerepében) írja le a szolgáltatást és az üzeneteket, és ebből kódot lehet generálni. A gRPC dokumentációja négyféle hívást különböztet meg: egyszerű (unary), szerver-stream, kliens-stream és kétirányú stream.

syntax = "proto3";
service Stock { rpc Reserve(ReserveRequest) returns (ReserveReply); }
message ReserveRequest { string request_id = 1; int32 quantity = 2; }
message ReserveReply { string reservation_id = 1; }

A protobuf-útmutató szerint a mezőszám a mező egyedi azonosítója az átviteli formátumban: használatban nem változtatható, és törölt mező száma nem használható fel újra, ezért a törölt számot reserved jelöléssel kell lefoglalni. A hiányzó mező olvasáskor típusfüggő alapértéket ad, és implicit jelenlétű mezőnél nem lehet megkülönböztetni az explicit alapértéket a be nem állítottól. A generált típusok mellett is szükséges üzleti validáció.

Időkeret: a gRPC a deadline fogalmát használja, alapértelmezett nincs; a lejáratkor DEADLINE_EXCEEDED hiba keletkezik (6.5). A megszakítás („cancellation”) a további munkát leállítja, de a dokumentáció szerint a megszakítás előtti változtatásokat nem görgeti vissza.

Böngészőből a szokásos módon nem hívható közvetlenül: a gRPC-Web nevű megoldás proxyn át engedi, hogy a böngésző elérje a gRPC-szolgáltatást.

Jellemzők

Szempont	RPC / gRPC
Irány	Kérés–válasz; streamnél egy- vagy kétirányú
Kezdeményező	A kliens (streamnél is a hívás indítása)
Kapcsolat tartóssága	Kérésenként vagy tartós csatornán többféle hívás
Késleltetés	Egy kérés–válasz út, gyakran kompaktabb formátum
Terhelés	Hívásonként; a stream csökkenti az ismételt kapcsolatfelépítést
Hibatűrés	Deadline, megszakítás; az ismétlés idempotenciát igényel
Mikor jó?	Belső szolgáltatáshívás, típusos szerződés, generálás, streaming
Mikor nem?	Közvetlen böngészős hívás, sok ismeretlen külső fogyasztó, gyorsítótárazható erőforrás-olvasás

Gyakori tévhitek

Állítás	Pontosítás
„A gRPC és az RPC ugyanaz.”	A gRPC egy konkrét RPC-keretrendszer.
„Az RPC azt jelenti, hogy a hívás helyi.”	Hálózati hívás: időtúllépés, részleges hiba.
„A kérésazonosító megvédi az ismétléstől.”	Csak ha a szerver idempotenciakulcsként kezeli.
„A generált típus megspórolja a validációt.”	Az üzleti szabályokat továbbra is ellenőrizni kell.

Röviden

• Az RPC műveletközpontú: a hívó eljárást hív, nem erőforrást kér.
• A JSON-RPC egyszerű szövegalapú protokoll; a gRPC típusos, generálható keretrendszer streaminggel.
• A mezőszám a szerződés része; törölt számot lefoglalni kell.
• A deadline és a megszakítás nem vonja vissza a már végrehajtott változást.

Ellenőrző kérdések

1. Mi különbözteti meg a korrelációs azonosítót az idempotenciakulcstól?
2. Mikor indokolt unary hívás helyett stream?
3. Mit kell ellenőrizni egy protobuf-séma módosításakor?

Források

• JSON-RPC 2.0 specification
• gRPC core concepts — hívásfajták, deadline, megszakítás.
• gRPC deadlines
• Protocol Buffers: proto3 — mezőszámok, reserved, alapértékek.