Чем canary-развёртывание отличается от blue-green? В каком случае вы выберете один подход, а в каком — другой, для backend-сервиса с базой данных?

Короткий ответ

Blue-green разворачивает новую версию параллельно со старой и переключает весь трафик одним разом с быстрым откатом переключением обратно, а canary постепенно направляет небольшую долю трафика на новую версию; canary выбирают, когда важно обнаружить проблему на малой доле пользователей, blue-green — когда нужен быстрый простой откат «всё или ничего».

Как это работает подробнее

blue-green требует двух полных независимых окружений и механизма переключения на уровне роутинга; canary требует более тонкого контроля трафика и системы мониторинга, способной сравнить метрики с baseline.

Пример кода

Пример конфигурацииКопировать

Blue-green:
  blue (v1, 100%) ── green (v2, 0%, прогрет)
  → переключение роутера: blue 0% / green 100%
  → откат за секунды
Canary:
  v1: 95%, v2: 5%
  → мониторинг error rate/latency v2 относительно v1 15 минут
  → 5% → 25% → 100%

Что использовать на практике

• Рекомендация. для сервиса с БД нужно продумать обратную совместимость схемы между старой и новой версией в обоих подходах, так как они одновременно читают/пишут одни таблицы; canary лучше ограничивает blast radius для рискованных изменений, blue-green подходит для хорошо протестированных изменений с важной скоростью релиза.

Подводные камни

• Риск. считать canary автоматически «безопаснее» без настроенных метрик и критериев остановки; забывать, что blue-green не защищает от проблем, вызванных несовместимой миграцией БД, применённой до переключения.