| gRPC | |
|---|---|
| Típusú | távoli eljáráshívás keretrendszer |
| Fejlesztő | |
| Beírva | Android Java, C#, C++, Dart, Go, Java, Kotlin/JVM, Node.js, Objective-C, PHP, Python, Ruby |
| Első kiadás | 2016. augusztus |
| legújabb verzió | 1.33.2 |
| Engedély | Apache licenc 2.0 |
| Weboldal | grpc.io |
A gRPC ( Remote Procedure Calls ) egy nyílt forráskódú távoli eljáráshívási (RPC) rendszer , amelyet eredetileg a Google fejlesztett ki 2015-ben. A HTTP/2 -t átvitelként, a protokollpuffereket pedig interfészleíró nyelvként használják . A gRPC olyan funkciókat biztosít, mint a hitelesítés , a kétirányú streamelés és az áramlásvezérlés, a blokkoló vagy nem blokkoló összerendelés, valamint a visszavonás és az időtúllépés. Platformok közötti kliens- és szerver-összerendeléseket generál számos nyelvhez. Leggyakrabban szolgáltatások mikroszolgáltatás-szerű architektúrában való összekapcsolására, valamint mobileszközök és böngészőkliensek háttérszolgáltatásokhoz való csatlakoztatására használják.
A HTTP/2 komplex használata a gRPC-ben lehetetlenné teszi a gRPC-kliens böngészőben való megvalósítását – helyette proxyra van szükség.
A gRPC támogatja a TLS és a token alapú hitelesítés használatát . A Google-szolgáltatásokhoz való csatlakozáshoz TLS -t kell használni . A hitelesítési adatoknak két típusa van: a csatorna hitelesítő adatai és a hívási hitelesítő adatok.
A gRPC protokollpuffereket használ az adatok kódolására. A JSON-t tartalmazó HTTP API -val ellentétben szigorúbb specifikációkkal rendelkeznek.
A gRPC-ben egy kliens alkalmazás közvetlenül hívhat meg egy kiszolgálóalkalmazás metódust egy másik gépen, mintha az egy helyi objektum lenne, ami megkönnyíti az elosztott alkalmazások és szolgáltatások létrehozását. Mint sok RPC rendszer, a gRPC is egy szolgáltatás meghatározásán alapul, olyan metódusok meghatározásán, amelyek paramétereikkel és visszatérési típusaikkal távolról hívhatók. A szerver oldalon a szerver megvalósítja ezt az interfészt, és elindítja a gRPC szervert az ügyfélhívások feldolgozására. A kliens oldalon van egy csonk (egyes nyelveken egyszerűen kliensnek hívják), amely ugyanazokat a metódusokat fedi fel, mint a szerver.
A gRPC- kliensek és -kiszolgálók számos környezetben futhatnak és kommunikálhatnak egymással, és bármelyik támogatott gRPC-nyelven írhatók.
Alapértelmezés szerint a gRPC a Protobuf -ot használja interfészdefiníciós nyelvként ( IDL ) a szolgáltatási interfész és a hasznos üzenetek szerkezetének leírására. Kívánság szerint más alternatívák is használhatók.
A gRPC négyféle szolgáltatási módszer meghatározását teszi lehetővé:
A fájlban található szolgáltatásdefiníciótól kezdve a .protogRPC olyan Protocol Buffers fordítóbővítményeket biztosít , amelyek kliens- és kiszolgálókódot generálnak. A gRPC-felhasználók általában az ügyféloldalon hívják meg ezeket az API-kat, és a szerver oldalon valósítják meg a megfelelő API-t.
A szinkron RPC-k, amelyek addig blokkolnak, amíg nem érkezik válasz a kiszolgálótól, a legközelebbi közelítések az RPC által megcélzott eljáráshívás-absztrakcióhoz. Másrészt a hálózatok eredendően aszinkronok, és sok esetben hasznos az RPC futtatása az aktuális szál blokkolása nélkül.
A gRPC programozási API a legtöbb nyelven szinkron és aszinkron ízekkel is rendelkezik.
Az ügyfél egy kérést küld, és egy választ ad vissza.
A szerver streaming RPC hasonló az unary RPC-hez, azzal a különbséggel, hogy a szerver üzenetfolyamot ad vissza válaszul az ügyfél kérésére. Az összes üzenet elküldése után a szerver állapotinformációit (állapotkódot és opcionális állapotüzenetet) és további végső metaadatokat küld a kliensnek. Ezzel befejeződik a szerveroldali feldolgozás. A kliens akkor lép ki, ha az összes üzenetet megkapta a szervertől.
A streaming kliens RPC hasonló az unary RPC-hez, azzal a különbséggel, hogy az ügyfél egyetlen üzenet helyett üzenetfolyamot küld a kiszolgálónak. A szerver egyetlen üzenettel válaszol (az állapotinformációkkal és a további végső metaadatokkal együtt), általában, de nem feltétlenül azután, hogy megkapta a kliens összes üzenetét.
A kétirányú streameléssel rendelkező RPC-ben a hívást a metódust hívó kliens és a kliens metaadatait, metódusnevét és határidejét fogadó szerver kezdeményezi. A szerver választhat, hogy elküldi a kezdeti metaadatait, vagy megvárja, amíg a kliens megkezdi az üzenetek streamelését.
Az adatfolyam feldolgozása a kliens oldalon és a szerver oldalon az alkalmazástól függ. Mivel a két szál független, a kliens és a szerver bármilyen sorrendben olvashatja és írhatja az üzeneteket. Például a szerver megvárhatja, amíg megkapja a kliens összes üzenetét, mielőtt megírná a saját üzeneteit, vagy a szerver és a kliens játszhat " ping-pongot " - a szerver kap egy kérést, majd választ, majd a kliens küld egy másikat. kérés a válasz alapján, és így tovább.
A gRPC lehetővé teszi az ügyfelek számára, hogy meghatározzák, mennyi ideig hajlandóak várni az RPC befejezésére, mielőtt az RPC meghiúsulna. A szerver oldalon a szerver megkérdezheti, hogy egy adott RPC lejárt-e, vagy mennyi ideje van hátra az RPC befejezéséhez.
A határidő vagy az időtúllépés megadása nyelvfüggő: egyes nyelvi API-k időtúllépések (időtartamok) szerint működnek, egyes nyelvi API-k pedig határidők (fix időpont) szerint működnek, és lehet, hogy van alapértelmezett határidő. .
A gRPC-ben mind a kliens, mind a szerver egymástól függetlenül és helyileg határoz meg egy hívás sikerességét, és előfordulhat, hogy következtetéseik nem egyeznek. Ez azt jelenti, hogy például rendelkezhet egy RPC-vel, amely sikeres a szerver oldalon, de sikertelen a kliens oldalon. A szerver dönthet úgy is, hogy leállítja, mielőtt az ügyfél az összes kérését elküldte volna.
A kliens vagy a szerver bármikor törölheti az RPC-t. A törlés azonnali hatállyal megszünteti az RPC-t, így nem történik további munka.
A metaadatok egy adott RPC-hívásra vonatkozó információk (például hitelesítési részletek) kulcs-érték párok listája formájában, ahol a kulcsok karakterláncok, az értékek pedig általában karakterláncok, de lehetnek bináris adatok. A metaadatok átlátszatlanok magának a gRPC-nek – ez lehetővé teszi a kliens számára, hogy a hívással kapcsolatos információkat közöljön a szerver felé, és fordítva.
A metaadatokhoz való hozzáférés nyelvenként eltérő.
A gRPC-csatorna kapcsolatot biztosít a megadott gazdagépen és porton lévő gRPC-kiszolgálóval. Kliens csonk létrehozásakor használatos. Az ügyfelek megadhatnak csatornaargumentumokat a gRPC alapértelmezett viselkedésének megváltoztatásához, például engedélyezhetik vagy letilthatják az üzenettömörítést.
A nyelvtől függ, hogy a gRPC hogyan dönt a csatorna bezárása mellett. Egyes nyelvek lehetővé teszik a csatorna állapotának lekérdezését is.
Számos különböző szervezet alkalmazta a gRPC-t, például a Square , a Netflix , az IBM , a CoreOS , a Docker , a CockroachDB , a Cisco , a Juniper Networks , [1] a Spotify , [2] és a Dropbox . [3]
A nyílt forráskódú u-bmc projekt IPMI helyett gRPC-t használ . 2019. január 8-án a Dropbox bejelentette, hogy a Courier következő verzióját, a SOA architektúrájának középpontjában álló RPC-keretrendszerüket áttelepítik a gRPC-re, elsősorban azért, mert jól illeszkedik a meglévő egyéni RPC-keretrendszereikhez.