Сообщить об ошибкеКороткий ответ
При множестве независимых потребителей эволюцию контракта ведут через строго аддитивные изменения, явное версионирование при неизбежных breaking changes и длительные периоды параллельной поддержки версий; решение о выводе старой версии зависит от реальной телеметрии использования, а не от предположений.
Как это работает подробнее
Аддитивные изменения (новые необязательные поля) безопасны для потребителей, игнорирующих неизвестные поля; при breaking change вводят новую версию контракта, оставляя старую работающей, и мигрируют потребителей поэтапно.
Долгая параллельная поддержка нескольких версий даёт потребителям время на миграцию и снижает риск инцидентов, но увеличивает нагрузку на команду и усложняет кодовую базу. Быстрый вывод старой версии снижает эту нагрузку, но повышает риск сломать потребителей, которые не успели мигрировать. Критерий выбора — реальная доля трафика на старой версии, контрактные обязательства перед партнёрами и внутренняя стоимость поддержки нескольких версий одновременно.
Пример кода
Метрика перед выводом v1 из эксплуатации:
v1 traffic share: 2% (3 известных партнёра, 1 внутренний сервис)
-> точечное уведомление оставшихся потребителей с конкретным планом отключения,
а не общая рассылка "через 3 месяца отключаем v1"Что использовать на практике
- Практика. Для внешних партнёров период поддержки старой версии может растягиваться на месяцы из-за медленных циклов релиза на их стороне; consumer-driven contract testing (Pact) помогает заранее обнаружить, что изменение ломает известного потребителя.
Подводные камни
- Риск. Выводить старую версию по календарному плану без проверки реального трафика на неё; не вести реестр известных потребителей и их версий, что делает невозможным осознанное решение о выводе версии.