Deployment-стратегии

Команды сталкиваются с частыми внедрениями новых функций. Это связано как с высокими требованиями заказчиков, так и с необходимостью в исправлении и обновлении сервисов.

Когда мы внедряем микросервисную архитектуру, мы получаем возможность гибкого деплоя, но все стоит определенных вложений и трудозатрат.

Сами по себе микросервисы не дают нам гибкость по умолчанию. Есть сервис, и мы его обновляем, как только получаем положительное заключение от тестирования. Однако в этом подходе мы продолжаем сохранять высокие риски ошибки на проде, потому что могли чего-то не учесть при разработке или забыть что-то протестировать. Нет никакого запасного плана.

Встает вопрос о том, как же минимизировать возможные сбои, утечки и ошибки для пользователей при деплое. В итоге мы приходим к процессу гибкого управления и масштабирования сервисов при раскатке.

Существует три хорошо зарекомендовавших себя стратегии:

1. Blue-Green деплоймент. 2. Canary деплоймент. 3. Комбинированная (Blue-Green + Canary).

1. Blue-Green деплоймент. Суть этой стратегии заключается в поддержании двух полностью независимых окружений: активного («Blue») и нового («Green»).

Когда необходимо внести изменения, новая версия приложения разворачивается в «Green» окружении, в то время как активное окружение «Blue» продолжает работать на пользователей. Таким образом, пользователи не замечают изменений до тех пор, пока новая версия не будет готова к внедрению.

В этой стратегии инфраструктура разбивается на два набора: «Blue» и «Green».

В начале процесса оба набора находятся в одинаковом состоянии — это текущая версия приложения, доступная для пользователей.

Настройка маршрутизации в данной стратегии недорогая и может работать на какую-то часть % от общего входящего трафика. Например, мы перенаправляем 10% на новую версию, затем 20% и так далее. Не разбирая запросы на пользователей, а их на категории. По сути, увеличиваем постепенно долю нагрузки и транзакций на сервис.

Возможность быстрого отката также является значимым преимуществом. Если новая версия приложения не соответствует ожиданиям или появляются критические проблемы, можно быстро переключить трафик на предыдущую версию.

Важно понимать, хранит ли сервис или группа сервисов состояние, а также учитывать архитектуру работы с БД.

Если работаете с сервисом Stateful, то могут быть проблемы с синхронизацией данных или вовсе с их потерей, если те, например, жили в памяти сервиса и при переключении на новую версию часть контекста была разорвана.

Также замечу, что сервисы Stateless, в отличие от Stateful, по умолчанию имеют лучшую масштабируемость, поскольку каждый запрос обрабатывается независимо, и не требуется хранить состояние. Ну и тестировать такие сервисы проще, так как каждый запрос самодостаточен и не зависит от предыдущих. (Продолжение в следующем посте)

Мой канал в тг - https://t.me/carbonka