Какво е gRPC? Обяснени буфери на протоколи, стрийминг и архитектура

gRPC е мощна рамка за работа с разговори за отдалечени процедури. RPC ви позволяват да пишете код, сякаш той ще се изпълнява на локален компютър, въпреки че може да бъде изпълнен на друг компютър.

През последните няколко дни се гмурнах дълбоко в gRPC. Ще споделя някои от големите си открития тук в тази статия.

Имайте предвид, че ще се съсредоточа повече върху концепциите, отколкото върху подробностите за изпълнението. Ще научите основната архитектура на самия gRPC. Също така ще научите:

  • Защо gRPC е толкова широко използван от разработчиците
  • Как се представя толкова добре
  • И как всичко работи под предния капак.

Да се ​​върнем малко назад

Преди да се впуснем в gRPC, трябва да разгледаме какво представляват разговорите за отдалечени процедури .

RPC е форма на комуникация клиент-сървър, която използва функционално повикване, а не обичайно HTTP повикване.

Той използва IDL (Interface Definition Language) като форма на договор за извикваните функции и за типа данни.

Ако все още не сте го осъзнали, RPC в gRPC означава Remote Procedure Call. И да, gRPC репликира този архитектурен стил на комуникация между клиентски сървър, чрез извиквания на функции.

Така че gRPC технически не е нова концепция. По-скоро беше възприет от тази стара техника и усъвършенстван, което го направи много популярен само за период от 5 години.

Преглед на gRPC

През 2015 г. Google отвори своя проект, който в крайна сметка ще бъде този, наречен gRPC. Но какво всъщност означава „g“ в gRPC?

Много хора може да приемат това за Google, защото Google го е направил, но не го прави.

Google променя значението на "g" за всяка версия до точката, в която дори са направили README, за да изброят всички значения.

Откакто е въведен gRPC, той придоби доста голяма популярност и много компании го използват.

Какво прави gRPC толкова популярен?

Има много причини, поради които gRPC е толкова популярен:

  • Абстракцията е лесна (това е извикване на функция)
  • Поддържа се на много езици
  • Той е много ефективен
  • HTTP повикванията често са объркващи, така че това го улеснява

И освен всички горепосочени причини, gRPC е популярен, защото микроуслугите са много популярни.

Микроуслугите често изпълняват няколко услуги на различни езици за програмиране. Те също така често ще имат много услуги за обслужване на взаимодействия.

Това е мястото, където gRPC помага най-много, като предоставя подкрепа и способност за решаване на типичните проблеми, които възникват от тези ситуации.

gRPC е много популярен в услугата за обслужване на повиквания, тъй като често HTTP повикванията са по-трудни за разбиране на пръв поглед.

Функциите за gRPC са много по-лесни за разсъждение, така че разработчиците не трябва да се притесняват да напишат много документация, защото самият код трябва да обясни всичко.

Някои от услугите също могат да бъдат написани на различни езици и gRPC се предлага с множество библиотеки, които да поддържат това.

Ефективността е черешата отгоре - и това е голяма череша.

gRPC архитектура

Няколко пъти споменах, че производителността на gRPC е много добра, но може би се чудите какво я прави толкова добра? Какво прави gRPC толкова по-добър от RPC, когато техните дизайни са доста сходни?

Ето няколко ключови разлики, които правят gRPC толкова ефективна.

HTTP / 2

HTTP е с нас от дълго време. Сега почти всички бекенд услуги използват този протокол.

Както показва снимката по-горе, HTTP / 1.1 остава актуален дълго време.

След това през 2015 г. излезе HTTP / 2 и по същество замени HTTP / 1.1 като най-популярния транспортен протокол в интернет.

Ако си спомняте, че 2015 беше и годината, в която излезе gRPC, това съвсем не беше случайност. HTTP / 2 също е създаден от Google, за да бъде използван от gRPC в своята архитектура.

HTTP / 2 е една от големите причини, поради които gRPC може да се представя толкова добре. И в този следващ раздел ще видите защо.

Заявка / отговор Мултиплексиране

В традиционния HTTP протокол не е възможно да се изпращат множество заявки или да се получават множество отговори заедно в една връзка. За всеки от тях ще трябва да се създаде нова връзка.

Този вид мултиплексиране на заявки / отговори е възможен в HTTP / 2 с въвеждането на нов HTTP / 2 слой, наречен двоично кадриране.

Този двоичен слой капсулира и кодира данните. В този слой HTTP заявката / отговорът се разбива на рамки.

Рамката на заглавките съдържа типична информация за HTTP заглавки, а рамката с данни съдържа полезния товар. Използвайки този механизъм, е възможно да имате данни от множество заявки в една връзка.

Това позволява полезни натоварвания от множество заявки с един и същ хедър, като по този начин го идентифицира като една заявка.

Компресия на заглавката

Може да сте срещали много случаи, когато HTTP заглавията са дори по-големи от полезния товар. И HTTP / 2 има много интересна стратегия, наречена HPack, за да се справи с това.

Първо, всичко в HTTP / 2 е кодирано преди да бъде изпратено, включително заглавията. Това наистина помага за производителността, но това не е най-важното за компресирането на хедъра.

HTTP / 2 картографира заглавката както от страна на клиента, така и от страна на сървъра. От това HTTP / 2 може да знае дали заглавката съдържа същата стойност и изпраща стойността на заглавката само ако е различна от предишната заглавка.

Както се вижда на снимката по-горе, Заявка №2 ще изпрати само пътя, тъй като останалите стойности са абсолютно същите. И да, това намалява значително размера на полезния товар и от своя страна подобрява още повече производителността на HTTP / 2.

Протоколен буфер, известен още като Protobuf

Protobuf е най-често използваният IDL (Interface Definition Language) за gRPC. Това е мястото, където основно съхранявате вашите данни и договори за функции под формата на прото файл.

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

Тъй като това е под формата на договор, и клиентът, и сървърът трябва да имат един и същ прото файл. Протоколът действа като посреднически договор за клиент за извикване на всички налични функции от сървъра.

Protobuf също притежава механизми, за разлика от обичайния REST API, който просто изпраща низове от JSON като байтове. Тези механизми позволяват полезният товар да бъде много по-малък и позволяват по-бърза работа.

Методът на кодиране, който Protobuf използва е доста сложен. Ако искате да се впуснете задълбочено в това как работи, разгледайте тази изчерпателна документация.

Какво друго предлага gRPC?

звезди в небето

Сега трябва да имате основно разбиране за архитектурата на gRPC, как работи и на какво е способен.

Но ето още няколко интересни неща, които ни предлага gRPC.

Метаданни

Вместо да използва обичайна заглавка на HTTP заявка, gRPC има нещо, наречено метаданни. Метаданните са тип данни ключ-стойност, които могат да бъдат зададени от страна на клиента или сървъра.

Headerмогат да бъдат присвоени от страна на клиента, докато сървърите могат да присвояват Headerи Trailersстига и двете да са под формата на метаданни.

Стрийминг

Поточното предаване е една от основните концепции на gRPC, при която няколко неща могат да се случат с една заявка. Това е възможно благодарение на способността за мултиплексиране на HTTP / 2, спомената по-рано.

Има няколко вида стрийминг:

  • RPC за поточно предаване на сървъри: Когато клиентът изпраща една заявка и сървърът може да изпрати обратно множество отговори. Например, когато клиент изпраща заявка за начална страница, която има списък от множество елементи, сървърът може да изпраща обратно отговори поотделно, позволявайки на клиента да използва лениво зареждане.
  • Клиентско поточно RPC: Когато клиентът изпраща множество заявки, а сървърът изпраща обратно само един отговор. Например zip / chunk, качени от клиента.
  • Двупосочно поточно RPC: Когато клиентът и сървърът изпращат съобщения един към друг едновременно, без да чакат отговор.

Прехващачи

gRPC поддържа използването на прехващачи за неговото искане / отговор. Прехващачи, добре, прихващайте съобщения и ви позволяват да ги модифицирате.

Звучи ли ви познато? Ако сте играли с HTTP процеси на REST API, прехващачите са много подобни на мидълуер.

gRPC библиотеките обикновено поддържат прехващачи и позволяват лесно изпълнение. Прихващачите обикновено се използват за:

  • Променете заявката / отговора, преди да бъдете предадени. Може да се използва за предоставяне на задължителна информация, преди да бъде изпратена до клиента / сървъра.
  • Позволяват ви да манипулирате всяко извикване на функция, като например добавяне на допълнително регистриране за проследяване на времето за реакция.

Балансиране на натоварването

Ако все още не сте запознати с балансирането на натоварването, това е механизъм, който позволява клиентските заявки да бъдат разпределени на множество сървъри.

Но балансирането на натоварването обикновено се извършва на ниво прокси (например NGINX). И така, защо говоря за това тук?

Оказва се, че gRPC поддържа метод за балансиране на натоварването от клиента. Той вече е реализиран в библиотеката на Golang и може да се използва с лекота.

Макар да изглежда като някаква луда магия, не е така. Има някакъв DNS преобразувател, за да получите IP списък, и алгоритъм за балансиране на натоварването под капака.

Анулиране на обаждане

Клиентите на gRPC могат да анулират повикване на gRPC, когато вече не се нуждае от отговор. Връщането от страна на сървъра обаче не е възможно.

Тази функция е особено полезна за стрийминг от страна на сървъра, където може да идват множество сървърни заявки. Библиотеката gRPC е снабдена с модел на метод на наблюдател, за да знае дали дадена заявка е отменена и да й позволи да анулира множество съответни заявки наведнъж.

Обобщавайки

Изгубени в пространството и времето

Всичко, което споделих днес, просто надрасква повърхността на това какво е gRPC, на какво е способен и приблизително как работи.

Наистина се надявам тази статия да ви е помогнала да разберете повече за gRPC. Но има още много неща за учене, така че не спирайте до тук! Продължавайте да копаете.

Благодаря за четенето!