gRPC и protobuf: скомпилированный контракт, транспорт HTTP/2 и балансировщик, не заметивший новые поды

Контракт компилируется в обе стороны

К концу этого раздела вы будете точно знать, почему переименование поля бесплатно, а смена тега — нет, и почему это различие определяет, что видит балансировщик.

REST-контракты живут в документации и расползаются; gRPC-контракт — это файл, который компилируется в обе стороны провода:

syntax = "proto3";
package inventory.v1;

service Inventory {
  rpc GetStock(GetStockRequest) returns (StockReply);
  rpc WatchStock(WatchRequest) returns (stream StockReply); // серверный стриминг
}

message GetStockRequest {
  string sku = 1;       // тег 1 — именно число и ЕСТЬ идентичность поля
  string warehouse = 2;
}

Запустите buf generate (или голый protoc с Go-плагинами) — и получите два артефакта: типизированную клиентскую заглушку, чьи методы сериализуют, отправляют и декодируют за вас, и серверный интерфейс — InventoryServer, — который обязан реализовать ваш код. Согласие двух команд о форме данных обеспечивает компилятор, а не страница в вики.

Деталь, которая меняет само мышление о protobuf: имена полей никогда не попадают на провод. Каждое закодированное поле — это ключ (номер тега, сдвинутый на три бита влево и объединённый по OR с wire type — типом кодирования, однозначно задающим размер значения), за которым идёт значение. Переименуйте sku в stock_unit — байты идентичны; поменяйте тег с 1 на 9 — вы молча создали другое поле. Ключ — varint, и поэтому значения тегов важны: теги с 1 по 15 укладывают ключ в один байт, с 16 по 2047 — в два. В сообщении, которое логируется миллионы раз в минуту, горячее repeated-поле с тегом 16 вместо тега 3 — это измеримый налог на хранилище. Планируйте пространство тегов как API: маленькие теги — горячим полям, и оставляйте зазоры на будущее.

Честные числа: protobuf-нагрузка обычно выходит в 2–5 раз меньше эквивалентного JSON и парсится примерно в 5–10 раз быстрее, потому что декодирование — арифметика над тегированными байтами, а не сканирование текста. Но gzip съедает большую часть выигрыша по размеру на крупных пейлоадах — сжатый JSON часто оказывается в пределах 1,5–2 раз от сжатого protobuf. Что переживает компрессию — стоимость парсинга, поведение аллокаций и сгенерированные типы: против gRPC-API никто не пишет археологию на json.RawMessage.

Одно соединение, мультиплексирование — и что видит балансировщик

gRPC работает поверх HTTP/2: клиент открывает одно TCP-соединение, и каждый RPC становится на нём стримом, кадры конкурентных вызовов свободно перемежаются. Ни рукопожатия на каждый вызов, ни тюнинга пула соединений, и запрос 2 не ждёт запроса 1 на уровне HTTP (потеря пакета всё ещё стопорит все стримы на уровне TCP — HTTP/2 починил HTTP-шный head-of-line blocking, но не TCP-шный).

У этой эффективности есть продакшен-следствие, за которое заплатили в крючке. Балансировщик четвёртого уровня — Kubernetes ClusterIP, AWS NLB — балансирует в момент приёма соединения. gRPC-клиент предъявляет ровно одно долгоживущее соединение (headless-Service — сервис без кластерного IP, чей DNS возвращает IP каждого пода), поэтому все его RPC прижимаются к бэкенду, который его принял. Масштабирование добавляет поды, с которыми ни один существующий клиент никогда не заговорит. Реальных опций три:

• Клиентская балансировка: headless-Service плюс "loadBalancingConfig": [{"round_robin":{}}] — канал держит под-соединение на каждый бэкенд и раскладывает вызовы. Нюанс: пере-резолв DNS ленивый; добавьте серверный MaxConnectionAge, чтобы соединения перерождались и находили новые поды.
• L7-прокси (Envoy, Linkerd): прокси говорит на HTTP/2 с обеих сторон и балансирует по стримам, а не по соединениям. Это ответ сервис-меша, ценой лишнего хопа.
• Не делать ничего — тоже решение: нормально для двух подов и фатально для автоскейлинга.

Все три варианта покрывают спектр от нулевых изменений инфраструктуры до полного сервис-меша. Когда вы масштабируете gRPC-сервис, а трафик не перераспределяется — почти всегда причина в том, что третий вариант был выбран неосознанно.

Четыре типа вызовов, путешествующие дедлайны и коды, которые врут дашбордам

Ключевое слово stream обобщает RPC до четырёх форм: unary (один запрос, один ответ — большинство вызовов), серверный стриминг (один запрос, много ответов: вотчи, фиды, выдача огромного результата без буферизации), клиентский стриминг (много запросов, один ответ: загрузки, батчинг телеметрии) и двунаправленный (оба сразу: чат, протоколы синхронизации, живая транскрипция). Сгенерированный Go-код даёт стримам методы Send и Recv поверх уже знакомой машинерии контекстов.

Дедлайны — то место, где gRPC тихо обыгрывает самодельные HTTP-конвенции. Поставьте дедлайн на клиентский контекст — и он передастся заголовком grpc-timeout в вызове, а также в каждом вызове ниже по цепочке из этого контекста, с оставшимся бюджетом. Дедлайн 500 мс на краю доезжает до третьего хопа тем, что от него осталось, и все сервисы падают быстро и вместе с DeadlineExceeded. С обычным HTTP вы переизобретаете это кастомными заголовками и командной дисциплиной; в gRPC это встроено в рантайм.

Ещё две вещи, на которых обжигаются сениоры. Первое: статус-коды gRPC — не HTTP-коды; HTTP-слой почти всегда говорит 200, а настоящий вердикт — OK, Unavailable, DeadlineExceeded, NotFound — едет в трейлере grpc-status. Дашборд, считающий HTTP 200 у gRPC-сервиса, не измеряет ничего. Второе: сквозные задачи живут в интерсепторах — это middleware gRPC, клиентские и серверные, unary- и stream-варианты:

func authInterceptor(ctx context.Context, req any, info *grpc.UnaryServerInfo,
	next grpc.UnaryHandler) (any, error) {
	if err := verifyToken(ctx); err != nil {
		return nil, status.Error(codes.Unauthenticated, "bad token")
	}
	return next(ctx, req) // цепочка продолжается — та же форма, что у http-middleware
}