gRPC je moćan okvir za rad s pozivima na daljinski postupak. RPC vam omogućuju pisanje koda kao da će se izvoditi na lokalnom računalu, iako se može izvršiti na drugom računalu.
Posljednjih nekoliko dana duboko sam zaronio u gRPC. Podijelit ću neka od svojih velikih otkrića ovdje u ovom članku.
Imajte na umu da ću se više usredotočiti na koncepte nego na detalje implementacije. Naučit ćete temeljnu arhitekturu samog gRPC-a. Također ćete naučiti:
- Zašto programeri tako široko koriste gRPC
- Kako se dobro izvodi
- I kako to sve funkcionira ispod haube.
Vratimo se malo unatrag
Prije nego što požurimo s gRPC-om, trebali bismo pogledati što su daljinski pozivi .
RPC je oblik komunikacije klijent-poslužitelj koji koristi funkcijski poziv, a ne uobičajeni HTTP poziv.
Koristi IDL (jezik definicije sučelja) kao oblik ugovora o funkcijama koje se pozivaju i tipu podataka.
Ako to još niste svi shvatili, RPC u gRPC-u znači Poziv za daljinski postupak. I da, gRPC preslikava ovaj arhitektonski stil komunikacije klijentskog poslužitelja putem poziva funkcije.
Dakle, gRPC tehnički nije novi koncept. Umjesto da je prihvaćen iz ove stare tehnike i unaprijeđen, što ga je učinilo vrlo popularnim u samo pet godina.
Pregled gRPC-a
2015. godine Google je otvorio njihov projekt koji će na kraju biti onaj nazvan gRPC. Ali što zapravo znači "g" u gRPC-u?
Mnogi ljudi mogu to pretpostaviti Googleu jer ga je Google stvorio, ali nije.
Google mijenja značenje "g" za svaku verziju do te mjere da je čak napravio README kako bi nabrojio sva značenja.
Otkad je predstavljen gRPC, stekao je popriličnu popularnost i mnoge ga tvrtke koriste.
Što čini gRPC tako popularnim?
Puno je razloga zašto je gRPC toliko popularan:
- Apstrakcija je jednostavna (to je poziv funkcije)
- Podržana je na puno jezika
- Vrlo je izveden
- HTTP pozivi često zbunjuju, pa to olakšava
I osim svih gore navedenih razloga, gRPC je popularan jer su mikroservisi vrlo popularni.
Mikroservisi će često pokretati nekoliko usluga na različitim programskim jezicima. Također će često imati puno usluga za uslugu interakcija.
Tu gRPC najviše pomaže pružajući podršku i sposobnost rješavanja tipičnih problema koji proizlaze iz tih situacija.
gRPC je vrlo popularan u usluzi servisiranja poziva, jer je često HTTP pozive teže razumjeti na prvi pogled.
Mnogo je lakše razmišljati o funkcijama gRPC-a, tako da se programeri ne moraju brinuti o pisanju puno dokumentacije, jer bi sam kôd trebao sve objasniti.
Neke usluge mogu biti napisane i na različitim jezicima, a gRPC dolazi s više knjižnica koje to podržavaju.
Performanse su trešnja na vrhu - i to je velika trešnja.
gRPC arhitektura
Nekoliko sam puta spomenuo da su performanse gRPC-a vrlo dobre, ali možda se pitate zašto je to tako dobro? Što čini gRPC toliko boljim od RPC-a kad su njihovi dizajni prilično slični?
Evo nekoliko ključnih razlika zbog kojih je gRPC tako učinkovit.
HTTP / 2
HTTP je s nama već duže vrijeme. Sada se gotovo sve pozadinske usluge koriste ovim protokolom.
Kao što prikazuje gornja slika, HTTP / 1.1 ostao je relevantan dugo vremena.
Tada je 2015. izašao HTTP / 2 koji je u osnovi zamijenio HTTP / 1.1 kao najpopularniji transportni protokol na Internetu.
Ako se sjećate da je 2015. bila i godina kada je izašao gRPC, to uopće nije bila slučajnost. HTTP / 2 je također stvorio Google da bi ga gRPC koristio u svojoj arhitekturi.
HTTP / 2 jedan je od glavnih razloga zašto gRPC može raditi tako dobro. I u ovom sljedećem odjeljku vidjet ćete zašto.
Multipleksiranje zahtjeva / odgovora
U tradicionalnom HTTP protokolu nije moguće poslati više zahtjeva ili dobiti više odgovora zajedno u jednoj vezi. Za svakog od njih trebat će se stvoriti nova veza.
Ovakva vrsta multipleksiranja zahtjeva / odgovora omogućena je u HTTP / 2 uvođenjem novog HTTP / 2 sloja koji se naziva binarno kadriranje.
Ovaj binarni sloj enkapsulira i kodira podatke. U ovom se sloju HTTP zahtjev / odgovor raščlanjuje na okvire.
Okvir zaglavlja sadrži tipične informacije o HTTP zaglavljima, a okvir podataka sadrži korisni teret. Korištenjem ovog mehanizma moguće je imati podatke iz više zahtjeva u jednoj vezi.
To omogućuje opterećenje iz više zahtjeva s istim zaglavljem, identificirajući ga na taj način kao jedan zahtjev.
Kompresija zaglavlja
Možda ste se susreli s mnogim slučajevima kada su HTTP zaglavlja čak i veća od korisnog tereta. A HTTP / 2 ima vrlo zanimljivu strategiju nazvanu HPack kako bi to riješio.
Kao prvo, sve u HTTP / 2 kodira se prije slanja, uključujući zaglavlja. To pomaže u izvedbi, ali to nije najvažnije kod kompresije zaglavlja.
HTTP / 2 preslikava zaglavlje i na klijentskoj i na poslužiteljskoj strani. Otuda HTTP / 2 može znati sadrži li zaglavlje istu vrijednost i šalje vrijednost zaglavlja samo ako se razlikuje od prethodnog zaglavlja.
Kao što se vidi na gornjoj slici, zahtjev br. 2 samo će poslati put jer su ostale vrijednosti potpuno iste. I da, ovo puno smanjuje veličinu korisnog tereta, a zauzvrat još više poboljšava performanse HTTP / 2.
Međuspremnik protokola, zvani Protobuf
Protobuf je najčešće korišten IDL (jezik definicije sučelja) za gRPC. Tu u osnovi pohranjujete svoje podatke i ugovore o funkcijama u obliku proto datoteke.
message Person { required string name = 1; required int32 id = 2; optional string email = 3; }Budući da je ovo u obliku ugovora, i klijent i poslužitelj moraju imati istu proto datoteku. Proto datoteka djeluje kao posrednički ugovor za klijenta da pozove bilo koje dostupne funkcije s poslužitelja.
Protobuf također posjeduje mehanizme, za razliku od uobičajenog REST API-ja koji samo šalje nizove JSON-a kao bajtove. Ovi mehanizmi omogućuju da nosivost bude puno manja i omogućuju brže performanse.
Način kodiranja koji Protobuf koristi prilično je složen. Ako želite duboko zaroniti u to kako to funkcionira, pogledajte ovu sveobuhvatnu dokumentaciju.
Što još nudi gRPC?
Sada biste trebali imati osnovno razumijevanje arhitekture gRPC-a, kako to funkcionira i za što je sposobno.
No, evo još nekoliko zanimljivih stvari koje nam nudi gRPC.
Metapodaci
Umjesto da koristi uobičajeno zaglavlje HTTP zahtjeva, gRPC ima nešto što se naziva metapodaci. Metapodaci su vrsta podataka ključ / vrijednost koji se mogu postaviti s klijentske ili poslužiteljske strane.
Headermože se dodijeliti s klijentske strane, dok poslužitelji mogu dodijeliti Headeri Trailersdok god su oba u obliku metapodataka.
Strujanje
Streaming je jedan od temeljnih koncepata gRPC-a gdje se nekoliko stvari može dogoditi u jednom zahtjevu. To je omogućeno već spomenutom sposobnošću multipleksiranja HTTP / 2.
Postoji nekoliko vrsta streaminga:
- RPC streaminga poslužitelja: tamo gdje klijent šalje jedan zahtjev, a poslužitelj može poslati natrag više odgovora. Na primjer, kada klijent pošalje zahtjev za početnu stranicu koja ima popis više stavki, poslužitelj može odgovoriti natrag odvojeno, omogućujući klijentu da koristi lijeno učitavanje.
- RPC klijentskog strujanja: tamo gdje klijent šalje više zahtjeva, a poslužitelj vraća samo jedan odgovor. Na primjer, zip / komad koji je prenio klijent.
- RPK dvosmjernog strujanja: gdje i klijent i poslužitelj istovremeno šalju poruke jedni drugima, ne čekajući odgovor.
Presretači
gRPC podržava upotrebu presretača za svoj zahtjev / odgovor. Presretači, presreću poruke i omogućuju vam da ih mijenjate.
Zvuči li ovo poznato? Ako ste se poigrali s HTTP procesima na REST API-ju, presretači su vrlo slični međuprogramu.
gRPC knjižnice obično podržavaju presretače i omogućuju jednostavnu implementaciju. Presretači se obično koriste za:
- Izmijenite zahtjev / odgovor prije prosljeđivanja. Može se koristiti za pružanje obveznih podataka prije slanja klijentu / poslužitelju.
- Omogućuju vam manipulaciju sa svakim pozivom funkcije, kao što je dodavanje dodatne evidencije za praćenje vremena odziva.
Uravnoteženje opterećenja
Ako već niste upoznati s uravnoteženjem opterećenja, to je mehanizam koji omogućuje raspolaganje zahtjevima klijenta na više poslužitelja.
Ali uravnoteženje opterećenja obično se vrši na razini proxyja (na primjer, NGINX). Pa zašto ovdje pričam o tome?
Ispostavilo se da gRPC podržava metodu uravnoteženja opterećenja od strane klijenta. Već je implementiran u knjižnici Golang i može se koristiti s lakoćom.
Iako se to može činiti kao neka luda magija, nije. Postoji neka vrsta DNS razrješivača za dobivanje IP popisa i algoritam za uravnoteženje opterećenja ispod haube.
Otkazivanje poziva
gRPC klijenti mogu otkazati gRPC poziv kada više ne treba odgovor. Vraćanje na strani poslužitelja ipak nije moguće.
Ova je značajka posebno korisna za streaming na strani poslužitelja gdje možda dolazi više zahtjeva za poslužiteljem. Biblioteka gRPC dolazi opremljena uzorkom metode promatrača kako bi znala je li zahtjev otkazan i omogućila mu otkazivanje više odgovarajućih zahtjeva odjednom.
Završavati
Sve što sam danas podijelio samo ogrebe površinu onoga što gRPC jest, za što je sposoban i otprilike kako to funkcionira.
Iskreno se nadam da vam je ovaj članak pomogao da razumijete više o gRPC-u. Ali još uvijek se može naučiti puno više, zato nemojte ovdje stati! Nastavite kopati.
Hvala na čitanju!