API
gRPC и Protobuf: тест с множественным выбором
Суть Синтез юнита gRPC/Protobuf с множественным выбором — совместимость по field tag, эволюция схемы, формы streaming, deadlines и решение gRPC-против-REST на границе.
Высота — путь к senior
НольJuniorMiddleSenior
Ты на senior-высоте — в орбитеШесть вопросов поперёк всего юнита. Каждый отражает реальное решение — изменение схемы, которое ты подписываешь, форму streaming для выбора, deadline для установки — а не определение для заучивания. На проводе едут номера, а не имена, и большинство этих ловушек рождается из того, что про это забыли.
Цель
Убедись, что связываешь wire format Protobuf, дисциплину field tag, четыре формы вызовов, deadlines и границу gRPC-против-REST — синтез, к которому вёл урок.
Викторина
Completed
Коллега переименовывает поле Protobuf с discount_pct на discountPercent и тем же коммитом перенумеровывает его с 3 на 4, чтобы номера шли подряд. Какое изменение безопасно, а какое портит данные?
Heads-up Protobuf сериализует только field tag, wire type и значение — имена живут в .proto на этапе компиляции и не едут. Идентичность задаёт номер, поэтому перенумерация переназначает смысл на проводе.
Heads-up На проводе нет строкового ключа. Переименование меняет только локальную метку в исходниках; старые и новые бинарники прекрасно совместимы при переименовании.
Heads-up Перекомпиляция не помогает: каждая сторона компилирует самосогласованную схему, поэтому компилятор никогда не видит конфликта. Портят именно отстающие на старом номере.
Викторина
Completed
Нужно удалить устаревшее поле с номером 3 из сообщения, живущего в production. Каков senior-ход?
Heads-up Компилятор проверяет только самосогласованность текущего файла. Поздняя невинная правка может переназначить 3 новому полю, и старые клиенты, всё ещё шлющие исходное поле 3, отравят его. Именно reserved это блокирует.
Heads-up Перенумерация — ровно та катастрофа, которой надо избегать: пиры на старой схеме декодируют значения в неверные поля. Пробелы в нумерации совершенно нормальны и ничего не стоят на проводе.
Heads-up Смена типа не делает удаление безопасным и сама может сломать wire-совместимость. Проблема в идентичности номера, которую защищает только reserved.
Викторина
Completed
Новая сборка producer'а добавляет поле 7 и шлёт его consumer'ам, всё ещё на старой схеме; тем временем старый producer вовсе опускает поле 7, общаясь с новыми consumer'ами. Что происходит в каждом направлении?
Heads-up Protobuf построен под частичные совпадения: неизвестные поля пропускаются, отсутствующие — берут default. Строгое отклонение по точному совпадению сделало бы независимый деплой невозможным.
Heads-up Неизвестные field tag пропускаются, используя их wire type, чтобы узнать длину — и сохраняются для повторной сериализации. Никаких падений; это и есть forward compatibility.
Heads-up У proto3 есть чётко определённые нулевые default'ы (0, пустая строка, false, пусто) для отсутствующих скалярных полей — null для них нет. Поля-сообщения — исключение, доступное через presence.
Викторина
Completed
Дашборду нужно, чтобы сервер пушил живые обновления цены каждому клиенту, пока тот подписан, без запроса на каждое обновление. Какая форма RPC подходит и какова частая ошибка?
Heads-up Опрос возвращает накладные расходы запрос-на-обновление, которые server streaming и устраняет, и добавляет задержку, равную интервалу опроса. Server streaming пушит данные по мере готовности по одному открытому потоку.
Heads-up Это обратное тому, что нужно. Client streaming подходит для загрузок/батчинга телеметрии; здесь поток производит сервер.
Heads-up Server streaming уже пушит поток ответов из одного запроса. Bidi — когда обе стороны стримят независимо (чат, каналы управления); использовать его здесь — переусложнение.
Викторина
Completed
Клиентский вызов возвращает DEADLINE_EXCEEDED, но логи сервера показывают, что обработчик завершился и закоммитил запись. Как это читать и каков надёжный фикс?
Heads-up Deadline отменяет RPC на обоих концах, но не может откатить уже выполняющуюся на сервере работу. Исход «успех на сервере / ошибка у клиента» — классическая гонка deadline.
Heads-up Deadlines распространяются как относительная длительность в metadata, а не абсолютное wall-clock время, поэтому расхождение часов ни при чём. Причина — ответ проиграл гонку deadline.
Heads-up Снятие deadlines — путь, которым mesh каскадно уходит в исчерпание ресурсов: медленные downstream'ы навечно пинят caller'ов. Фикс — идемпотентность плюс реалистичные deadlines, а не их удаление.
Викторина
Completed
Публичный REST-эндпоинт, дёргаемый напрямую из React SPA, тормозит под нагрузкой. Коллега предлагает перевести его на нативный gRPC, чтобы браузер звал его напрямую. Каков senior-ход?
Heads-up Браузеры вообще не могут делать нативные gRPC-вызовы. Тебя вынудят на grpc-web и хоп через прокси, ты потеряешь читаемые payload'ы в DevTools и почти ничего не выиграешь, если payload насыщен строками.
Heads-up У границы и внутреннего яруса противоположные ограничения. Принуждение к одному протоколу тащит требование прокси и бинарную непрозрачность к браузеру, где они стоят дороже всего, ради единообразия, которое тебе не нужно.
Heads-up Это выбрасывает типизированный контракт и гарантии эволюции схемы, ради которых gRPC вообще существует, и заново изобретает фрейминг, deadlines и backpressure вручную — обычно хуже любого из вариантов.
Итог
Сквозная линия юнита — один факт: провод несёт field tag и значения, никогда имена. Поэтому переименование бесплатно, а перенумерация или переиспользование номера — молчаливая порча; add-only эволюция с reserved — единственный безопасный путь, и именно она даёт Protobuf двустороннюю backward/forward совместимость. Поверх мультиплексирования HTTP/2 четыре формы вызовов отражают, кто стримит (unary, server, client, bidi), deadlines распространяются и могут провалить caller’а, чья работа реально удалась, а решение на границе остаётся прежним: gRPC между твоими сервисами, REST/JSON или Connect-RPC у браузера.