Шта је гРПЦ? Објашњени међуспремници протока, стриминг и архитектура

гРПЦ је моћан оквир за рад са позивима на даљинске процедуре. РПЦ вам омогућавају да напишете код као да ће се покретати на локалном рачунару, иако се може извршити на другом рачунару.

Ових неколико дана дубоко сам заронио у гРПЦ. У овом чланку ћу поделити нека од својих великих открића.

Имајте на уму да ћу се више фокусирати на концепте него на детаље имплементације. Научићете основну архитектуру самог гРПЦ-а. Такође ћете научити:

  • Зашто програмери тако широко користе гРПЦ
  • Како се добро изводи
  • И како то све функционише испод хаубе.

Вратимо се мало уназад

Пре него што хитнемо у гРПЦ, требало би да погледамо шта су позиви даљинским поступцима .

РПЦ је облик комуникације клијент-сервер који користи функцијски позив, а не уобичајени ХТТП позив.

Користи ИДЛ (Интерфаце Дефинитион Лангуаге) као облик уговора о функцијама које се позивају и типу података.

Ако то још нисте сви схватили, РПЦ у гРПЦ означава Позив даљинске процедуре. И да, гРПЦ репродукује овај архитектонски стил комуникације клијентског сервера путем позива функције.

Дакле, гРПЦ технички није нови концепт. Уместо тога, усвојен је из ове старе технике и унапређен, што га је учинило веома популарним у само пет година.

Преглед гРПЦ

2015. године Гоогле је отворио њихов пројекат који ће на крају бити пројекат назван гРПЦ. Али шта заправо значи „г“ у гРПЦ?

Многи људи могу то претпоставити Гоогле-у јер га је Гоогле створио, али није.

Гоогле мења значење „г“ за сваку верзију до те мере да је чак направио РЕАДМЕ да би набројао сва значења.

Откако је гРПЦ представљен, стекао је прилично популарност и многе компаније га користе.

Шта чини гРПЦ тако популарним?

Постоји пуно разлога зашто је гРПЦ толико популаран:

  • Апстракција је једноставна (то је позив функције)
  • Подржава се на многим језицима
  • Веома је изведен
  • ХТТП позиви су често збуњујући, па ово олакшава

И поред свих горе наведених разлога, гРПЦ је популаран јер су микросервиси веома популарни.

Микросервиси ће често покретати неколико услуга на различитим програмским језицима. Такође ће често имати пуно услуга за услугу интеракција.

Ту гРПЦ највише помаже пружајући подршку и способност решавања типичних проблема који произилазе из тих ситуација.

гРПЦ је веома популаран у услузи сервисирања позива, јер је често ХТТП позиве теже разумети на први поглед.

Много је лакше размишљати о гРПЦ функцијама, тако да програмери не морају да брину о писању пуно документације, јер би сам код требао све објаснити.

Неке услуге би такође могле бити написане на различитим језицима, а гРПЦ долази са више библиотека које то подржавају.

Перформансе су трешња на врху - и то је велика трешња.

гРПЦ Архитектура

Неколико пута сам споменуо да су перформансе гРПЦ-а врло добре, али можда се питате зашто је то тако добро? Шта чини гРПЦ толико бољим од РПЦ-а када су њихови дизајни прилично слични?

Ево неколико кључних разлика због којих је гРПЦ тако ефикасан.

ХТТП / 2

ХТТП је са нама већ дуже време. Сада готово све позадинске услуге користе овај протокол.

Као што приказује горња слика, ХТТП / 1.1 је остао релевантан дуго времена.

Затим је 2015. изашао ХТТП / 2 који је у основи заменио ХТТП / 1.1 као најпопуларнији транспортни протокол на Интернету.

Ако се сећате да је 2015. била и година када је изашао гРПЦ, то уопште није била случајност. ХТТП / 2 је такође створио Гоогле да би га гРПЦ користио у својој архитектури.

ХТТП / 2 је један од главних разлога зашто гРПЦ може да ради тако добро. И у овом следећем одељку видећете зашто.

Мултиплексирање захтева / одговора

У традиционалном ХТТП протоколу није могуће послати више захтева или добити више одговора заједно у једној вези. За сваког од њих ће бити потребно створити нову везу.

Оваква врста мултиплексирања захтева / одговора омогућена је у ХТТП / 2 увођењем новог ХТТП / 2 слоја који се назива бинарно кадрирање.

Овај бинарни слој инкапсулира и кодира податке. У овом слоју, ХТТП захтев / одговор се рашчлањује на оквире.

Оквир заглавља садржи типичне информације о ХТТП заглављима, а оквир података садржи корисни терет. Коришћењем овог механизма могуће је имати податке из више захтева у једној вези.

Ово омогућава корисно оптерећење из више захтева са истим заглављем, идентификујући га на тај начин као један захтев.

Компресија заглавља

Можда сте се сусрели са многим случајевима када су ХТТП заглавља чак и већа од корисног терета. А ХТТП / 2 има врло занимљиву стратегију названу ХПацк да то реши.

Као прво, све у ХТТП / 2 је кодирано пре слања, укључујући заглавља. Ово помаже у перформансама, али то није најважније код компресије заглавља.

ХТТП / 2 мапира заглавље и на клијентској и на серверској страни. Отуда ХТТП / 2 може да зна да ли заглавље садржи исту вредност и шаље заглавље само ако се разликује од претходног заглавља.

Као што се види на горњој слици, захтев бр. 2 послаће само путању јер су остале вредности потпуно исте. И да, ово заиста смањује величину корисног терета, а заузврат још више побољшава перформансе ХТТП / 2.

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

Протобуф је најчешће коришћени ИДЛ (Интерфаце Дефинитион Лангуаге) за гРПЦ. Ту у основи складиштите податке и уговоре о функцијама у облику прото датотеке.

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

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

Протобуф такође поседује механизме, за разлику од уобичајеног РЕСТ АПИ-ја који само шаље низове ЈСОН-а као бајтове. Ови механизми омогућавају да носивост буде много мања и омогућавају брже перформансе.

Метод кодирања који Протобуф користи је прилично сложен. Ако желите дубоко заронити у то како то функционише, погледајте ову свеобухватну документацију.

Шта још нуди гРПЦ?

звезде на небу

Сада бисте требали да имате основно разумевање архитектуре гРПЦ-а, како то функционише и за шта је способно.

Али ево још неколико занимљивих ствари које нам нуди гРПЦ.

Метаподаци

Уместо да користи уобичајено заглавље ХТТП захтева, гРПЦ има нешто што се зове метаподаци. Метаподаци су врста података кључ / вредност који се могу подесити са стране клијента или сервера.

Headerможе се доделити са стране клијента, док сервери могу доделити Headerи Trailersсве док су оба у облику метаподатака.

Стреаминг

Стриминг је један од основних концепата гРПЦ-а где се неколико ствари може догодити у једном захтеву. То је омогућено већ поменутом способношћу мултиплексирања ХТТП / 2.

Постоји неколико врста стримовања:

  • РПЦ протока сервера: Тамо где клијент шаље један захтев, а сервер може да пошаље више одговора. На пример, када клијент пошаље захтев за почетну страницу која има листу више ставки, сервер може одвојено послати одговоре, омогућавајући клијенту да користи лење учитавање.
  • РПЦ клијентског струјања: Тамо где клијент шаље више захтева, а сервер враћа само један одговор. На пример, зип / комад који је отпремио клијент.
  • РПК двосмерног струјања: где и клијент и сервер истовремено шаљу поруке једни другима, не чекајући одговор.

Пресретачи

гРПЦ подржава употребу пресретача за свој захтев / одговор. Пресретачи, па, пресрећу поруке и омогућавају вам да их модификујете.

Да ли вам ово звучи познато? Ако сте се поиграли са ХТТП процесима на РЕСТ АПИ-ју, пресретачи су врло слични међупрограму.

гРПЦ библиотеке обично подржавају пресретаче и омогућавају лаку имплементацију. Пресретачи се обично користе за:

  • Измените захтев / одговор пре него што га проследите даље. Може се користити за пружање обавезних информација пре слања клијенту / серверу.
  • Омогућавају вам да манипулишете сваким позивом функције, као што је додавање додатног евидентирања за праћење времена одзива.

Балансирање оптерећења

Ако већ нисте упознати са уравнотежењем оптерећења, то је механизам који омогућава распоређивање захтева клијента на више сервера.

Али балансирање оптерећења се обично врши на нивоу проки сервера (на пример, НГИНКС). Па зашто овде причам о томе?

Испоставило се да гРПЦ подржава метод балансирања оптерећења од стране клијента. Већ је имплементиран у библиотеци Голанг и може се лако користити.

Иако то може изгледати као нека луда магија, није. Постоји нека врста ДНС резолуције за добијање ИП листе и алгоритам за уравнотежење оптерећења испод хаубе.

Отказивање позива

гРПЦ клијенти могу отказати гРПЦ позив када му више није потребан одговор. Враћање на страни сервера ипак није могуће.

Ова функција је посебно корисна за стреаминг на страни сервера где можда долази више захтева за сервером. Библиотека гРПЦ долази опремљена обрасцем методе посматрача да би знала да ли је захтев отказан и омогућила му да откаже више одговарајућих захтева одједном.

Окончање

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

Све што сам данас делио само огребе површину онога што је гРПЦ, за шта је способан и отприлике како то функционише.

Заиста се надам да вам је овај чланак помогао да разумете више о гРПЦ. Али још увек има много више учења, зато не заустављајте се овде! Наставите да копате.

Хвала за читање!