GRPC

gRPC
Tyyppi etämenettelyn kutsukehys
Kehittäjä Google
Sisään kirjoitettu Android Java, C#, C++, Dart, Go, Java, Kotlin/JVM, Node.js, Objective-C, PHP, Python, Ruby
Ensimmäinen painos elokuu 2016  ( 2016-08 )
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.

Todennus

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.

Tietojen koodausmenetelmä

gRPC käyttää protokollapuskureita tietojen koodaamiseen. Toisin kuin JSON:n sisältävällä HTTP API :lla, niillä on tiukemmat vaatimukset.

Yleiskatsaus

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ä.

Ydinkäsitteet, arkkitehtuuri ja elinkaari

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ää:

API:n käyttäminen

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.

Synkronisuus ja asynkronisuus

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.

RPC-elinkaari

Unary RPC

Asiakas lähettää yhden pyynnön ja palauttaa yhden vastauksen.

  1. Kun asiakas kutsuu stub-menetelmää, palvelimelle ilmoitetaan, että RPC on kutsuttu, ja siinä on asiakkaan metatiedot kyseiselle kutsulle, menetelmän nimi ja tarvittaessa määritetty määräaika.
  2. Palvelin voi sitten joko lähettää välittömästi takaisin omat alkuperäiset metatietonsa (jotka on lähetettävä ennen vastausta) tai odottaa pyyntöviestiä asiakkaalta. Se, mitä tapahtuu ensin, riippuu tietystä sovelluksesta.
  3. Kun palvelin vastaanottaa asiakaspyyntösanoman, se tekee kaiken tarvittavan työn vastauksen luomiseksi ja täyttämiseksi. Vastaus palautetaan sitten (jos onnistuu) asiakkaalle tilatietojen (tilakoodin ja valinnaisen tilaviestin) ja valinnaisten lopullisten metatietojen kanssa.
  4. Jos vastauksen tila on "OK", asiakas saa vastauksen, joka lopettaa puhelun asiakkaan puolella.

Palvelinpuolen suoratoiston RPC

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.

RPC-suoratoistoasiakas

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.

Kaksisuuntainen suoratoisto RPC

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.

Määräajat / aikakatkaisut

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. .

RPC:n lopettaminen

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ä.

Peruuta RPC

Asiakas tai palvelin voi peruuttaa RPC:n milloin tahansa. Peruutus lopettaa RPC:n välittömästi, joten muita töitä ei tehdä.

Metatiedot

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.

Kanavat

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.

Hyväksyminen

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.

Katso myös

Muistiinpanot

  1. grRPC . grpc.io. _ Haettu 24. helmikuuta 2020. Arkistoitu alkuperäisestä 24. marraskuuta 2020.
  2. gRPC Spotifyssa . jfokus.se _ Haettu 12. toukokuuta 2020. Arkistoitu alkuperäisestä 27. lokakuuta 2021.
  3. Kuinka siirsimme Dropboxin Nginxistä Envoyyn . Dropbox.Tech . Haettu 30. lokakuuta 2020. Arkistoitu alkuperäisestä 4. tammikuuta 2022.

Linkit