Mikä on gRPC? Protokollapuskurit, suoratoisto ja arkkitehtuuri selitetty

gRPC on tehokas kehys etämenettelypuheluiden kanssa työskentelyyn. RPC: n avulla voit kirjoittaa koodin ikään kuin se suoritettaisiin paikallisella tietokoneella, vaikka se voidaan suorittaa toisella tietokoneella.

Viime päivinä olen sukeltanut syvälle gRPC: hen. Aion jakaa joitain suuria löytöjäni tässä artikkelissa.

Huomaa, että keskityn enemmän käsitteisiin kuin toteutuksen yksityiskohtiin. Opit itse gRPC: n ydinarkkitehtuurin. Opit myös:

  • Miksi kehittäjät käyttävät gRPC: tä niin laajalti?
  • Kuinka se toimii niin hyvin
  • Ja miten kaikki toimii konepellin alla.

Palataan vähän takaisin

Ennen kuin voimme kiirehtiä gRPC, meidän pitäisi katsoa, mitä etäproseduurikutsujen ovat.

RPC on asiakas-palvelin-viestinnän muoto, joka käyttää toimintokutsua tavallisen HTTP-puhelun sijaan.

Se käyttää IDL: ää (Interface Definition Language) käyttömuodon muodossa kutsuttavista toiminnoista ja tietotyypistä.

Jos et ole vielä ymmärtänyt sitä, gRPC: n RPC tarkoittaa etäkäytön kutsua. Ja kyllä, gRPC toistaa tämän asiakaspalvelimen viestinnän arkkitehtonisen tyylin toimintokutsujen kautta.

Joten gRPC ei ole teknisesti uusi käsite. Pikemminkin se otettiin käyttöön tästä vanhasta tekniikasta ja sitä parannettiin, joten se oli erittäin suosittu vain viiden vuoden aikana.

Yleiskatsaus gRPC: hen

Vuonna 2015 Google avasi hankkeensa, joka lopulta olisi nimeltään gRPC. Mutta mitä gRPC: n "g" tarkoittaa?

Monet ihmiset saattavat olettaa sen Googlelle, koska Google teki sen, mutta ei.

Google muuttaa jokaisen version "g": n merkityksen siihen pisteeseen, jossa he jopa tekivät README-luettelon kaikkien merkitysten luettelosta.

GRPC: n käyttöönoton jälkeen se on saavuttanut melkoisen suosion ja monet yritykset käyttävät sitä.

Mikä tekee gRPC: stä niin suositun?

On monia syitä, miksi gRPC on niin suosittu:

  • Abstraktio on helppoa (se on toimintokutsu)
  • Sitä tuetaan monilla kielillä
  • Se on erittäin suorituskykyinen
  • HTTP-puhelut ovat usein hämmentäviä, joten tämä tekee siitä helpompaa

Ja lukuun ottamatta kaikkia edellä mainittuja syitä, gRPC on suosittu, koska mikropalvelut ovat erittäin suosittuja.

Mikropalvelut käyttävät usein useita palveluja eri ohjelmointikielillä. Heillä on myös paljon palvelua palvelujen vuorovaikutuksessa.

Täällä gRPC auttaa eniten tarjoamalla tukea ja kykyä ratkaista tyypilliset ongelmat, jotka syntyvät näistä tilanteista.

gRPC on erittäin suosittu palvelupuheluiden palvelussa, koska usein HTTP-puheluita on vaikeampi ymmärtää ensi silmäyksellä.

gRPC-toimintoja on paljon helpompi perustella, joten kehittäjien ei tarvitse huolehtia paljon asiakirjojen kirjoittamisesta, koska koodin itsensä pitäisi selittää kaikki.

Osa palveluista voidaan myös kirjoittaa eri kielillä, ja gRPC: ssä on useita kirjastoja sen tukemiseksi.

Suorituskyky on kirsikka päällä - ja se on iso kirsikka.

gRPC-arkkitehtuuri

Olen maininnut useita kertoja, että gRPC: n suorituskyky on erittäin hyvä, mutta saatat miettiä, mikä tekee siitä niin hyvän? Mikä tekee gRPC: stä niin paljon paremman kuin RPC, kun niiden mallit ovat melko samanlaisia?

Tässä on muutamia keskeisiä eroja, jotka tekevät gRPC: stä niin suorituskykyisen.

HTTP / 2

HTTP on ollut kanssamme pitkään. Nyt lähes kaikki taustapalvelut käyttävät tätä protokollaa.

Kuten yllä olevasta kuvasta näkyy, HTTP / 1.1 pysyi merkityksellisenä pitkään.

Sitten vuonna 2015 HTTP / 2 tuli ulos ja korvasi olennaisesti HTTP / 1.1: n Internetin suosituimpana kuljetusprotokollana.

Jos muistat, että vuosi 2015 oli myös vuosi, jolloin gRPC ilmestyi, se ei ollut lainkaan sattumaa. Google loi myös HTTP / 2: n, jota gRPC käyttää arkkitehtuurissaan.

HTTP / 2 on yksi suurimmista syistä, miksi gRPC voi toimia niin hyvin. Ja tässä seuraavassa osassa näet miksi.

Pyynnön / vastauksen multipleksointi

Perinteisessä HTTP-protokollassa ei ole mahdollista lähettää useita pyyntöjä tai saada useita vastauksia yhteen yhteyteen. Jokaiselle heille on luotava uusi yhteys.

Tällainen pyyntö / vastaus multipleksointi on mahdollista HTTP / 2: ssa ottamalla käyttöön uusi HTTP / 2-kerros, jota kutsutaan binaarikehykseksi.

Tämä binaarikerros kapseloi ja koodaa tiedot. Tässä kerroksessa HTTP-pyyntö / vastaus jaetaan kehyksiin.

Otsikkokehys sisältää tyypillisiä HTTP-otsikkotietoja ja datakehys sisältää hyötykuorman. Tämän mekanismin avulla on mahdollista saada tietoja useista pyynnöistä yhdessä yhteydessä.

Tämä sallii useiden pyyntöjen hyötykuormat samalla otsakkeella, mikä identifioi sen yhtenä pyynnönä.

Otsikkopakkaus

Olet saattanut kohdata monia tapauksia, joissa HTTP-otsikot ovat jopa hyötykuormaa suuremmat. Ja HTTP / 2: lla on erittäin mielenkiintoinen strategia nimeltä HPack sen käsittelemiseksi.

Ensinnäkin kaikki HTTP / 2-tiedostot koodataan ennen lähettämistä, mukaan lukien otsikot. Tämä auttaa suorituskykyä, mutta se ei ole tärkeintä otsikkojen pakkauksessa.

HTTP / 2 kartoittaa otsikon sekä asiakas- että palvelinpuolelta. Siitä lähtien HTTP / 2 voi tietää, onko otsikossa sama arvo, ja lähettää otsikon arvon vain, jos se eroaa edellisestä otsikosta.

Kuten yllä olevasta kuvasta näkyy, pyyntö # 2 lähettää polun vain, koska muut arvot ovat täsmälleen samat. Ja kyllä, tämä vähentää paljon hyötykuorman kokoa ja puolestaan ​​parantaa HTTP / 2: n suorituskykyä entisestään.

Protokollapuskuri, alias Protobuf

Protobuf on yleisimmin käytetty IDL (Interface Definition Language) gRPC: lle. Siellä tallennat periaatteessa tiedot ja toimintosopimukset prototiedoston muodossa.

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

Koska tämä on sopimuksen muodossa, sekä asiakkaalla että palvelimella on oltava sama prototiedosto. Prototiedosto toimii välittäjäsopimuksena asiakkaalle kaikkien palvelimelta saatavien toimintojen kutsumiseksi.

Protobufilla on myös omistavat mekanismit, toisin kuin tavallinen REST-sovellusliittymä, joka vain lähettää tavuina JSON-merkkijonoja. Näiden mekanismien avulla hyötykuorma on paljon pienempi ja nopeampi.

Protobufin käyttämä koodausmenetelmä on melko monimutkainen. Jos haluat sukeltaa syvälle sen toimintaan, tutustu tähän kattavaan dokumentaatioon.

Mitä muuta gRPC tarjoaa?

tähtiä taivaalla

Nyt sinulla pitäisi olla perustiedot gRPC: n arkkitehtuurista, miten se toimii ja mihin se kykenee.

Mutta tässä on muutamia muita mielenkiintoisia asioita, joita gRPC tarjoaa meille.

Metatiedot

Tavallisen HTTP-pyynnön otsikon käyttämisen sijaan gRPC: llä on metadata. Metadata on avainarvotyyppi, joka voidaan asettaa joko asiakas- tai palvelinpuolelta.

Headervoidaan määrittää asiakkaan puolelta, kun taas palvelimet voivat määrittää Headerja Trailersniin kauan kuin molemmat ovat metatietojen muodossa.

suoratoisto

Suoratoisto on yksi gRPC: n peruskäsitteistä, jossa useita asioita voi tapahtua yhdessä pyynnössä. Tämän mahdollistaa aiemmin mainittu HTTP / 2: n multipleksointikyky.

Suoratoistoa on useita:

  • Server Streaming RPC: Jos asiakas lähettää yhden pyynnön ja palvelin voi lähettää useita vastauksia. Esimerkiksi, kun asiakas lähettää pyynnön kotisivulle, jossa on luettelo useista kohteista, palvelin voi lähettää vastaukset erikseen, jolloin asiakas voi käyttää laiskaa latausta.
  • Client Streaming RPC: Jos asiakas lähettää useita pyyntöjä ja palvelin lähettää vain yhden vastauksen. Esimerkiksi asiakkaan lataama zip / chunk.
  • Kaksisuuntainen suoratoisto RPC: jossa sekä asiakas että palvelin lähettävät viestejä toisilleen samanaikaisesti odottamatta vastausta.

Interceptorit

gRPC tukee keskeyttäjien käyttöä pyyntöönsä / vastauksessaan. Kuuntelijat, sieppaavat viestit ja antavat sinun muokata niitä.

Kuulostaako tämä tutulta? Jos olet pelannut HTTP-prosesseja REST-sovellusliittymässä, sieppaimet ovat hyvin samanlaisia ​​kuin väliohjelmat.

gRPC-kirjastot tukevat yleensä sieppaimia ja mahdollistavat helpon toteutuksen. Interceptoreita käytetään yleensä:

  • Muokkaa pyyntöä / vastausta ennen sen välittämistä. Sitä voidaan käyttää pakollisten tietojen toimittamiseen ennen lähettämistä asiakkaalle / palvelimelle.
  • Voit manipuloida kutakin toimintokutsua, kuten lisätä ylimääräistä kirjaamista vasteajan seuraamiseksi.

Kuormituksen tasapainoittaminen

Jos et ole vielä perehtynyt kuormituksen tasapainottamiseen, se on mekanismi, jonka avulla asiakaspyynnöt voidaan jakaa useille palvelimille.

Kuormituksen tasapainottaminen tapahtuu kuitenkin yleensä välityspalvelimen tasolla (esimerkiksi NGINX). Joten miksi puhun siitä täällä?

Osoittautuu, että gRPC tukee asiakkaan kuormituksen tasapainotustapaa. Se on jo toteutettu Golang-kirjastossa, ja sitä voidaan käyttää helposti.

Vaikka se saattaa tuntua jonkinlaiselta hullulta taikuudelta, se ei ole. IP-luettelon saamiseksi on jonkinlainen DNS-ratkaisu ja kuoren alla oleva kuorman tasapainotusalgoritmi.

Soita peruutus

gRPC-asiakkaat voivat peruuttaa gRPC-puhelun, kun se ei enää tarvitse vastausta. Palautus palvelinpuolella ei kuitenkaan ole mahdollista.

Tämä ominaisuus on erityisen hyödyllinen palvelinpuolen suoratoistossa, kun useita palvelinpyyntöjä saattaa olla tulossa. GRPC-kirjastossa on tarkkailumenetelmäkuvio, joka tietää, onko pyyntö peruttu, ja antaa sen perua useita vastaavia pyyntöjä kerralla.

Käärimistä

Kadonnut avaruudessa ja ajassa

Kaikki, mitä jaoin tänään, vain naarmuttaa pinnan siitä, mikä gRPC on, mihin se kykenee ja karkeasti miten se toimii.

Toivon todella, että tämä artikkeli auttoi sinua ymmärtämään enemmän gRPC: stä. Mutta oppimista on vielä paljon enemmän, joten älä pysähdy tähän! Jatka kaivamista.

Kiitos lukemisesta!