Обновление приложений в микросервисной и монолитной архитектурах

Deploy unit определяет blast radius и порядок совместимости. У монолита обычно один крупный artifact, у микросервисов — несколько независимо версионируемых artifacts и контрактов.

Монолит

Один выпуск содержит согласованный набор модулей. Это упрощает атомарность версии, локальные refactoring и rollback binary. Цена — крупный blast radius и совместное окно deploy для несвязанных функций.

Стратегии:

• rolling update нескольких экземпляров;
• blue/green с переключением трафика;
• canary на доле запросов;
• feature flag для отделения deploy от release.

Монолит не обязан останавливаться при обновлении: это зависит от topology и стратегии, а не от архитектурного ярлыка.

Микросервисы

Независимый deploy работает только при совместимых контрактах. В момент rollout одновременно существуют старая и новая версии.

Сначала server понимает old + new
→ затем обновляются clients
→ затем удаляется old contract

Для события consumer сначала начинает понимать новое необязательное поле, затем producer его публикует. Переименование/удаление выполняется отдельным поздним этапом.

Миграция БД: expand and contract

1. Добавить новую nullable column/table без удаления старой.
2. Выпустить код, способный работать с обеими схемами.
3. Заполнить данные и переключить чтение.
4. Остановить запись старого формата.
5. Удалить старую схему отдельной миграцией после проверки.

Rollback к старому binary невозможен, если schema уже стала несовместимой. Поэтому backward compatibility важнее “быстрого отката”.

Проверка выпуска

• health/readiness не подменяют бизнес synthetic check;
• отслеживаются error rate, latency, saturation и ключевые бизнес-сигналы;
• artifact идентифицируется версией/digest;
• migration отделена и наблюдаема;
• rollback/roll-forward отрепетирован;
• feature flag имеет owner и срок удаления.

Типичные сбои

• Одновременно удалить поле на server и обновить только часть clients.
• Запустить destructive migration перед новым кодом.
• Rollback image при необратимо изменённой схеме.
• Принять “процесс запущен” за успешный deploy.
• Выпустить все микросервисы одной волной и потерять их автономность.

Вопросы для собеседования

Почему rolling update требует совместимости? Старые и новые instances обслуживают трафик одновременно.

Чем deploy отличается от release? Deploy доставляет код, release открывает поведение пользователю, например flag.

Что такое expand-and-contract? Поэтапное совместимое изменение schema/contract с поздним удалением старой формы.

Почему rollback не всегда безопасен? Новый код мог изменить данные или schema так, что старый binary их не понимает.

Микросервис всегда проще обновить? Только при зрелых контрактах, автоматизации и наблюдаемости; зависимые изменения сложнее монолита.

См. Микросервисная архитектура, Артефакт, Docker.