Mi a gRPC? Protokoll pufferek, adatfolyam és architektúra magyarázata

A gRPC hatékony keretrendszer a távoli eljáráshívásokkal való együttműködéshez. Az RPC-k lehetővé teszik a kód írását, mintha egy helyi számítógépen futna, annak ellenére, hogy egy másik számítógépen futtatható.

Az elmúlt napokban mélyen belemerültem a gRPC-be. Itt fogom megosztani néhány nagy felfedezésemet ebben a cikkben.

Ne feledje, hogy inkább a koncepciókra fogok koncentrálni, mint a megvalósítás részleteire. Meg fogja tanulni a gRPC mag architektúráját. Azt is megtanulja:

  • Miért használják a fejlesztők olyan széles körben a gRPC-t?
  • Hogyan teljesít ilyen jól
  • És hogyan működik mindez a motorháztető alatt.

Menjünk vissza egy kicsit

Mielőtt belevágnánk a gRPC-be, meg kell vizsgálnunk, hogy mi a távoli eljáráshívás .

Az RPC az ügyfél-kiszolgáló kommunikáció egy olyan formája, amely a szokásos HTTP-hívás helyett függvényhívást használ.

Az IDL-t (Interface Definition Language) használja a meghívandó funkciókra és az adattípusra vonatkozó szerződés formájában.

Ha mindannyian még nem jöttek rá, az RPC a gRPC-ben a Távoli eljáráshívás rövidítése. És igen, a gRPC megismétli a kliens-szerver kommunikáció ezen architektúrális stílusát függvényhívásokon keresztül.

Tehát a gRPC technikailag nem új koncepció. Inkább ezt a régi technikát alkalmazta, és továbbfejlesztette, így nagyon népszerűvé vált mindössze 5 év alatt.

A gRPC áttekintése

2015-ben a Google nyitotta meg projektjüket, amely végül a gRPC nevet viseli. De mit jelent valójában a gRPC-ben szereplő "g"?

Sokan feltételezhetik a Google számára, mert a Google elkészítette, de nem.

A Google megváltoztatja az egyes verziók "g" jelentését arra a pontra, ahol még README-t is készítettek az összes jelentés felsorolásához.

A gRPC bevezetése óta elég nagy népszerűségre tett szert, és sok vállalat használja.

Mitől olyan népszerű a gRPC?

Rengeteg oka van annak, hogy a gRPC ilyen népszerű:

  • Az absztrakció egyszerű (ez egy függvényhívás)
  • Sok nyelven támogatott
  • Nagyon előadó
  • A HTTP hívások gyakran zavaróak, így ez megkönnyíti

A fenti okoktól eltekintve a gRPC azért népszerű, mert a mikroszolgáltatások nagyon népszerűek.

A mikroszolgáltatások gyakran több szolgáltatást futtatnak különböző programozási nyelveken. Gyakran sok szolgáltatást is nyújtanak a szolgáltatás interakcióihoz.

A gRPC itt segít a legjobban azáltal, hogy támogatást és képességet kínál az adott helyzetekből adódó tipikus problémák megoldására.

A gRPC nagyon népszerű a szervizhívások szolgáltatásában, mivel a HTTP hívásokat gyakran első pillantásra nehezebb megérteni.

A gRPC függvények sokkal könnyebben indokolhatók, ezért a fejlesztőknek nem kell aggódniuk sok dokumentáció megírása miatt, mert a kódnak mindent meg kell magyaráznia.

Lehet, hogy a szolgáltatások egy része különféle nyelveken is meg van írva, és a gRPC több könyvtárral is rendelkezik, hogy ezt támogassa.

A teljesítmény a cseresznye a tetején - és ez egy nagy cseresznye.

gRPC architektúra

Többször említettem, hogy a gRPC teljesítménye nagyon jó, de elgondolkodhatna azon, hogy mitől olyan jó? Mitől sokkal jobb a gRPC, mint az RPC, ha a kialakításuk meglehetősen hasonló?

Íme néhány kulcsfontosságú különbség, amely a gRPC-t annyira teljesítővé teszi.

HTTP / 2

A HTTP már régóta velünk van. Most szinte az összes háttérszolgáltatás használja ezt a protokollt.

Amint a fenti kép mutatja, a HTTP / 1.1 sokáig releváns maradt.

Aztán 2015-ben megjelent a HTTP / 2, amely lényegében felváltotta a HTTP / 1.1-et, mint az internet legnépszerűbb szállítási protokollját.

Ha emlékszel, hogy 2015-ben a gRPC is megjelent, az egyáltalán nem volt véletlen. A HTTP / 2-t a Google is létrehozta, hogy a gRPC fel tudja használni az architektúrájában.

A HTTP / 2 az egyik nagy oka annak, hogy a gRPC ilyen jól tud teljesíteni. És ebben a következő részben megtudhatja, miért.

Kérelem / válasz multiplexelés

A hagyományos HTTP protokollban nem lehet több kérést elküldeni vagy több választ kapni egyetlen kapcsolaton keresztül. Mindegyikükhöz új kapcsolatot kell létrehozni.

Ez a fajta kérés / válasz multiplexelés a HTTP / 2-ben lehetővé válik egy új, bináris keretezésnek nevezett HTTP / 2 réteg bevezetésével.

Ez a bináris réteg bezárja és kódolja az adatokat. Ebben a rétegben a HTTP kérés / válasz keretekre oszlik.

A fejléckeret tipikus HTTP fejlécinformációt tartalmaz, az adatkeret pedig a hasznos terhet. Ennek a mechanizmusnak a használatával lehetséges, hogy egyetlen kapcsolaton belül több kérésből is legyenek adatok.

Ez lehetővé teszi több kérelem hasznos terhelését ugyanazzal a fejléccel, ezáltal egyetlen kérésként azonosítva.

Fejléc tömörítés

Számos olyan esetet tapasztalhatott, amikor a HTTP fejlécek még nagyobbak is, mint a hasznos teher. Ennek kezelésére a HTTP / 2 egy nagyon érdekes stratégiával rendelkezik, amelynek neve HPack.

Egyrészt a HTTP / 2-ben mindent elküldés előtt kódolnak, beleértve a fejléceket is. Ez segít a teljesítményben, de nem ez a legfontosabb a fejléc tömörítésében.

A HTTP / 2 feltérképezi a fejlécet mind az ügyfél, mind a szerver oldalon. Ebből a HTTP / 2 meg tudja tudni, hogy a fejléc ugyanazt az értéket tartalmazza-e, és csak akkor küldi a fejléc értékét, ha az eltér az előző fejléctől.

Amint a fenti képen látható, a 2. kérelem csak az útvonalat küldi, mivel a többi érték pontosan megegyezik. És igen, ez sokat csökkent a hasznos teher méretében, és ez még jobban javítja a HTTP / 2 teljesítményét.

Protokoll puffer, más néven Protobuf

A Protobuf a leggyakrabban használt IDL (Interface Definition Language) a gRPC számára. Itt tárolja alapvetően adatait és függvényszerződéseit proto fájl formájában.

message Person { required string name = 1; required int32 id = 2; optional string email = 3; }

Mivel ez szerződés formájában van, az ügyfélnek és a szervernek is ugyanazzal a protofájlmal kell rendelkeznie. A protofájl közvetítői szerződésként szolgál az ügyfél számára a szerverről elérhető összes funkció meghívására.

A Protobuf rendelkezik mechanizmusokkal is, ellentétben egy szokásos REST API-val, amely csak a JSON húrjait küldi bájtként. Ezek a mechanizmusok lehetővé teszik, hogy a hasznos teher sokkal kisebb legyen, és gyorsabb teljesítményt nyújtsanak.

A Protobuf által használt kódolási módszer meglehetősen bonyolult. Ha mélyre akar merülni a működésében, nézze meg ezt az átfogó dokumentációt.

Mit kínál még a gRPC?

csillagok az égen

Most meg kell ismernie a gRPC architektúráját, működését és mire képes.

De itt van még néhány érdekes dolog, amelyet a gRPC kínál nekünk.

Metaadatok

A gRPC a szokásos HTTP kérés fejléc helyett metaadatokkal rendelkezik. A metaadatok olyan kulcsértékadatok, amelyeket az ügyfél vagy a kiszolgáló oldala állíthat be.

Headerhozzárendelhetők az ügyfél oldaláról, míg a szerverek hozzárendelhetnek Headerés Trailersmindaddig, amíg mindkettő metaadat formájában van.

Folyó

A streaming a gRPC egyik alapkoncepciója, ahol egy kéréssel több dolog is történhet. Ezt a korábban említett HTTP / 2 multiplexelési képesség teszi lehetővé.

A streamingnek több típusa van:

  • Server Streaming RPC: Ha az ügyfél egyetlen kérést küld, és a szerver több választ is visszaküldhet. Például, amikor az ügyfél kérést küld egy olyan weboldalra, amely több elem listájával rendelkezik, a kiszolgáló külön válaszolhat vissza, lehetővé téve az ügyfél számára a lusta betöltést.
  • Client Streaming RPC: Ha az ügyfél több kérést küld, és a szerver csak egyetlen választ küld vissza. Például az ügyfél által feltöltött zip / chunk.
  • Kétirányú streaming RPC: ahol az ügyfél és a kiszolgáló is egyszerre küld üzeneteket egymásnak, válaszra várva.

Elfogók

A gRPC támogatja az elfogók használatát kérésére / válaszára. Elfogók, jól, lehallgatják az üzeneteket, és lehetővé teszik azok módosítását.

Ez ismerősen hangzik? Ha már játszott a HTTP-folyamatokkal egy REST API-n, az elfogók nagyon hasonlítanak a köztes szoftverekre.

A gRPC könyvtárak általában támogatják az elfogókat, és lehetővé teszik az egyszerű megvalósítást. Az interceptorokat általában:

  • Az átadás előtt módosítsa a kérést / választ. Használható kötelező információk megadására, mielőtt elküldenék őket az ügyfélnek / szervernek.
  • Lehetővé teszi az egyes függvényhívások manipulálását, például további naplózás hozzáadásával a válaszidő nyomon követéséhez.

Terhelés elosztás

Ha még nem ismeri a terheléselosztást, akkor ez egy olyan mechanizmus, amely lehetővé teszi az ügyfélkérések több szerveren történő elosztását.

De a terheléselosztás általában proxy szinten történik (például NGINX). Akkor miért beszélek erről itt?

Kiderült, hogy a gRPC támogatja a kliens terheléselosztásának módszerét. Ez már a Golang könyvtárban megvalósult, és könnyedén használható.

Bár valamiféle őrült varázslatnak tűnhet, mégsem az. Van egyfajta DNS-megoldó egy IP-lista és egy terheléselosztó algoritmus számára a motorháztető alatt.

Hívás törlése

A gRPC kliensek képesek lemondani a gRPC hívást, amikor már nincs szükségük válaszra. Viszont a szerver oldalon nem lehet visszagörgetni.

Ez a szolgáltatás különösen a szerveroldali streaming esetén hasznos, ahol több szerver kérés érkezhet. A gRPC könyvtár megfigyelő módszer mintával rendelkezik, hogy megtudja, hogy egy kérést törölnek-e, és lehetővé teszi, hogy egyszerre több megfelelő kérést töröljön.

Csomagolás

Elveszett a térben és az időben

Minden, amit ma megosztottam, csak megkarcolja a gRPC felületét, mire képes és nagyjából hogyan is működik.

Nagyon remélem, hogy ez a cikk segített jobban megérteni a gRPC-t. De még mindig sokkal több a tanulás, ezért ne álljon meg itt! Áss tovább.

Köszönöm, hogy elolvasta!