Опишите, за счёт чего blue-green-развёртывание позволяет переключать трафик между версиями приложения.
Blue-green-развёртывание поддерживает два отдельных окружения: текущее рабочее и подготовленное для новой версии. После проверки новой версии единая точка маршрутизации переключает трафик с прежнего окружения на новое, поэтому откат выполняется обратным переключением.
Переключение обычно выполняется на уровне балансировщика, прокси или другого компонента маршрутизации. Это не означает мгновенное завершение уже установленных соединений и не устраняет задержки DNS-кэширования, если переключение сделано через DNS.
Подход появился как ответ на риск обновления приложения непосредственно в рабочем окружении. При последовательной замене экземпляров старая и новая версии некоторое время сосуществуют, а ошибка может проявляться уже во время частичного обновления.
Blue-green переносит основную проверку новой версии до переключения пользовательского трафика. Цена этого подхода — необходимость временно содержать два полноценных окружения и заранее продумывать совместимость приложения с данными.
Новая версия может успешно пройти проверку запуска, но обнаружить ошибки только под реальной нагрузкой: некорректные тайм-ауты, несовместимость с внешней зависимостью, проблемы производительности или ошибочные настройки маршрутизации.
Если обновлять единственное рабочее окружение по месту, откат может потребовать повторного развёртывания, восстановления конфигурации и ожидания готовности экземпляров. Кроме того, часть пользователей уже может попасть на новую версию, а часть — продолжить работать со старой.
Сначала создают green-окружение с новой версией рядом с текущим blue-окружением. Его проверяют отдельными health check, функциональными тестами, тестовыми запросами и, при необходимости, ограниченным внутренним трафиком без изменения основного маршрута пользователей.
После подтверждения готовности изменяют правило маршрутизации на общем входном компоненте. Балансировщик начинает направлять новые запросы в green, а blue сохраняют некоторое время для быстрого отката и завершения уже принятых операций.
Ключевой механизм — наличие единой точки переключения, а не само существование двух наборов серверов. Если маршрутизация выполняется через DNS, переключение ограничено TTL и кэшами клиентов; через балансировщик или прокси изменение обычно контролируется точнее, но уже установленные долгоживущие соединения могут продолжить обслуживаться старым окружением.
Главное ограничение связано с состоянием. Сессии, очереди, кэш и загружаемые файлы не должны бездумно храниться только внутри одного окружения. Обычно их выносят во внешние отказоустойчивые хранилища либо обеспечивают совместимость обеих версий с общим форматом данных.
Особенно опасны необратимые миграции схемы базы данных. Безопаснее применять поэтапную схему: сначала добавить новые поля или таблицы, совместимые со старой версией, затем переключить приложение, и только после подтверждения результата удалять устаревшие элементы.
Компромисс blue-green — более простой и быстрый откат в обмен на повышенные инфраструктурные затраты. Подход хорошо подходит для приложений, где важны предсказуемое переключение и минимальное время отката, но может быть дорогим для ресурсоёмких систем.
После выпуска новой версии API команда хотела исключить длительный простой. Рассматривались rolling update, canary-релиз и blue-green-развёртывание. Rolling update экономил ресурсы, но временно смешивал версии и усложнял анализ ошибок; canary позволял измерять поведение на части трафика, однако требовал корректного распределения запросов и достаточно быстрого обнаружения проблем.
Выбрали blue-green: новую версию развернули в отдельной группе экземпляров, прогнали проверки совместимости и переключили маршрут на уровне балансировщика. Старая группа оставалась доступной для отката, но её не удаляли до завершения уже начатых операций и подтверждения метрик.
Решение дало быстрый откат при ошибке приложения, однако выявило необходимость внешнего хранилища сессий и совместимой миграции базы данных. После их внедрения переключение стало предсказуемым, а стоимость временного удвоения вычислительных ресурсов сочли приемлемой.
Нет. Health check обычно подтверждает доступность ограниченного набора функций, но не гарантирует корректность под реальной нагрузкой, совместимость данных, работу фоновых задач и поведение внешних интеграций. Поэтому нужны проверки бизнес-сценариев, наблюдение за метриками после переключения и заранее определённые критерии отката.
Новая версия могла изменить состояние базы данных, отправить сообщения во внешнюю систему или записать данные в формате, который старая версия не понимает. Возврат трафика исправит маршрут, но не отменит уже выполненные побочные эффекты. Поэтому откат приложения должен быть согласован с версионированием схем, контрактами сообщений и идемпотентностью операций.
Они могут остаться привязанными к blue до закрытия соединения, даже если новые запросы уже направляются в green. Для корректного перехода учитывают время жизни соединений, используют механизм draining на старом окружении и проверяют совместимость протоколов между клиентами и обеими версиями. При наличии WebSocket или длительных потоковых запросов переключение нельзя считать мгновенным.