Wiki · Технологии разработки

gRPC

4 мин чтенияАвтор: Сергей ЧерняковСоавторы: Евгений Баев

Содержание 5 разделов

gRPC – это открытый фреймворк для удалённого вызова процедур: одна программа вызывает функцию другой программы на другом сервере так, будто она локальная. Данные передаются в двоичном формате Protocol Buffers поверх HTTP/2.

Название обычно звучит, когда система уже не помещается в одно приложение. Каталог, корзина, расчёт доставки и склад живут как отдельные сервисы и постоянно переговариваются. Разработчики говорят: «между сервисами у нас gRPC, наружу REST». Разберём, что за этим стоит и как это касается заказчика.

Откуда gRPC и как он устроен

Google больше десяти лет пользовался внутренней системой вызовов под названием Stubby, а в 2015 году открыл её следующую версию как gRPC. Официально поддерживаются больше десяти языков, среди них Go, Java, C++, Python, Node.js, C#, Kotlin, Swift и PHP.

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

service Delivery {
  rpc GetPrice (Address) returns (Price);
}

По этому файлу генератор создаёт код для сервера и клиента на нужных языках. Сервис на Go и мобильное приложение на Kotlin общаются по одному описанию, и ошибка вида «отправили строку вместо числа» ловится ещё при сборке.

Вызовы бывают четырёх видов: обычный запрос и ответ, поток ответов от сервера, поток запросов от клиента и двусторонний поток. Клиент может указать дедлайн, сколько он готов ждать ответа: если время вышло, вызов завершается ошибкой, а не висит бесконечно.

Схема gRPC: из proto-файла генерируют код сервера и клиента, мобильное приложение вызывает функцию сервиса доставки по HTTP/2 — Как сервисы договариваются через gRPC

Чем gRPC отличается от REST API

	REST API	gRPC
Формат данных	обычно JSON, читается глазами	Protocol Buffers, двоичный и компактный
Описание	по желанию, чаще всего OpenAPI	proto-файл обязателен
Транспорт	HTTP/1.1 или HTTP/2	только HTTP/2
Потоковая передача	через дополнительные технологии	встроена
Вызов из браузера	напрямую	через прокси и gRPC-Web
Проверка руками	браузер, curl, Postman	Postman и специальные утилиты

Как устроен обычный API сайта и какие у него бывают ответы, мы разбирали отдельно. Здесь важно одно: REST удобен для публичного API, который подключают сторонние компании, а gRPC для обмена внутри системы, где обе стороны пишет одна команда.

Где gRPC уместен, а где нет

Связь микросервисов внутри одной системы, где запросов много и важна скорость.
Мобильное приложение и его сервер: компактные сообщения меньше расходуют трафик, а код клиента генерируется из того же proto-файла.
Потоки событий: статусы заказов, отслеживание курьера, обновления в реальном времени.
Обычный сайт на 1С-Битрикс или WordPress с формой заявки. Здесь gRPC добавит инфраструктуру и не даст выигрыша.
Публичный API для партнёров. Им проще подключиться к REST с понятной документацией.

Почему браузер не вызывает gRPC напрямую

В браузере нет программного интерфейса, который дал бы скрипту нужный контроль над запросами HTTP/2. Поэтому для веб-страниц сделан gRPC-Web: браузер отправляет обычный запрос, а прокси-сервер, например Envoy, переводит его в настоящий gRPC. Ограничение остаётся: из браузера доступны обычные вызовы и поток ответов от сервера, а потоки от клиента и двусторонние спецификация gRPC-Web не требует.

Схема: мобильное приложение вызывает gRPC-сервер напрямую, а страница в браузере отправляет запрос gRPC-Web через прокси Envoy — Почему браузеру нужен прокси для gRPC

Для заказчика это значит лишний компонент, который надо настроить, обновлять и мониторить. Если сайт должен напрямую говорить с сервисами на gRPC, спросите подрядчика, где будет стоять прокси и кто за него отвечает.

gRPC против REST, Protocol Buffers и вызовы из браузера

Что выбрать для нового проекта: gRPC или REST?

Для внешнего API, который будут подключать партнёры и сайт, обычно выбирают REST: его проще проверить и описать. gRPC берут для обмена между своими сервисами и с мобильным приложением, где важны скорость, строгий договор о данных и потоковая передача. Часто в одной системе есть и то и другое.

Что такое Protocol Buffers?

Protocol Buffers – это формат и язык описания данных от Google, который gRPC использует по умолчанию. Структуру сообщений описывают в proto-файле, а данные передаются в двоичном виде, компактнее JSON.

Как проверить, что сервис на gRPC отвечает?

Сервис на gRPC проверяют клиентом, который понимает этот протокол, например Postman: в нём есть отдельный тип запроса gRPC, куда загружают proto-файл или включают рефлексию сервера. Браузер и обычный curl для этого не подходят, потому что ответ двоичный и идёт по HTTP/2. Ещё у сервиса стоит предусмотреть стандартную проверку здоровья, которую опрашивает мониторинг.

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

Источники