Основы gRPC: контракты protobuf, потоки и подходящие задачи

Что это такое

Введение в gRPC (указано в источниках) описывает модель: сервис и его методы определяются в файле .proto, protoc создаёт клиентские заглушки и серверные интерфейсы для каждого языка, а клиент вызывает метод удалённого сервера словно у локального объекта; Protocol Buffers по умолчанию служат и языком описания интерфейса, и форматом сообщений. Страница основных понятий (указана в источниках) перечисляет четыре вида методов: унарный, с серверным потоком, с клиентским потоком и с двунаправленным потоком. У каждого вызова может быть крайний срок, после которого он завершается ошибкой DEADLINE_EXCEEDED; любая сторона может отменить вызов; метаданные передаются вместе с ним как пары ключ/значение; вызовы завершаются статусом из фиксированного набора (OK, NOT_FOUND, UNAVAILABLE и другие). FAQ (указан в источниках) отмечает, что gRPC следует семантике HTTP поверх HTTP/2, но явно допускает полнодуплексные потоки, использует статические пути для диспетчеризации и формализует собственный набор ошибок вместо кодов состояния HTTP.

Почему это важно

Сгенерированные типизированные клиенты для многих языков, потоковая передача и сроки завершения, распространяемые по цепочкам вызовов, устраняют целый класс рукописного клиентского кода и ошибок тайм-аутов. Цена — двоичная полезная нагрузка, HTTP/2 на всём пути и инструменты, которых нет у обычного curl.

Как применять

• Используйте gRPC для внутренних вызовов между сервисами, где обе стороны сгенерированы из одних файлов .proto, для потоков (телеметрия, подписки, большие наборы результатов) и для мобильных клиентов, для которых FAQ отмечает экономию полосы пропускания и соединений.
• Задавайте крайний срок каждого клиентского вызова и передавайте оставшееся до него время последующим вызовам; обеспечьте проверку отмены сервером в длительных циклах.
• Сопоставляйте ошибки со стандартными кодами состояния, а подробности помещайте в сообщение или сведения об ошибке; не изобретайте коды.
• Храните файлы .proto в одном пакете с проверкой совместимости при изменениях; номера полей — это контракт.
• Для браузеров используйте gRPC-Web, который FAQ описывает как общедоступный; для публичных партнёрских API предлагайте JSON поверх HTTP вместо gRPC либо с преобразованием из его определений.
• Убедитесь, что каждый балансировщик и прокси по пути передаёт HTTP/2 до бэкенда; gRPC требует его на всём пути.

Подводные камни

Предположение, что gRPC автоматически быстр: сериализация дешева, но дизайн с множеством мелких вызовов таким и остаётся. Долгоживущие потоки, привязывающие соединение к одному бэкенду и нарушающие балансировку нагрузки. Повторы INVALID_ARGUMENT так же, как UNAVAILABLE, потому что клиент не различает коды, допускающие повтор. Предоставление gRPC интеграторам, у которых есть только HTTP-инструменты.