Контракты между сервисами
В микросервисной системе сервисы общаются через API и события. Как документировать и проверять контракты, чтобы релизы не ломали consumers?
Короткий ответ
Нужно явно описывать API/event schemas, версионировать изменения и гонять contract tests между producer и consumer версиями. Breaking changes должны идти через migration window.
Полный разбор
Для HTTP API контракт можно фиксировать через OpenAPI/JSON Schema/gRPC proto, для событий - через schema registry или явно версионированные event schemas. Важно не давать сервисам читать чужие таблицы напрямую: публичный контракт должен быть API или событием.
Проверка - consumer-driven contract tests или совместимость producer/consumer схем. Перед релизом надо убедиться, что старая версия producer работает с новой версией consumer и наоборот, если такой режим возможен во время rolling deploy. Для событий полезны правила backward compatibility: добавление optional поля обычно безопаснее, переименование или удаление поля - breaking change.
Документация контракта должна жить рядом с кодом или в registry, а не только в устной договоренности. Для миграций нужен план: dual-write, dual-read, deprecation period и мониторинг ошибок парсинга.
Теория
В распределенной системе контракт - это продуктовая граница сервиса. Без проверки совместимости любой релиз producer-а может сломать consumer-ов.
Типичные ошибки
- Документировать контракт только в Confluence и не проверять его в CI.
- Менять event schema без backward compatibility.
- Давать сервисам ходить напрямую в общую БД.
Как отвечать на собеседовании
- Назови OpenAPI/schema registry/consumer-driven contract tests.
- Скажи про rolling deploy и backward compatibility.