фон

Aliware

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

02

Стратегия выпуска

Aliware

по отрасли широко применяется для реализации стратегии выпуска, включая зеленый выпуск, A/B-тестирование и канареечный выпуск.

01

сине-зеленый релиз

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

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

Как показано на рисунке, старая версия определенного сервиса — v1, а новая версия v2 развертывается избыточно. При обновлении версии весь существующий трафик будет переключен на новую версию v2.

Если в новой версии v2 есть программные ошибки или сбои, вы можете быстро вернуться к старой версии v1.

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

1. Развертывание имеет простую структуру и удобное управление и обслуживание;

2. Процесс обновления услуги прост и имеет короткий цикл.

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

1. Избыточность ресурсов требует развертывания двух наборов производственных сред;

2. Провал новой версии имеет большое влияние.

02

А/Б тестирование

Оно меркнет в сравнении метод переключения релизизпоток, А/Б На основе запроса пользователя метаинформация будет транслировать маршрутизацию до новой версии, которая представляет собой оттенки серого. Стратегия на основе содержимого запроса соответствуетиз выпуск. Только при соблюдении определенных правил запрос будет перенаправлен в новую версию. Http Header и Печенье. на основе Http Header Примеры таких способов, как User-Agent Значение Android запрос (из запроса Android) может получить доступ к новой версии, другие системы по-прежнему имеют доступ к старой версии на основе Cookie Пример подхода, Cookie Обычно содержит информацию о пользователе с бизнес-семантикой, например, обычные пользователи могут получить доступ к новым версиям, VIP Пользователи по-прежнему имеют доступ к старой версии.

Как показано на рисунке, текущая версия службы — v1, и теперь в сети доступна новая версия v2. Есть надежда, что пользователи Android смогут опробовать новые возможности, а пользователи других систем останутся неизменными.

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

А/Б тестированиеизпреимущество：

1. Новая версия Служить может быть предоставлена ​​для конкретного запроса или пользователя, и объем сбоев новой версии будет небольшим;

2. Необходимо создать полноценную платформу мониторинга для сравнения различий в статусе запроса между различными версиями.

А/Б тестированиеизнедостаток：

1. Избыточность ресурсов все еще существует, поскольку требуемую мощность невозможно точно оценить;

2. Цикл выпуска длительный.

03

Канарский релиз

существоватьсине-зеленый релизсередина, в связи с общим изменением существующихпоток, необходимо клонировать среду для новой версии в соответствии с размером оригинальной Служить, занимаемой машиной, что эквивалентно требованию в 1 раз большего количества машинных ресурсов оригинала. существовать А/Б До тех пор, пока мы можем оценить размер середина, соответствующего конкретным правилам, мы можем по мере необходимости выделять дополнительные машинные ресурсы для новой версии. По сравнению с первыми двумя Стратегия выпуска,Канарский релизисдумал перенаправить небольшое количество запросов на новую версию.,Поэтому для развертывания новой версии Служить требуется лишь очень небольшое количество машин. Убедившись, что новая версия соответствует ожиданиям,Постепенно корректируйте весовое соотношение потока,Заставить поток медленно мигрировать со старой версии на новую версию,В течение периода пропорция может быть установлена ​​в соответствии с,Расширение новой версии Служить,При этом старая версия Служить будет уменьшена в размере.,Максимизируйте использование базовых ресурсов.

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

Канарский релизиз Преимущества:

1. Направляйте трафик на новую версию без разбора и пропорционально, и сбой новой версии окажет небольшое влияние;

2. В период выпуска новая версия постепенно расширяется, а старая версия одновременно сокращается, что приводит к высокой загрузке ресурсов.

Недостатки Канарского релиза:

1. Трафик направляется на новую версию без разбора, что может повлиять на опыт важных пользователей;

2. Цикл выпуска длительный.

03

упражняться

Aliware

Далее мы будем использовать платформу эксплуатации и обслуживания контейнеров Alibaba Cloud. ACK а также MSE Облачный Шлюз Знакомство с тремя вышеперечисленными типами Стратегии выпуска провести упражнения. Здесь мы используем простейшую бизнес-структуру, то есть Облачный бизнес. шлюз, бэкенд Служить (ответ на середина возвращает информацию о текущей версии) и регистрация середина heart. Регистрация середина сердце определяет структуру бизнеса середина Служить метод открытия, мы будем соответственно K8s Контейнерный сервиси Nacos Два механизма обнаружения Служить приходят разные из Стратегия выпуска。

01

Предварительные условия

• Создана платформа для эксплуатации и обслуживания контейнеров Alibaba Cloud ACK.
• Создан собственный облачный шлюз MSE.
• Созданный MSE зарегистрироватьсясередина Сердце Накос (Служить обнаружил Nacos когда это необходимо)

02

Метод обнаружения службы: служба контейнера K8s.

В этом примере мы используем собственный метод обнаружения служб K8s, который заключается в регистрации серверной службы в CoreDNS через ресурс декларативного API службы. Серверная служба в примере предоставляет интерфейс/версию для запроса текущей версии, а текущая версия — v1. Собственный облачный шлюз глубоко интегрирован с ACK и может динамически получать служебную информацию из кластера ACK в режиме реального времени, что упрощает предоставление серверной службы внешним пользователям через собственный облачный шлюз.

Структура бизнеса следующая:

1. Развертывание

Примените следующие ресурсы (ServiceиDeployment) к ACK Кластер, завершите выпуск серверной части. Текущая версия приложения: v1。

apiVersion: v1
kind: Service
metadata:
  name: httpbin
spec:
  ports:
  - port: 8080
    protocol: TCP
  selector:
    app: httpbin
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: httpbin-v1
spec:
  replicas: 3
  selector:
    matchLabels:
      app: httpbin
      version: v1
  template:
    metadata:
      labels:
        app: httpbin
        version: v1
    spec:
      containers:
      - image: specialyang/spring-cloud-httpbin-k8s:v1
        imagePullPolicy: Always
        name: spring-cloud-httpbin-k8s
        ports:
        - containerPort: 8080

существовать Облачный шлюзиз Служитьуправлять->источникуправлятьсередина,Добавьте целевой кластер ACK.

Импортируйте службу httpbin, чтобы она была доступна собственному облачному шлюзу в управлении службами.

Добавьте версию службы v1 в конфигурацию политики службы httpbin. Обратите внимание, что вам необходимо выбрать соответствующую метку, чтобы отфильтровать узлы версии v1. Поскольку в настоящее время мы развернули только версию v1, количество узлов v1. версия составляет 100% от общего количества экземпляров.

Создайте правило маршрутизации для службы в управлении маршрутизацией, чтобы предоставить доступ к службе внешним пользователям. Путь API, предоставляемый службой httpbin, — /version, и запрос перенаправляется в версию v1 службы httpbin.

Выполните следующий сценарий, чтобы проверить результат ответа на запрос.

for i in {1..10}; do curl "${GATEWAY_EXTERNAL_IP}/version"; echo "";  done
version: v1
version: v1
version: v1
version: v1
version: v1
version: v1
version: v1
version: v1
version: v1
version: v1

2. Развертывание сине-зеленых сил

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

Используйте ресурсы декларативного API K8s для развертывания новой версии v2 службы httpbin. Количество реплик также равно 3.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: httpbin-v2
spec:
  replicas: 3
  selector:
    matchLabels:
      app: httpbin
      version: v2
  template:
    metadata:
      labels:
        app: httpbin
        version: v2
    spec:
      containers:
      - image: specialyang/spring-cloud-httpbin-k8s:v2
        imagePullPolicy: Always
        name: spring-cloud-httpbin-k8s
        ports:
        - containerPort: 8080

существовать httpbin Добавьте версию службы в конфигурацию политики службы. v2, обратите внимание, что для фильтрации необходимо выбрать соответствующий тег v2 Версия из узла, кластера середина теперь существует v1 и v2 Количество узлов версии одинаковое, поэтому каждый занимает 50%。

сейчассуществовать,давайте начнемиспользоватьсине-зеленый релизиздумал будет транслироваться из v1 Переключиться на v2, вам нужно только изменить целевую службу в правиле маршрутизации, созданном выше.

Выполните следующий сценарий, чтобы проверить результат ответа на запрос.

for i in {1..10}; do curl "${GATEWAY_EXTERNAL_IP}/version"; echo "";  done
version: v2
version: v2
version: v2
version: v2
version: v2
version: v2
version: v2
version: v2
version: v2
version: v2

Сейчас существуют мы нашли доступ api ресурсы/версия запросизпоток весь удален из v1 переключиться на v2。

3. А/Б-тестирование

А/Б Обновление будет транслировать маршрутизацию на новую версию на основе запроса пользователя из метаинформации. Другими словами, он может динамически маршрутизироваться на основе содержимого запроса. Например, мы хотим Пользовательский агент Значение запроса Android (из запроса Android) имеет доступ к новым версиям,Другие системы по-прежнему имеют доступ к старой версии.

мы все ещеиспользоватьвышеупражнятьсясерединаразвертыватьиз httpbin из v1,v2 из развертывание. Кроме того, необходимо создать два правила маршрутизации:

• соответствовать path для/версии запросдоступ Служить Версия v1
• соответствовать path для/версии,и User-Agent В голове содержится Android запросдоступ Служить Версия v2

Обратите внимание по сравнению с version Правила маршрутизации, версия-v2 Правилу измаршрутизации середина необходимо добавить заголовок запроса, соответствующий правилу.

Протестировано с помощью следующего скрипта A/B test из Эффект。

// user агентсередина не содержит android
curl ${GATEWAY_EXTERNAL_IP}/version
version: v1

// user агентсерединасодержит android
curl -H "User-Agent: Mozilla/5.0 (Linux; Android 4.0.3)" ${GATEWAY_EXTERNAL_IP}/version
version: v2

Видно, что текущий запрос будет перенаправлен в поток в соответствии с источником операционной системы.

4. Канарский релиз

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

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

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

Его середина, цель Служить должна настроить два пункта назначения, httpbin из версии v1 и v2,И установите соответствующее соотношение изпоток.

Протестировано с помощью следующего скрипта Канарский релизиз Эффект。

for i in {1..10}; do curl "${GATEWAY_EXTERNAL_IP}/version"; echo "";  done
version: v1
version: v1
version: v1
version: v1
version: v1
version: v2
version: v1
version: v2
version: v1
version: v1

существующие результаты теста середина выше, можно найти 10 запросов, есть 2 Один из них — доступ к новой версии v2, его коэффициент потока соответствует ожиданиям 8:2。

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

03

Метод обнаружения службы: центр регистрации Nacos.

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

Для этого бизнес-сценария мы приведем дополнительный пример использования Nacos Как сделать сине-зеленый для Служить при регистрации сердца середина релиз、А/Б тестированиеи Канарский релиз. Пример серединаиз бэкенда Служить предоставляет запрос текущей версии интерфейса/версии, и текущая версия в1. Глубокая интеграция облачного шлюза MSE Nacos Центр регистрации, который может динамически загружать с Nacos Получите информацию о службе из экземпляра, чтобы облегчить доступ к внутренней службе внешним пользователям через собственный облачный шлюз.

Структура бизнеса следующая:

01

развертывать

Примените следующие ресурсы (развертывание) к ACK Кластер, завершите серверную часть Служитьизразвернуть и опубликовать Служить в Nacos Центр регистрации, текущая версия приложения: в1. Необходимо отметить следующие моменты:

1. yaml Переменную середины ресурса ${NACOS_SERVER_ADDRESS} необходимо заменить на вашу MSE Nacos Адрес, если и шлюз существует один VPC, то достаточно имени домена интрасети, в противном случае вам необходимо настроить имя домена общедоступной сети;

2、существовать K8s Service Обнаружение служб, Pod середина Labels Информацию можно рассматривать как информацию метаданных узла. и существовать Nacos Регистрация середина сердце середина, узел метаданных зависит от Служить информацией, внесенной при регистрации. существовать Spring Cloud Фреймворк середина, через переменные среды spring.cloud.nacos.discovery.metadata.xxx Добавляйте метаданные к узлам без вмешательства. В этом примере середина мы используем version Как знак версии он используется для различения узлов разных версий. Поэтому вам необходимо добавить переменные среды в бизнес-контейнер. spring.cloud.nacos.discovery.metadata.version=v1。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: httpbin-v1
spec:
  replicas: 3
  selector:
    matchLabels:
      app: httpbin
  template:
    metadata:
      labels:
        app: httpbin
    spec:
      containers:
      - image: specialyang/spring-cloud-httpbin-nacos:v1
        imagePullPolicy: Always
        name: spring-cloud-httpbin-nacos
        ports:
        - containerPort: 8080
        env:
        - name: spring.cloud.nacos.discovery.server-addr
          value: ${NACOS_SERVER_ADDRESS}
        - name: spring.cloud.nacos.discovery.metadata.version
          value: v1

существовать Облачный шлюзиз Служитьуправлять->источникуправлятьсередина,Добавить целевую регистрацию MSE Nacosсередина Сердцекластер.

существовать Служитьуправлятьсередина Импорт должен подвергаться Облачный шлюзиз Служить httpbin, обратите внимание на выбор источника сервиса MSE Nacos зарегистрироватьсясередина Сердце。

и K8s Service Служить найти из примера того же существующего, конфигурация политики середина добавить Служить версию v1, имя тега и значение тега можно выбрать в качестве нашего существования. httpbin Служить Добавить метаданные при регистрации версия = v1. Затем настройте сопоставление маршрутов путь/версия запрос Переслать httpbin Служитьиз v1 Версия.

Выполните следующий сценарий, чтобы проверить результат ответа на запрос.

for i in {1..10}; do curl "${GATEWAY_EXTERNAL_IP}/version"; echo "";  done
version: v1
version: v1
version: v1
version: v1
version: v1
version: v1
version: v1
version: v1
version: v1
version: v1

02

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

Его Стратегия производства показана на рисунке ниже:

развертывать httpbin Служитьиз новой версии v2, обратите внимание на то, чтобы регистрационная информация соответствовала приведенной выше, и добавьте переменные среды для бизнес-контейнера. Spring.cloud.nacos.discovery.metadata.version=v2, при запуске бизнес-приложения будет указано Nacos Зарегистрируйтесь Служить и переносить определяемую пользователем метаданную. Облачный Шлюз может использовать эту информацию метаданных для различения разных узлов.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: httpbin-v2
spec:
  replicas: 3
  selector:
    matchLabels:
      app: httpbin
  template:
    metadata:
      labels:
        app: httpbin
    spec:
      containers:
      - image: specialyang/spring-cloud-httpbin-nacos:v2
        imagePullPolicy: Always
        name: spring-cloud-httpbin-nacos
        ports:
        - containerPort: 8080
        env:
        - name: spring.cloud.nacos.discovery.server-addr
          value: ${NACOS_SERVER_ADDRESS}
        - name: spring.cloud.nacos.discovery.metadata.version
          value: v2

и K8s Service из примера серединасине-зеленый релиз работает одинаково,существовать httpbin Добавьте версию службы в конфигурацию политики службы. v2, затем правило маршрутизации серединаиз target Служить httpbin из v1 Версия изменена на v2 Версия После успешного выпуска проверьте, все ли результаты запроса. version: v2。

3. А/Б-тестирование

Его Стратегия производства показана на рисунке ниже:

Мы также используем предыдущий пример User-Agent. Значение Android запрос (из запроса системы Android) может получить доступ к новой версии, другие системы по-прежнему имеют доступ к старой версии. Включая правила изменения операций, методы проверки и. K8s Service из Пример последовательный.

4. Канарский релиз

Его Стратегия производства показана на рисунке ниже:

Аналогичным образом, с использованием правил измаршрутизации операций и методов проверки. K8s Service из Пример последовательный.

04

Подвести итог

Aliware

Эта статья об общих из Стратегиях. выпуска дал краткое введение и принципиальный анализ, а также объяснил каждую стратегию с картинками и текстами. Подробно обсуждался выпуск, Подвести Итог таков:

• сине-зеленый релиз: Простое понимание — переключение потока,По идее горячего приготовления,избыточностьразвертывать Служитьновый Версия.
• А/Б тестирование: Проще говоря, запросить потокмаршрутизацию для Служитьиз разных версий на основе содержимого запроса (заголовок, файл cookie).
• Канарский релиз: тип коэффициента, основанный на потоке из Стратегия выпуск, развертывание одной или небольшой партии новой версии из Служить, которая составит небольшое количество (напр. 1%）запрос Дренажновый Версия,Постепенно увеличивайте потокпропорция,Пока все пользователи не перейдут на новую версию.

Облачный Шлюз служит управляемым входом в ваш изпоток, предоставляет широкие возможности управления изпотоками и поддерживает различные методы обнаружения, такие как K8s Service、Nacos、Eurake、ECS и доменное имя и поддерживает Служить версию а в единой модели также возможности публикации в оттенках серого. существуют и зупражняютсясередина, вы можете найти два метода обнаружения Служить Только расположение метаданных отличается, но Служить управление версиями. правила такжемаршрутизации, серединаиз всех моделей выпуска в оттенках серого согласованы,Вы можете легко научиться публиковать в оттенках серого для различных методов открытия.,Убедитесь, что процесс обновления версии проходит гладко и без потерь.