Развертывание в оттенках серого, непрерывное развертывание и сине-зеленое развертывание

предисловие

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

Стратегия обновления версии

Функциональный переключатель

Встроенная функция переключения логики приложения, отключив переключатель старой и новой логики, чтобы определить выполнение без поддержки механизма маршрутизации производительности, разработчики могут гибко управлять программой. Такой подход требует поддержки центра динамической конфигурации, в отрасли есть относительно законченные решения, такие как Apollo, spring cloud config и так далее. Конкретные способы, подобные этому:

if Config.SwitchOn {
    //new logic
} else {
    //old logic
}

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

Развертывание в оттенках серого/развертывание Canary

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

скользящее развертывание

Последовательное развертывание больше похоже на расширенную версию развертывания в градациях серого.После того как новая версия пройдет проверку в градациях серого, мы постепенно увеличиваем объем развертывания в градациях серого, пока все серверы не будут обновлены до новой версии. В процессе развёртывания необходимо поддерживать плавное переключение, то есть сначала удалять сервер из списка балансировки нагрузки, кроме того, скользящий релиз обычно делается партиями, например 10% на первую партию, 30% на вторую. вторая партия, 100% для третьей партии и т.д.

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

сине-зеленое развертывание

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

Для достижения сине-зеленого развертывания требуется несколько дополнительных опор:

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

Преимущества сине-зеленого развертывания:

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

Недостатки сине-зеленого развертывания:

Недостаточное использование ресурсов, так как общие ресурсы простаивают
После того, как переключение трафика завершено, в бэкенде может остаться не обработанная бизнес-логика, и потребуются дополнительные механизмы. Вы можете убедиться, что две среды могут обрабатывать транзакции одновременно во время проектирования, поэтому вам не нужно учитывать эту проблему; вы также можете установить службу в «режим только для чтения» перед переключением трафика, а затем вернуться в « режим чтения-записи" после переключения трафика. режим" и т.д.
Старая и новая версии могут включать изменения в структуре таблиц базы данных, и в этом случае нам потребуются дополнительные меры совместимости базы данных. При возникновении проблем при переходе на новую среду возможны расхождения данных из-за новой логики. Для решения этой проблемы можно разделить рефакторинг базы данных и выпуск приложения: сначала выполняется рефакторинг базы данных, чтобы обеспечить совместимость между старой и новой версиями, а выпуск приложения выполняется после завершения рефакторинга базы данных.

другие концепции

Комбинация из одного сервера Двойная группа серверов

Упомянутое ранее сине-зеленое развертывание требует двух сред, что фактически эквивалентно группе из двух серверов. Развертывания с двумя оттенками серого и скользящие развертывания также можно использовать для групп с двумя серверами. Например, развертывание оттенков серого в двухсерверной группе не является универсальным при переключении между синей и зеленой средами, а сначала переключает небольшую часть на новую среду, а затем полностью переключается на новую среду после прохождение проверки; при прокатном развертывании в двухсерверной группе делится на два пакетных перехода в новую среду.

группа серверов

При делении группы серверов ее можно разделить на разные степени: по центру обработки данных, например, компьютерный зал А — это группа, а компьютерный зал Б — это группа; по логическому группированию, например, половина машин в машинных залах A и B разделены на группу, оставшаяся половина машин сгруппирована вместе. Независимо от группировки, при передаче запроса между службами необходимо указать групповой идентификатор определенной машины, например, метаданные экземпляра службы в реестре должны иметь такой идентификатор, как «group=group1», чтобы клиент или прокси-узел могли идентифицировать только группу, в которой находится экземпляр сервера, при маршрутизации.

механизм маршрутизации

Различные стратегии развертывания, упомянутые выше, на самом деле требуют различных уровней поддержки механизма маршрутизации. Для служб HTTP прокси-узлы могут использоваться для распределения между различными нижестоящими узлами в процессе разрешения доменного имени; службам RPC необходимо реализовать соответствующий механизм маршрутизации.