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

Архитектура Solomon_Xiao GedanС вами, "Дан Дэн" Как быть более элегантной службы с конвейера, с севера на юг через схему планирования потока вещей.

Сталкиваетесь ли вы со следующими проблемами во время обычного процесса публикации:

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

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

Анализ сценария

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

Службы B и C регистрируют службы в реестре, а службы A и B обнаруживают службы для вызова из реестра;
Бизнес-трафик направляется из балансировки нагрузки в службу A, а проверка работоспособности экземпляра службы A настраивается на SLB. Когда экземпляр службы A не работает, соответствующий экземпляр удаляется из SLB, служба A вызывает службу B. , и служба B вызывает службу C. ;

На приведенном выше рисунке показаны два типа трафика.

Движение Север-Юг:
- То есть бизнес-трафик перенаправляется на внутренний сервер через SLB, например, путь вызова бизнес-трафика -> SLB -> A
Движение Восток-Запад:
- Трафик, вызванный через обнаружение службы центра обслуживания реестра, например, путь вызова A -> B

Движение Север-Юг

Проблема с транспортом север-юг

Когда служба A освобождается, после того как экземпляр службы A1 не работает, SLB обнаруживает, что служба A1 находится в автономном режиме в соответствии с проверкой работоспособности, а затем удаляет экземпляр из SLB. Экземпляр A1 зависит от проверки работоспособности SLB, которая будет удалена из SLB, что обычно занимает от нескольких секунд до десятков секунд.Во время этого процесса, если на SLB поступает непрерывный трафик, некоторые запросы будут по-прежнему направляться на экземпляр A1, в результате запрос не выполнен;

Как обеспечить, чтобы в процессе публикации службы А трафик, проходящий через SLB, не сообщал об ошибках? Давайте посмотрим, как это делает SAE.

Элегантный план модернизации для движения с севера на юг

Причина сбоя запроса заключается в том, что экземпляр серверной службы сначала останавливается, а затем удаляется из SLB. Можем ли мы сначала удалить экземпляр службы из SLB, а затем обновить экземпляр?

Согласно этой идее, SAE предоставляет решение, основанное на возможностях сервиса K8S.

Когда пользователь связывает SLB через SAE, SAE создает сервисный ресурс в кластере и связывает экземпляр и службу приложения, а компонент CCM будет отвечать за покупку SLB, создание группы SLB Virtual Server и ставит Экземпляр приложения Связанный ENI NIC добавляет к группе виртуальной серверы, пользователи могут получить доступ к экземплянам приложений через SLB;
Когда приложение будет выпущено, CCM сначала удалит ENI, соответствующий экземпляру, из группы виртуальных серверов, а затем обновит экземпляр, чтобы гарантировать, что трафик не будет потерян.

Это схема гарантии SAE для трафика север-юг в процессе обновления приложения.

восточно-западный трафик

Проблема потока Восток-Запад

В традиционном процессе публикации поставщик услуг останавливается и перезапускается, а процесс восприятия потребителем услуг остановки узла поставщика услуг выглядит следующим образом:

Прежде чем услуга будет выпущена, потребитель звонит поставщику услуг в соответствии с правилами балансировки нагрузки, и бизнес идет нормально.
Поставщик услуг B должен выпустить новую версию, сначала поработать на одном из узлов, сначала остановить процесс Java.
Процесс остановки службы делится на активный выход и пассивный выход, активный выход происходит в квазиреальном времени, а время пассивного выхода определяется разными центрами регистрации, в худшем случае это займет 1 минуту.
- Если приложение остановлено в обычном режиме, хук Shutdown Hook в Spring Cloud и среде Dubbo может выполняться в обычном режиме, и на время, отнимающее этот шаг, можно не обращать внимания.
- Если приложение остановлено аварийно, например, с помощью команды kill -9 для непосредственной остановки или при построении образа Docker, приложение Java не является процессом № 1, и сигнал уничтожения не передается приложению. В этом случае поставщик услуг не возьмет на себя инициативу по отмене узла службы, а будет пассивно удален реестром через определенный период времени из-за тайм-аута пульса.
Реестр услуг информирует потребителя о том, что один из узлов поставщика услуг отключился. Существует два метода push и polling.Push можно рассматривать как квази-реальное время.Время опроса определяется интервалом опроса потребителя услуги.В худшем случае это занимает 1 минуту.
Потребитель услуг обновляет список услуг и понимает, что поставщик услуг отключился для узла.Этот шаг не существует для платформы Dubbo, но время обновления ленты по умолчанию, компонента балансировки нагрузки Spring Cloud, составляет 30 секунд. что требуется в худшем случае. Занимает 30 секунд.
Потребители услуг больше не вызывают узлы, которые перешли в автономный режим.

От шага 2 до шага 6 Eureka занимает 2 минуты в худшем случае, а Nacos — 50 секунд в худшем случае. В этот период времени могут быть проблемы с запросом, поэтому при публикации будут возникать различные ошибки, что также повлияет на пользовательский опыт.После публикации грязные данные, которые исполняются наполовину, нуждаются в исправлении. В итоге приходилось каждый раз устраивать выпуск в два-три часа ночи.

Элегантный план обновления для трафика с востока на запад

В традиционном процессе публикации у клиента есть период отчета об ошибках вызова службы, поскольку клиент вовремя не воспринимает экземпляр сервера в автономном режиме. В традиционном процессе публикации центр регистрации в основном используется для уведомления потребителей о необходимости обновления списка поставщиков услуг.Можно ли обойти центр регистрации, чтобы поставщик услуг уведомлял потребителей услуг напрямую? Ответ — да, мы в основном делаем две вещи:

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

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

Пакетная публикация и публикация в оттенках серого

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

Давайте сначала представим выпуск в оттенках серого. Приложение содержит 10 экземпляров приложения. Версия развертывания каждого экземпляра приложения — версия 1. Теперь каждый экземпляр приложения необходимо обновить до версии 2.

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

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

твойподобноа такжеСфокусируйся надаАрхитектура Solomon_Xiao GedanПродолжение мотивации.

🏆 Технический спецвыпуск 7 | Все может быть бессерверным