Контракты и версионирование сервисов

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

Почему это важно: Без чётких контрактов изменение одного сервиса ломает все остальные. Это главная боль микросервисов.

Главная идея

Контракт — это договор между сервисами, и его изменение должно быть управляемым: версионирование, contract testing, обратная совместимость.

Как это выглядит на практике

Сервис A вызывает сервис B по REST/gRPC.
Команда B решает изменить формат ответа.
Без версионирования сервис A сразу падает.
С versioning: B поддерживает старый и новый формат, A мигрирует в своём темпе.

Что происходит под капотом

Contract testing (Pact): тесты, которые проверяют, что обе стороны согласны с контрактом.
Schema registry (Avro, Protobuf): централизованное место для схем сообщений.
Backward compatibility: новые версии должны понимать старые запросы.
Forward compatibility: старые сервисы должны игнорировать неизвестные поля в ответе.

Типичные ошибки и заблуждения

Ошибка: контракт = OpenAPI-файл. Контракт — это и поведение, не только структура.
Ошибка: версионирование URL — единственный способ. Часто хватает версионирования полей.
Ошибка: можно изменять контракт без согласования. Это путь к каскадным авариям.
Ошибка: contract testing — лишняя работа. Это страховка от регрессий, которая окупается мгновенно.

Ключевые выводы

Контракт — это договор, нарушение ломает всю систему.
Backward + forward compatibility — фундамент эволюции API.
Contract tests ловят регрессии до мержа.
Schema registry централизует знания о форматах.

Термины урока

API contract: договор между потребителем и поставщиком API.

Pact: инструмент consumer-driven contract testing.

Protobuf: язык описания структур данных и схем gRPC.

Backward compatibility: совместимость с предыдущими версиями.

Связь с работой backend-разработчика

В микросервисной архитектуре дисциплина контрактов важнее, чем дисциплина кода. Это то, что отличает работающую систему от хаоса.

Мини-разбор реальной ситуации

Команда удалила 'неиспользуемое' поле из ответа сервиса. Через час 4 других сервиса начали падать с ошибками парсинга. Контракт-тесты остановили бы это в CI.

Что запомнить

Изменения контрактов — всегда через версионирование.
Backward compatibility — обязательна.
Contract testing экономит ночи.

Итог

Контракты — это нервная система микросервисной архитектуры. Без дисциплины здесь любой выигрыш от микросервисов теряется.