Независимая развертываемость — это вся суть, поэтому каждому сервису нужен собственный pipeline CI/CD плюс низкорисковая стратегия выпуска — обычно canary или blue-green — чтобы безопасно развертываться многократно в день.
Каждый сервис собирается, тестируется и развертывается в собственном темпе. Изменение в одном сервисе никогда не вызывает полный выпуск системы.
commit ─▶ build ─▶ unit + contract tests ─▶ image ─▶ deploy (one service)
| Стратегия | Как | Преимущество | Недостаток |
|---|---|---|---|
| Rolling | Постепенно заменяйте инстансы | Просто, по умолчанию | Смешанные версии ненадолго |
| Blue-green | Два окружения, переключение трафика | Мгновенный откат | 2x инфраструктура |
| Canary | Отправьте небольшой % на новую версию | Ограничивает радиус поражения | Требует хорошей метрики |
v1 ████████████████ 95% ← watch error rate / latency
v2 █ 5% ← promote if healthy, roll back if not
└─ automated check on SLOs decides promote vs abort
[ Blue v1 ] ◀─ live ──┐
[ Green v2 ] ◀─ idle ├─ flip router ─▶ Green is live; Blue is instant rollback
Без обратно совместимых схем canary/blue-green ломаются, поскольку две версии работают одновременно. Всегда проектируйте изменения совместимыми между версиями.
Частые низкорисковые развертывания — это то, что делает микросервисы стоящими своей сложности — медленные рискованные выпуски уничтожили бы преимущество автономии.
Canary и blue-green ограничивают радиус поражения неудачного развертывания и обеспечивают почти мгновенный откат, превращая развертывание из пугающего события в рутинное, автоматизированное, ежедневное действие.