Проверяет понимание стратегий управления версиями gRPC-контрактов для обеспечения обратной совместимости API.
В gRPC контракт определяется через Protocol Buffers (proto-файлы). Версионирование здесь отличается от REST, где часто используют /v1, /v2 в URL. В gRPC принято стремиться к эволюции контракта без явных версий, чтобы сохранить совместимость между клиентами и серверами.
Основные правила: не изменять номера полей, не удалять поля (можно пометить как reserved), не менять типы существующих полей. Новые поля добавляются с новыми номерами. Это позволяет старым клиентам игнорировать неизвестные поля, а новые клиенты могут использовать их.
syntax = "proto3";
package user.v1;
message User {
string id = 1;
string name = 2;
// Добавляем новое поле без нарушения совместимости
string email = 3;
reserved 4, 5; // зарезервировано для будущего
}Если изменения несовместимы (например, изменение типа поля), создают новую версию сервиса. Обычно используют разные имена пакетов (user.v1, user.v2) или добавляют суффикс к имени сервиса (UserServiceV2). Это позволяет сосуществовать нескольким версиям одновременно.
package user.v2;
message User {
string id = 1;
string full_name = 2; // изменили поле name
}Вывод: Версионирование gRPC-контрактов строится на эволюции proto-файлов с соблюдением правил обратной совместимости. Для критических изменений создают новые версии пакетов или сервисов. Это обеспечивает плавное обновление API без сбоев для клиентов.
