| gRPC | |
|---|---|
| Tyyppi | etämenettelyn kutsukehys |
| Kehittäjä | |
| Sisään kirjoitettu | Android Java, C#, C++, Dart, Go, Java, Kotlin/JVM, Node.js, Objective-C, PHP, Python, Ruby |
| Ensimmäinen painos | elokuu 2016 |
| uusin versio | 1.33.2 |
| Lisenssi | Apache-lisenssi 2.0 |
| Verkkosivusto | grpc.io |
gRPC ( Remote Procedure Calls ) on avoimen lähdekoodin etämenettelypuhelu ( RPC) -järjestelmä, jonka Google on alun perin kehittänyt vuonna 2015. HTTP/2 :ta käytetään siirtona, protokollapuskuria käytetään käyttöliittymän kuvauskielenä . gRPC tarjoaa ominaisuuksia, kuten todennus , kaksisuuntainen suoratoisto ja vuon ohjaus, estävät tai estämättömät sidokset sekä peruutukset ja aikakatkaisut. Luo monialustaisia asiakas- ja palvelinsidoksia useille kielille. Sitä käytetään yleisimmin palveluiden yhdistämiseen mikropalvelutyylisessä arkkitehtuurissa ja mobiililaitteiden ja selainasiakkaiden yhdistämiseen taustapalveluihin.
HTTP/2:n monimutkainen käyttö gRPC:ssä tekee mahdottomaksi toteuttaa gRPC-asiakasohjelmaa selaimessa - sen sijaan tarvitaan välityspalvelin.
gRPC tukee TLS :n ja token - pohjaisen todennuksen käyttöä . Yhteyden Google-palveluihin on käytettävä TLS :ää . Tunnuksia on kahdenlaisia: kanavan tunnistetiedot ja puhelun tunnistetiedot.
gRPC käyttää protokollapuskureita tietojen koodaamiseen. Toisin kuin JSON:n sisältävällä HTTP API :lla, niillä on tiukemmat vaatimukset.
gRPC:ssä asiakassovellus voi kutsua suoraan palvelinsovellusmenetelmää toisella koneella ikään kuin se olisi paikallinen objekti, mikä helpottaa hajautettujen sovellusten ja palveluiden luomista. Kuten monet RPC-järjestelmät, myös gRPC perustuu ajatukseen palvelun määrittelystä, menetelmien määrittelystä, joita voidaan kutsua etänä parametreineen ja palautustyypeineen. Palvelinpuolella palvelin toteuttaa tämän rajapinnan ja käynnistää gRPC-palvelimen käsittelemään asiakaskutsuja. Asiakaspuolella on tynkä (joissakin kielissä yksinkertaisesti asiakas), joka paljastaa samat menetelmät kuin palvelin.
gRPC- asiakkaat ja -palvelimet voivat toimia ja kommunikoida keskenään erilaisissa ympäristöissä, ja ne voidaan kirjoittaa millä tahansa tuetuista gRPC-kielistä.
Oletusarvoisesti gRPC käyttää Protobufia rajapinnan määrityskielenä ( IDL ) palvelun rajapinnan ja hyötykuormaviestirakenteen kuvaamiseen. Muita vaihtoehtoja voidaan käyttää haluttaessa.
gRPC:n avulla voit määrittää neljän tyyppistä palvelumenetelmää:
Alkaen tiedostossa olevasta palvelun määritelmästä .proto, gRPC tarjoaa Protocol Buffers -kääntäjälaajennuksia , jotka luovat asiakas- ja palvelinkoodin. gRPC-käyttäjät kutsuvat tyypillisesti näitä API:ita asiakaspuolella ja toteuttavat vastaavan API:n palvelinpuolella.
Synkroniset RPC:t, jotka estävät, kunnes palvelimelta saadaan vastaus, ovat lähinnä RPC:n tavoittelemaa proseduurikutsun abstraktiota. Toisaalta verkot ovat luonnostaan asynkronisia, ja monissa skenaarioissa on hyödyllistä pystyä suorittamaan RPC:tä estämään nykyistä säiettä.
grRPC-ohjelmointisovellusliittymällä useimmilla kielillä on sekä synkronisia että asynkronisia makuja.
Asiakas lähettää yhden pyynnön ja palauttaa yhden vastauksen.
Palvelimen suoratoisto-RPC on samanlainen kuin yksipuolinen RPC, paitsi että palvelin palauttaa viestivirran vastauksena asiakkaan pyyntöön. Kun kaikki viestit on lähetetty, palvelimen tilatiedot (tilakoodi ja valinnainen tilaviesti) ja muut lopulliset metatiedot lähetetään asiakkaalle. Tämä päättää palvelinpuolen käsittelyn. Asiakas poistuu, kun se on vastaanottanut kaikki viestit palvelimelta.
Suoratoistoasiakkaan RPC on samanlainen kuin unary RPC, paitsi että asiakas lähettää palvelimelle viestivirran yhden viestin sijaan. Palvelin vastaa yhdellä viestillä (tilatietojen ja lopullisten metatietojen kera), yleensä, mutta ei välttämättä, sen jälkeen, kun se on vastaanottanut kaikki asiakkaan viestit.
RPC:ssä, jossa on kaksisuuntainen suoratoisto, puhelun aloittaa menetelmää kutsuva asiakas ja palvelin, joka vastaanottaa asiakkaan metatiedot, menetelmän nimen ja määräajan. Palvelin voi lähettää alkuperäisen metatietonsa tai odottaa, että asiakas aloittaa viestien suoratoiston.
Virtauskäsittely asiakas- ja palvelinpuolella riippuu sovelluksesta. Koska kaksi säiettä ovat riippumattomia, asiakas ja palvelin voivat lukea ja kirjoittaa viestejä missä tahansa järjestyksessä. Palvelin voi esimerkiksi odottaa, kunnes se on vastaanottanut kaikki asiakkaan viestit ennen kuin kirjoittaa omia viestejään, tai palvelin ja asiakas voivat pelata " ping pong " -palvelin vastaanottaa pyynnön, lähettää vastauksen, sitten asiakas lähettää toisen. pyyntö vastauksen perusteella ja niin edelleen.
gRPC:n avulla asiakkaat voivat määrittää, kuinka kauan he ovat valmiita odottamaan RPC:n valmistumista ennen kuin RPC epäonnistuu. Palvelinpuolella palvelin voi kysyä, onko tietty RPC aikakatkaissut tai kuinka paljon aikaa on jäljellä RPC:n suorittamiseen.
Määräajan tai aikakatkaisun määrittäminen riippuu kielestä: jotkin kielen sovellusliittymät toimivat aikakatkaisujen (ajan pituuden) suhteen, ja jotkut kielisovellusliittymät toimivat määräajan (kiinteän ajankohdan) mukaan, ja niillä voi olla tai ei ole oletusmääräaikaa. .
gRPC:ssä sekä asiakas että palvelin tekevät itsenäisiä ja paikallisia määrityksiä puhelun onnistumisesta, ja niiden johtopäätökset eivät välttämättä täsmää. Tämä tarkoittaa, että sinulla voi olla esimerkiksi RPC, joka onnistuu palvelinpuolella, mutta epäonnistuu asiakaspuolella. Palvelin voi myös päättää lopettaa ennen kuin asiakas on lähettänyt kaikki pyyntönsä.
Asiakas tai palvelin voi peruuttaa RPC:n milloin tahansa. Peruutus lopettaa RPC:n välittömästi, joten muita töitä ei tehdä.
Metadata on tietoa tietystä RPC-kutsusta (kuten todennustiedot) avainarvoparien luettelon muodossa, jossa avaimet ovat merkkijonoja ja arvot ovat yleensä merkkijonoja, mutta ne voivat olla binääritietoja. Metadata on läpinäkymätön gRPC:lle itselleen - sen avulla asiakas voi toimittaa palvelimelle kutsuun liittyviä tietoja ja päinvastoin.
Metatietojen käyttöoikeus vaihtelee kielen mukaan.
gRPC-kanava tarjoaa yhteyden gRPC-palvelimeen määritetyssä isännässä ja portissa. Käytetään luotaessa asiakaskantaa. Asiakkaat voivat määrittää kanavaargumentteja muuttaakseen gRPC:n oletuskäyttäytymistä, kuten ottaa viestien pakkaamisen käyttöön tai poistaa sen käytöstä.
Se, miten gRPC päättää sulkea kanavan, riippuu kielestä. Jotkin kielet mahdollistavat myös kanavan tilan kyselyn.
Useat eri organisaatiot ovat ottaneet käyttöön gRPC:n, kuten Square , Netflix , IBM , CoreOS , Docker , CockroachDB , Cisco , Juniper Networks , [1] Spotify , [2] ja Dropbox . [3]
Avoimen lähdekoodin projekti u-bmc käyttää gRPC:tä IPMI :n sijaan . Dropbox ilmoitti 8. tammikuuta 2019, että Courierin seuraava versio, heidän SOA-arkkitehtuurin ytimessä oleva RPC-kehys, siirretään gRPC:hen ensisijaisesti siksi, että se sopii hyvin yhteen heidän olemassa olevien mukautettujen RPC-kehysten kanssa.