Skip to main content

Бинарный RPC: gRPC

gRPC — это бинарный RPC-фреймворк, разработанный Google. В отличие от текстовых RPC (JSON-RPC, SOAP, GraphQL), gRPC использует бинарный формат и работает строго поверх HTTP/2 (который, в свою очередь, работает поверх TCP).

Image

Protocol Buffers​

Для описания API и сериализации данных gRPC использует Protocol Buffers (protobuf). Вы пишете .proto-файл, в котором описываете структуры данных и методы сервиса. Из этого файла генерируется код (boilerplate) для нужного языка — он реализует парсинг, сериализацию и вызов методов.

Бинарный формат делает обмен более компактным и быстрым по сравнению с текстовыми протоколами, что особенно важно для внутренних микросервисных взаимодействий (back-to-back).

Возможности gRPC​

Две интересные фичи:

  1. Тайм-аут запроса. В самом запросе можно указать максимальное время ожидания ответа. Если сервер не успевает обработать запрос за это время, он может просто прекратить работу над ним — не тратить ресурс впустую.
  2. Отмена запроса. Клиент, отправив запрос, может в любой момент отправить сигнал отмены — например, если пользователь передумал или ушёл со страницы. Сервер получит уведомление и остановит обработку.

Эти возможности специфичны для gRPC и в классических HTTP+REST встречаются реже.

Стриминг​

Помимо обычного режима «запрос-ответ», gRPC поддерживает стриминг:

  • Client-side streaming — клиент отправляет поток сообщений, сервер возвращает один ответ.
  • Server-side streaming — клиент отправляет один запрос, сервер отвечает потоком сообщений.
  • Bidirectional streaming — обе стороны обмениваются потоками сообщений в произвольном порядке.

Эта возможность стала возможной благодаря механике HTTP/2 — фреймам и стримам. Именно они позволяют организовать параллельную передачу данных в рамках одного соединения.

Область применения​

gRPC ориентирован на back-to-back взаимодействия (микросервисы, внутренние сервисы) и даёт выигрыш в скорости и компактности за счёт бинарного протокола и генерации кода.

Резюме​

  • Бинарный протокол на основе Protocol Buffers.
  • Работает строго поверх HTTP/2.
  • Поддерживает тайм-ауты и отмену запросов.
  • Три режима стриминга: client-side, server-side, bidirectional.
  • Оптимален для микросервисной архитектуры и внутренних взаимодействий.