gRPC и Protobuf: бинарный контракт и его цена

Выкатили новый микросервис. В течение часа orders-сервис начинает читать неверные значения: priority приходит как discount_pct, и возвраты срабатывают на здоровых заказах. Данные никто не менял — кто-то перенумеровал поле protobuf с 4 на 3, чтобы «прибраться в схеме». На проводе нет имён полей, только номера, поэтому каждый потребитель, всё ещё работающий на старой схеме, декодировал поле 3 не в тот слот. Proto скомпилировался чисто. Тесты прошли. Прод сорок минут молча портил состояние.

Формат провода: номера, а не имена

JSON шлёт схему с каждым сообщением. {"userId": 42, "active": true} повторяет ключи userId и active в каждом payload, как UTF-8 текст, на каждом запросе. Protobuf делает наоборот: сериализует только номер поля, тип на проводе и значение. То же сообщение становится примерно 08 2A 10 01 — горстка байт, где 08 кодирует «поле 1, varint», 2A — это 42, и так далее. Имена полей живут только в файле .proto на этапе компиляции; они никогда не путешествуют.

Этот один выбор даёт те самые числа, о которых думают сеньоры. Для данных с большим числом чисел protobuf примерно в 4-5 раз компактнее JSON благодаря varint-кодированию (маленькие целые стоят один байт, а не длину их десятичной строки). Сериализация примерно в 3-6 раз быстрее, а парсинг в 5-10 раз быстрее, потому что нет токенизации текста, нет аллокации строк-ключей, нет рефлексии — декодер идёт по известной раскладке. В Go-бенчмарках это выливается в ~5-7x быстрее round-trip при ~3x меньше аллокаций. Расплата — зеркало суперсилы JSON: нельзя декодировать protobuf-сообщение без его схемы. Байты сами по себе бессмысленны.

Номера полей это контракт, навсегда

Поскольку на проводе несётся поле 3, а никогда "discount_pct", идентичность данных задаёт номер поля, а не имя. Это полностью переворачивает привычную интуицию:

• Переименовать поле бесплатно. discount_pct → discountPercent ничего не меняет на проводе; старые и новые бинарники взаимодействуют идеально. Имя это локальная метка в исходнике.
• Перенумеровать поле катастрофа. Поменяй 3 на 4, и каждый пир всё ещё на старой схеме читает твоё новое поле 4 в то, что он зовёт полем 4, а данные твоего старого поля 3 падают туда, где он ждёт 3. Это и есть баг из Hook. Компилятор его не ловит, потому что каждая сторона компилирует самосогласованную схему.
• Переиспользовать удалённый номер та же катастрофа, отложенная. Удали поле 3, потом позже добавь новое несвязанное поле и присвой ему 3 — теперь старые клиенты, шлющие исходное поле 3, отравляют новое.

Дисциплина, которая всё это предотвращает, — add-only эволюция плюс reserved. Ты никогда не меняешь и не переиспользуешь номер; только дописываешь новые поля с новыми номерами, а удаляя поле, резервируешь его номер (и имя), чтобы никто не смог его вернуть:

message Order {
  reserved 3;                  // discount_pct, удалено 2026-Q1 — не переиспользовать
  reserved "discount_pct";
  string id = 1;
  int64 amount_cents = 2;
  Priority priority = 4;       // безопасно: дописано со свежим номером
}

Сделанная так схема одновременно обратно совместима (новый код читает сообщения, записанные старым: отсутствующие новые поля просто берут дефолты proto3 — 0, "", пусто) и прямо совместима (старый код читает сообщения нового: неизвестные номера полей пропускаются и сохраняются, а не вызывают ошибку). Эта двусторонняя совместимость и есть вся причина, почему большие полиглот-системы могут деплоить продюсеров и консьюмеров независимо.

Одно соединение, четыре формы вызова

gRPC работает поверх HTTP/2, и это даёт мультиплексирование: множество одновременных RPC переплетаются как независимые стримы по одному TCP-соединению, без head-of-line blocking на уровне HTTP — 50 одновременных вызовов нужны одно соединение, а не 50. Отменённый или истёкший по дедлайну вызов шлёт RST_STREAM, который убивает только этот стрим и оставляет остальные нетронутыми. Поэтому пропускная способность gRPC в service mesh держится под конкурентностью там, где модель «соединение на запрос» у HTTP/1.1 рушится.

Поверх этого одного соединения блок service в схеме определяет четыре формы вызова, и выбор не той — частый запах дизайна:

1. Unary — один запрос, один ответ. REST-образный случай на 95%.
2. Server streaming — один запрос, стрим ответов (поток цен, хвост лога, прогресс с пушем от сервера).
3. Client streaming — стрим запросов, один ответ (загрузка чанков, батчинг телеметрии).
4. Bidirectional streaming — обе стороны стримят независимо в одном вызове (чат, живая коллаборация, долгоживущий канал управления).

service PriceService {
  rpc GetQuote(QuoteRequest) returns (Quote);                  // unary
  rpc WatchPrices(WatchRequest) returns (stream Quote);        // server streaming
  rpc UploadTrades(stream Trade) returns (UploadSummary);      // client streaming
  rpc Trade(stream Order) returns (stream Fill);               // bidirectional
}

Вместе с этим едут две операционные фичи, которые легко пропустить, пока они не укусят. Дедлайны: клиент задаёт таймаут, который распространяется вниз по цепочке вызовов; когда он истекает, RPC авто-отменяется на обоих концах, и медленный downstream не может вечно держать серверные потоки. Классический сбивающий с толку отказ — вызов с deadline-exceeded, который успел на сервере («я отправил все ответы»), но упал на клиенте («они пришли слишком поздно») — работа сделана, а вызывающий увидел ошибку. Отмена: любая сторона может прервать вызов на лету, и проброшенная отмена останавливает downstream-работу вместо того, чтобы дать осиротевшим запросам молоть впустую. Пропуск дедлайнов — самая частая причина, почему gRPC-mesh каскадно уходит в исчерпание ресурсов при частичном отказе.

Где gRPC выигрывает, а где больно

gRPC — верный дефолт для внутреннего трафика между сервисами: типизированный контракт, разделяемый полиглот-сервисами, выигрыши в 4-10x по скорости и размеру на горячих путях, нативный стриминг и проброс дедлайнов по графу вызовов. В нагруженном mesh эта экономия не академическая — она режет хвостовую latency и CPU на пути сериализации, который REST тратит на JSON.

Боль реальна и приходит в двух местах. Во-первых, браузер не умеет говорить на gRPC. Браузеры не могут управлять HTTP/2-фреймингом или трейлерами, поэтому нужен grpc-web плюс прокси (Envoy или собственный прокси фреймворка), чтобы транслировать между браузером и gRPC-бэкендом — лишняя инфраструктура, и grpc-web всё ещё не умеет client- или bidirectional-стриминг. (Connect-RPC обходит часть этого, отдавая unary-вызовы как обычный HTTP.) Во-вторых, отлаживаемость рушится. Бинарный payload нечитаем во вкладке Network в Chrome — ты видишь «передано байт», а не поля. curl бесполезен без схемы и декодера; трейлеры прячутся внутри байт тела ответа, где у DevTools нет хука. Логи, реплей запросов и ad-hoc осмотр — всё требует дополнительного тулинга. Эта непрозрачность и есть налог за компактность — то самое свойство, что делает провод маленьким, делает его непостижимым для людей.