ћерион Ќетворкс

7 минут чтени€

gRPC Ч это мощна€ платформа дл€ работы с удаленными вызовами процедур (Remote Procedure Calls). RPC позвол€т писать код так, как будто он будет выполн€тьс€ на локальном компьютере, даже если он может выполн€тьс€ на другом компьютере.


„то такое RPC?

RPC Ч это форма взаимодействи€ клиент-сервер, в которой используетс€ вызов функции, а не обычный вызов HTTP. »де€ в том, что мы можем вызвать и выполнить функцию где-то на удаленной системе, как если бы это была локальна€ функци€.

ќн использует IDL (Interface Definition Language - €зык описани€ интерфейса) как форму контракта на вызываемые функции и тип данных.

RPC Ч это протокол "запрос-ответ", т.е. он следует модели "клиент-сервер":

RPC-архитектура

 лиент делает запрос на выполнение процедуры на удаленном сервере.  ак и при синхронном локальном вызове, клиент приостанавливаетс€ до тех пор, пока не будут возвращены результаты процедуры. ѕараметры процедуры передаютс€ по сети на сторону сервера. ѕроцедура выполн€етс€ на сервере и, наконец, результаты передаютс€ обратно клиенту.

gRPC воспроизводит этот архитектурный стиль взаимодействи€ клиент-сервер через вызовы функций.

“аким образом, gRPC технически не €вл€етс€ новой концепцией. —корее, он был заимствован из этой старой техники и улучшен, что сделало ее очень попул€рной.


„то такое gRPC?

¬ 2015 году Google открыл исходный код своего проекта, который в конечном итоге получил название gRPC.

Ќо что на самом деле означает буква Ђgї в gRPC? ћногие люди могут предположить, что это дл€ Google, потому что Google это сделал, но это не так. Google мен€ет значение Ђgї дл€ каждой версии до такой степени, что они даже сделали README, чтобы перечислить все значени€.

— момента по€влени€ gRPC он приобрел довольно большую попул€рность, и многие компании используют его.

≈сть много причин, по которым gRPC так попул€рен: проста€ абстракци€, он поддерживаетс€ во многих €зыках и он очень эффективный.

» помимо всех вышеперечисленных причин, gRPC попул€рен потому, что очень попул€рны микросервисы и имеетс€ большое количество взаимодействий между ними. »менно здесь gRPC помогает больше всего, предоставл€€ поддержку и возможности дл€ решени€ типичных проблем, возникающих в таких ситуаци€х.

ј поскольку разные сервисы могут быть написаны на разных €зыках, gRPC поставл€етс€ с несколькими библиотеками дл€ их поддержки.


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

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

ћы сказали что производительность gRPC очень высока, но что делает ее такой хорошей? „то делает gRPC намного лучше, чем RPC, если их дизайн очень похож? ¬от несколько ключевых отличий, которые делают gRPC столь эффективным.

HTTP/2

HTTP был с нами очень долго. —ейчас почти все серверные службы используют этот протокол.

HTTP

HTTP/1.1 долгое врем€ оставалс€ актуальным, затем в 2015 году, по€вилс€ HTTP/2, который фактически заменил HTTP/1.1 как самый попул€рный транспортный протокол в »нтернете.

≈сли вы помните, что 2015 год был также годом выхода gRPC, и это было вовсе не совпадение. HTTP/2 также был создан Google дл€ использовани€ gRPC в его архитектуре.

HTTP/2 Ч одна из важных причин, почему gRPC может работать так хорошо. » в следующем разделе вы поймете, почему.

ћультиплексирование запроса/ответа

¬ традиционном протоколе HTTP невозможно отправить несколько запросов или получить несколько ответов вместе в одном соединении. ƒл€ каждого из них необходимо создать новое соединение.

“акой вид мультиплексировани€ запроса/ответа стал возможен в HTTP/2 благодар€ введению нового уровн€ HTTP/2, называемого binary framing.

HTTP/2

Ётот двоичный уровень инкапсулирует и кодирует данные. Ќа этом уровне HTTP-запрос/ответ разбиваетс€ на кадры (они же фреймы).

‘рейм заголовков (HEADERS frame) содержит типичную информацию заголовков HTTP, а фрейм данных (DATA frame) содержит полезные данные. »спользу€ этот механизм, можно получить данные из нескольких запросов в одном соединении.

Ёто позвол€ет получать полезные данные из нескольких запросов с одним и тем же заголовком, тем самым идентифициру€ их как один запрос.

—жатие заголовка

¬ы могли столкнутьс€ со многими случа€ми, когда заголовки HTTP даже больше, чем полезна€ нагрузка. » HTTP/2 имеет очень интересную стратегию под названием HPack дл€ решени€ этой проблемы.

¬о-первых, все в HTTP/2 кодируетс€ перед отправкой, включа€ заголовки. Ёто помогает повысить производительность, но это не самое важное в сжатии заголовков.

HTTP/2 сопоставл€ет заголовок как на стороне клиента, так и на стороне сервера. »з этого HTTP/2 может узнать, содержит ли заголовок одно и то же значение, и отправл€ет значение заголовка только в том случае, если оно отличаетс€ от предыдущего заголовка.

«апросы

 ак видно на картинке выше, запрос є 2 отправит только новый путь, так как другие значени€ точно такие же как и были. » да, это значительно сокращает размер полезной нагрузки и, в свою очередь, еще больше повышает производительность HTTP/2.


„то такое Protocol Buffer (Protobuf)?

Protobuf Ч это наиболее часто используемый IDL дл€ gRPC. «десь вы храните свои данные и функциональные контракты в виде так называемого прото-файла. ѕо сути это протокол сериализации данных, такой как JSON или XML.

¬ыгл€дит это так:

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

“ак мы определили сообщение Person с пол€ми name, id и email

ѕоскольку это форма контракта то и клиент, и сервер должны иметь один и тот же прото-файл. ‘айл proto действует как промежуточный контракт дл€ клиента, чтобы вызвать любые доступные функции с сервера.

Protobuf также имеет собственные механизмы, в отличие от обычного REST API, который просто отправл€ет строки JSON в виде байтов. Ёти механизмы позвол€ют значительно уменьшить полезную нагрузку и повысить производительность.


„то еще может предложить gRPC?

ћетаданные

¬место обычного заголовка HTTP-запроса в gRPC есть то, что называетс€ метаданными (Metadata). ћетаданные Ч это тип данных Ђключ-значениеї, которые можно установить как на стороне клиента, так и на стороне сервера.

«аголовок может быть назначен со стороны клиента, в то врем€ как серверы могут назначать заголовок и трейлеры, если они оба представлены в виде метаданных.

ѕотокова€ передача

ѕотокова€ передача (Streaming) Ч это одна из основных концепций gRPC, когда в одном запросе может выполн€тьс€ несколько действий. Ёто стало возможным благодар€ упом€нутой ранее возможности мультиплексировани€ HTTP/2.

—уществует несколько видов потоковой передачи:

  • Server Streaming RPC: когда клиент отправл€ет один запрос, а сервер может отправить несколько ответов. Ќапример, когда клиент отправл€ет запрос на домашнюю страницу со списком из нескольких элементов, сервер может отправл€ть ответы по отдельности, позвол€€ клиенту использовать отложенную загрузку.
  • Client Streaming RPC: когда клиент отправл€ет несколько запросов, а сервер отправл€ет обратно только один ответ. Ќапример, zip/chunk, загруженный клиентом.
  • Bidirectional Streaming RPC: клиент и сервер одновременно отправл€ют сообщени€ друг другу, не дожида€сь ответа.

ѕерехватчики

gRPC поддерживает использование перехватчиков дл€ своего запроса/ответа. ќни перехватывают сообщени€ и позвол€ют вам измен€ть их.

Ёто звучит знакомо? ≈сли вы работали с HTTP-процессами в REST API, перехватчики очень похожи на middleware (оно же промежуточное ѕќ).

Ѕиблиотеки gRPC обычно поддерживают перехватчики и обеспечивают простую реализацию. ѕерехватчики обычно используютс€ дл€:

  • »зменени€ запроса/ответа перед передачей. Ёто можно использовать дл€ предоставлени€ об€зательной информации перед отправкой на клиент/сервер.
  • ѕозвол€ет вам манипулировать каждым вызовом функции, например, добавл€ть дополнительные логи дл€ отслеживани€ времени отклика.

Ѕалансировки нагрузки

≈сли вы еще не знакомы с балансировкой нагрузки, это механизм, который позвол€ет распредел€ть клиентские запросы по нескольким серверам.

Ќо балансировка нагрузки обычно делаетс€ на уровне прокси (например, nginx). “ак причем это здесь?

ƒело в том, что gRPC поддерживает метод балансировки нагрузки клиентом. ќн уже реализован в библиотеке Golang и может быть легко использован.

’от€ это может показатьс€ какой-то магией, это не так. “ам есть что-то типа преобразовател€ DNS дл€ получени€ списка IP-адресов и алгоритм балансировки нагрузки под капотом.

ќтмена вызова

 лиенты gRPC могут отменить вызов gRPC, когда им больше не нужен ответ. ќднако откат на стороне сервера невозможен.

Ёта функци€ особенно полезна дл€ потоковой передачи на стороне сервера, когда может поступать несколько запросов к серверу. Ѕиблиотека gRPC оснащена шаблоном метода наблюдател€, чтобы узнать, отменен ли запрос, и позволить ей отменить несколько соответствующих запросов одновременно.


—кидки 50% в Merion Academy

¬ыбрать курс