gRPC и HTTP/2: как работает
Зачем это на собесе
Ждут понимания, почему gRPC быстрее REST и какие у него ограничения.
Объяснение
gRPC — RPC-фреймворк от Google: контракт описывается в .proto, транспорт — HTTP/2, сериализация — Protocol Buffers (бинарная).
| Свойство | Как даёт эффект |
|---|---|
| HTTP/2 | мультиплексирование запросов в одном соединении, сжатие заголовков (HPACK), двусторонний стриминг |
| Protobuf | компактный бинарный формат, быстрая (де)сериализация |
| Кодогенерация | типизированные клиент и сервер на многих языках |
| Стриминг | server, client и bidirectional |
| Deadlines | встроенный тайм-аут, передаваемый по цепочке вызовов |
Вызов выглядит как вызов метода, но это сетевой вызов: у него есть сбои и задержка.
Ограничения
- Браузер не может вызывать gRPC напрямую (нужен gRPC-Web или transcoding).
- Отладка сложнее: бинарный формат (используйте
grpcurl, Postman, Kreya). - Балансировка: длинные HTTP/2-соединения требуют L7-балансировщика или клиентской балансировки.
- Меньше подходит для публичных API.
Нюансы и подводные камни
- Один канал
GrpcChannelсоздаётся один раз и переиспользуется (как HttpClient), а не на каждый вызов. - Балансировщик L4 привязывает все вызовы одного соединения к одному поду.
- Требуется HTTP/2 с TLS (ALPN) или h2c внутри сети.
- Для больших сообщений лимит по умолчанию 4 МБ на приём.
Практика
- Сравните latency и размер сообщения REST и gRPC на одном сервисе.
- Вызовите сервис через
grpcurlс reflection. - Настройте клиентскую балансировку по DNS.
Вопросы с ответами
Почему gRPC быстрее REST/JSON?
Бинарный protobuf, HTTP/2 с мультиплексированием и сжатием заголовков, кодогенерация без парсинга JSON.
Почему в gRPC проблемы с балансировкой?
Долгоживущее HTTP/2-соединение закрепляет клиента за одним бэкендом; нужна L7-балансировка или клиентская.
Можно ли вызвать gRPC из браузера?
Только через gRPC-Web или JSON transcoding.