gRPC: от контракта до сервиса в проде

Что gRPC обещает вызывающему коду и что на самом деле уходит в сеть: сервис и метод из контракта, сгенерированная заглушка, канал, статус и метаданные, а под ними поток HTTP/2 с сообщениями с префиксом длины и статусом в трейлерах.

1. Что такое gRPC: вызов метода на другой машине по общему контракту
2. Вызов gRPC: метод из контракта, а не запрос к ресурсу
3. Вызов на проводе: поток HTTP/2, сообщения и трейлеры

Как protobuf кодирует сообщение и что из этого следует для схемы: номера полей и типы на проводе, значения по умолчанию и наличие поля, enum и oneof, а затем правила развития схемы, по которым старый клиент продолжает работать.

1. Protobuf на проводе: номер поля, тип и неотличимый ноль
2. Эволюция схемы: какие изменения ломают старого клиента

Как orders.proto живёт в репозитории: генерация кода Go плагинами protoc, buf и EasyP, доставка контракта клиентам, линт схемы и проверка ломающих изменений против основной ветки в CI.

1. Кодогенерация и доставка контракта
2. Линт и проверка ломающих изменений в CI

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

1. Коды статуса: исход вызова, по которому клиент выбирает реакцию
2. Клиентский канал: когда открывается соединение
3. Дедлайн и повторы: один бюджет на всю цепочку
4. Остановка и health: сервер уходит, не обрывая вызовы

Где в gRPC живёт сквозная логика (логи, метрики, аутентификация, восстановление после паники, валидация) и в каком порядке она выполняется, и почему правила проверки входных данных удобнее держать в самой схеме.

1. Интерцепторы: сквозная логика вокруг вызова
2. Валидация в схеме: protovalidate

Четыре вида вызова и что меняется, когда сообщений больше одного: управление потоком, медленный получатель, конец потока и ошибка посреди него, а затем подписка на события заказа, которая переживает обрыв и перезапуск сервера.

1. Четыре вида вызова и медленный получатель
2. Подписка на события заказа через поток

Как сервис заказов отдаёт тот же контракт внешнему клиенту по REST и JSON и браузеру: gRPC-Gateway с аннотациями google.api.http, описание OpenAPI из той же схемы и чем это отличается от gRPC-Web.

1. gRPC-Gateway: REST и OpenAPI из того же контракта

Что меняется, когда сервис заказов работает в несколько экземпляров: почему балансировка долгих соединений HTTP/2 не работает по привычке, какие метрики и трассы снимать с вызовов, и как сервисы доверяют друг другу через TLS, mTLS и токены в метаданных.

1. Балансировка: одно соединение HTTP/2 на много вызовов
2. Наблюдаемость вызовов: метрики, трассы и код статуса
3. Безопасность: TLS, mTLS и токен в метаданных