gRPC – краткий обзор

gRPC (Google Remote Procedure Call) – open-source фреймворк для работы с удаленными вызовами процедур. Разработан в 2015 году корпорацией Google на основе парадигмы RPC. Применяется для межсистемной интеграции наряду с REST, SOAP и GraphQL.

Особенности gRPC

Основная фишка gRPC – высокая пропускная способность и снижение нагрузки на сеть. Достигается это благодаря тому, что gRPC использует Protoboof и HTTP/2.

Protobuf (Protocol Buffers)

Формат сериализации данных в бинарном формате. Он не является человеко-читаемым, но зато дает высокую производительность и низкую нагрузку на сеть. Поддерживается большинством языков программирования.

HTTP/2

Версия протокола HTTP, который поддерживает двунаправленную потоковую передачу (прямо как веб-сокеты), а также позволяет группировать запросы во фреймы. Это удобно, так как в одном канале может быть замультиплексировано несколько запросов, идущих фреймами. Сообщения внутри фреймов можно приоритизировать. Благодаря HTTP/2, не нужно заново устанавливать соединение под каждый запрос, весь обмен данными происходит в одном TCP-соединении.

Принцип работы gRPC

Коммуникация между клиентом и сервером осуществляется не HTTP-вызовом, а вызовом процедуры. Клиент вызывает удаленную процедуру, сериализует параметры и дополнительную информацию в сообщении, после чего шлет сообщение на сервер. Приняв данные, сервер производит их десериализацию, выполняет запрошенную операцию и шлет результат обратно клиенту. Сериализация и десериализация параметров осуществляется специальными объектами: stub сервера и stub клиента.

Разработка начинается строго с контракта: необходимо сначала описать proto-файлы и затем преобразовать контракт в заглушки для реализации клиента. Для этого существует множество плагинов кодогенерации, написанных Google.

Режимы взаимодействия сервера и клиента

gRPC предусматривает четыре возможных режима взаимодействия сервера и клиента:

1. Однонаправленное (Unary gRPC): после каждого запроса клиент ждет ответа от сервера.
2. Потоковая передача сервера: в ответ на запрос клиента сервер предоставляет поток сообщений.
3. Потоковая передача клиента: сервер принимает поток сообщений от клиента и отвечает одним подтверждающим сообщением.
4. Двунаправленный обмен (дуплексный): потоки сообщений одновременно передаются в обоих направлениях.

Ограничения

1. Высокий порог входа. Требуется больше времени и усилий для настройки и развертывания.
2. Vendor lock. Google является основным драйвером и определяет направление развития протокола.
3. Сложности балансировки нагрузки. В gRPC устанавливается постоянное соединение с одним сервисом, что затрудняет перераспределение запросов между экземплярами сервиса.
4. В gRPC не поддерживается трассировка запросов.
5. Сообщения в Protobuf нечеловекочитаемы.

Применение

gRPC следует использовать, когда критически важна высокая пропускная способность и производительность при низких требованиях к сети и аппаратным ресурсам, например, в платформах интернета вещей. Также gRPC очень хорош для общения микросервисов в MSA.

В следующем посте сравним REST и gRPC по пунктам.

Подборка материалов

Теория

1. Что нужно знать о gRPC системному аналитику
2. Что такое gRPC и как он работает — обзорная статья Highload Today
3. Объяснение буферов протокола, потоковой передачи и архитектуры
4. REST vs SOAP, gRPC и GraphQL: стили межсистемной интеграции по API — Babok School
5. gRPC на практике: особенности, преимущества и недостатки — Хабр
6. Что такое gRPC и Protobuf — Merion

Практика

1. Как мы используем микросервисы и GRPC
2. Courier: миграция Dropbox на gRPC
3. Опыт использования gRPC в Почте Mail.ru
4. gRPC в качестве протокола межсервисного взаимодействия. Доклад Яндекса

Видео

1. Какие сервисы делать на gRPC? // Демо-занятие курса «Системный аналитик. Advanced»
2. gRPC для микросервисов или не REST-ом единым
3. gRPC лучше REST? — Systems Education