Мысли о дизайне SDK для окрашивания трафика

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

Серия статей технической команды Dewu:

• Даже не раскраска трафика,Вы сказали, что хотите начать микробизнес?
• Практика внедрения среды окрашивания Dewu

введение

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

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

на основераскраска трафика может реализовывать множество функций, таких как логика оттенков серого, сине-зеленое развертывание, изоляция плавательных дорожек; стресс-тест ссылкиждать。

Где болевые точки?

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

1. Высокие затраты ресурсов : Расширение среды часто зависит от многих основных компонентов в дополнение к самому Служить, таких как: Центр регистрации, центр конфигурации, очередь сообщений и т. д.
2. Управление зависимостями ссылок затруднено : Нам необходимо убедиться, что вся ссылка Служить доступна, например: А зависит от Б, Б зависит от С … Наихудший сценарий — полное развертывание.；В то же время, если окружающая среда толькоиспользоватьодин раз,и существует большое количество подобных сред,Ссылку для вызова Служить легко сделать сложной и запутанной.

раскраска трафика

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

1. За каждый Служить в регистрационном центре сохраняется дополнительная отметка по окраске.,Можно понимать как идентификацию версии.
2. На входе в поток добавьте в запрос флаг красителя
3. На базовом уровне структуры,Анализ следов окрашивания,сквозное и Служитьмаршрутизация

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

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

1. Служить можно, следуя метке потока, чтобы применить потокмаршрутизацию к соответствующему окрашенному Служить.
2. Если красильная среда, соответствующая стандарту крашения, не имеет данного параметра Служить, поток перейдет в базовую среду.
3. Если красящая среда добавлена ​​Служить,Не развернуто,Или развернутый процесс Служить зависает,Тогда поток сообщит об ошибке вместо перехода к базовой среде (чтобы предотвратить обнаружение некоторых аномальных проблем).
4. Ожидается, что DB, MQ, Redis и другое промежуточное ПО будут использовать один и тот же набор, чтобы избежать потерь.

С помощью раскраски трафика мы можем достичь следующих целей:

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

Проблема случайной регистрации локального запуска

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

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

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

Уровень приложения в оттенках серого

Для оттенков серого на уровне интерфейса управление оттенками серого в настоящее время выполняется внутри приложения. Но на уровне приложения в настоящее время не существует особенно хорошего способа управления оттенками серого.

Например, существует техническое требование изменить клиент Redis с Lettuce на Jedis. Оттенки серого в этом сценарии находятся на уровне приложения. Текущий метод — опубликовать узел, а затем завершить процесс публикации. в оттенках серого. Он определяется общим количеством экземпляров службы и не может гибко контролироваться.

Если есть раскраска трафика,Вы можете отправить новый узел,Обновите версию этого узла,Например, предыдущая версия была V1.,Тогда недавно выпущенная версия — V2. Прежде всего, версия V1 должна соответствовать всем производственным требованиям.,Можно управлять через шлюз для пересылки потока в версию V2 определенным образом.,Например, белый список пользователей,область,Соотношение пользователей и так далее. Если у вас возникнут какие-либо проблемы, вы можете в любой момент переключить поток обратно на V1.,Очень удобно.

Изящный офлайн-сервис

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

Если он реализован на основе окрашивания, информация об экземпляре (IP:PORT), которая должна быть отключена, будет передана на шлюз через центр конфигурации для обработки окрашивания. Информация о окрашивании будет следовать за запросом по всему каналу, балансируя нагрузку. компонент в приложении и промежуточное программное обеспечение, такое как MQ. Информация о целевом экземпляре, который необходимо перевести в автономный режим, будет фильтроваться таким образом, чтобы к экземпляру, который будет переведен в автономный режим, не поступал трафик.

Ускорение выпусков производственной среды

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

Решить эту проблему со скоростью публикации можно на основе раскраски трафикаосознать Сине-зеленое развертывание. То есть повторное развертывание версии V2 при выпуске,Количество экземпляров в этой версии V2 остается таким же, как и в V1.,Поскольку в этой версии V2 нет потока,Так что никакой зависимости,Все могут публиковать одновременно,Подождите, пока все разошлют,Вы можете распределять поток через шлюз,Сначала раздайте немного потока версии V2 для проверки.,Если проблем нет, можно медленно увеличивать поток.,Затем выпустите версию контейнера V1.

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

Итак, существует ли компромисс, который может повысить эффективность выпуска без увеличения затрат на ресурсы?

• Можно заменить при публикации.,Сначала опубликуйте половину экземпляров,Эта половина экземпляров — наша версия V2.,На момент публикации потока не было,Так что его еще можно публиковать параллельно.

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

Полный стресс-тест ссылки

Полный стресс-тест Ссылки незаменимы для бизнеса в сфере электронной коммерции. Ежегодно проводится N крупных продаж, и для обеспечения стабильности крупных продаж необходимо заранее провести стресс-тестирование. Среди них; стресс-тест Основная идея ссылок — это различие между потоком. Необходимо различать, является ли поток обычным запросом пользователя или потоком стресс-тестирования с платформы стресс-тестирования.

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

За этот контент автор также отвечал во время моей стажировки. трафикаSDK, конкретная идея реализации показана на рисунке ниже:

Ядром всей раскраски трафикаSDK на самом деле является аспект,В масштабируемостидизайн,Я разделил весь SDK для окрашивания на четыре модуля.,Как показано ниже:

1. Центр конфигурации по умолчанию использует Apollo из-за деловых отношений между подразделениями. Чтобы предотвратить связывание, вы можете рассмотреть возможность использования SPI и механизма Provider для выполнения динамического переключения.
2. Модуль генерации ключей оттенков серого и модуль расчета попаданий в оттенках серого отвечают за расчет запроса с идентификацией стресс-теста, получение значения в оттенках серого и сравнение его с порогом оттенков серого в центре конфигурации, чтобы определить, нужно ли высвободить текущий запрос. благодаря этому мы можем легко контролировать соотношение запросов стресс-тестов, поступающих в кеш и поступающих в БД.
3. Модуль анализа запросов стресс-теста отвечает за фильтрацию запросов, несущих флаг стресс-теста, и установку информации стресс-теста в контекст потока.

раскраска трафика Реализация

Здесь решающее значение имеют три момента:

1. Приложения должны иметь концепцию версии
   • Вы можете поместить информацию о версии в файл конфигурации проекта. При запуске проекта эта информация о версии регистрируется в центре регистрации вместе с собственной информацией об экземпляре. Эта информация называется метаданными.
   • При управлении потокоммаршрутизацией соответствующее сопоставление выполняется на основе информации о окрашивании.,Сначала получите список доступных Служить в регистрационном центре.,На основе текущей запрошенной версии,Отфильтровать экземпляры Служить, не соответствующие требованиям.,Балансировка нагрузки среди оставшейся коллекции экземпляров.
2. Полноканальная прозрачная передача цветовой информации
   • Мы можем извлечь уроки из идеи распределенного отслеживания ссылок и генерировать уникальный TraceID на входе каждого запроса. С помощью этого TraceId можно соединить всю ссылку последовательно, точно так же, как TracId необходимо передавать по всей ссылке. Информация о трафике также должна передаваться по всему каналу.
   • Прозрачная передача между приложениями может осуществляться с помощью независимых пакетов агентов или скрыта в базовой структуре. Если HTTP используется для вызовов интерфейса между интрасетями, информация будет передана в заголовке запроса. Если это RPC, используйте для его передачи RpcContext.
   • Для прозрачной передачи внутри приложения вы можете использовать ThreadLocal, чтобы извлечь его из ThreadLocal и продолжить прозрачную передачу при инициировании вызова интерфейса. Но здесь нам нужно обратить внимание на сценарий переключения пула потоков. В этом сценарии нам нужно рассмотреть передаваемый поток-локальный.
3. управление потокоммаршрутизацией
   • Когда поток имеет информацию о метке, оставшаяся работа заключается в том, чтобы направить запрос маршрутизации к правильному экземпляру на основе информации о метке. Если внутренняя структура Spring Cloudсистема,Вы можете управлять маршрутизацией через Ribbon. Если это система Dubbo,Логику маршрутизации можно переформулировать, унаследовав AbstractRouter от Dubbo. Если это разработанная внутри компании структура RPC,Должны быть соответствующие расширения для управления маршрутизацией.

Как прозрачно передавать стандарты трафика

1. Во-первых, метка потока на входном слое потока будет размещена в http. Внутри заголовка
2. После того, как поток достигает шлюза,Способ прозрачной передачи метки потока по ссылке Служить — получить метку красителя из Внутри заголовка.,и начинилThreadLocalПрозрачная передача изнутри вниз。(Здесь необходимо решить проблему прозрачной передачи между потоками)

Как маршрутизация трафика направляется на узлы красителей

Рассмотрим его в двух частях:

• Вызов RPC, после получения метки окрашивания, как найти узел окрашивания? Здесь необходимо решить, как выявить окрашенные узлы
• Сообщения MQ, как производитель отправляет сообщения с цветными тегами и как потребитель обрабатывает сообщения с цветовыми тегами?

Давайте сначала посмотрим на конкретную реализацию двух вышеупомянутых проблем в Dewu:

Регистрация услуги – выявление окрашенных узлов:

1. Во-первых, когда будет создана среда окрашивания, будет определен масштаб окрашивания.
2. При добавлении развертывания Служить в эту среду окраски метка цвета будет по умолчанию вставлена ​​в переменную среды COLORING_ENV.
3. Страница конфигурации выпуска контейнера автоматически добавит переменную COLORING_ENV.
4. До сих пор,Служить уже может прочитать стандартную переменную среды COLORING_ENV при запуске.,Следующий шаг зависит от того, как центр регистрации распознает окрашенные узлы.
5. Прежде всего, при добавлении Служита в красящую среду.,Служить добавит узел в поле крашения регистрационного центра,Указывает на наличие узла Служить в данной красильной среде.
6. Основная проблема, решаемая красильным полем: если красильный узел зависает,Поток среды крашения должен определять, должна ли среда крашения иметь узлы крашения.,Если да, сообщите об ошибке,Если нет, мы перейдем к базовой среде. Избегайте проблем тестирования, которые остаются нераскрытыми.
7. Во-вторых, при регистрации в Служить,Служить Информация об узле и регистрация метода будут иметь цветные метки.< coloring_env >
8. До сих пор,Центр регистрации может идентифицировать узлы окрашивания на основе этикеток окрашивания.,Бизнес Служить может быть окрашен потокмаршрутизацией на основе отметки крашения в Trace, совмещенной с узлом окраски центра регистрации.

Преобразование MQ – идентификация и обработка сообщений MQ:

Основное решение MQ заключается в том, что сообщения, отправляемые производителем сообщений среды окрашивания, потребляются только потребителями среды окрашивания. Если среда окрашивания не имеет узла-потребителя, он будет потребляться потребителями базы. среда.

Здесь обсуждались два подхода:

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

Техническая группа Dewu выбрала второй вариант. Ниже приводится подробное описание второго варианта.

Как показано на рисунке:

1. ServiceB_Color1 автоматически зарегистрирует группу потребителей GID_Color1_Topic и прослушает Topic_A. Среды Color2 и Color3 одинаковы.
2. Сообщение с цветом Color1 создается ServiceA_Color1 и потребляется ServiceB_Color1.
3. Сообщения с Color2 создаются ServiceA_Color2 и потребляются ServiceB, поскольку ServiceB не имеет узлов в среде окрашивания Color2.
4. Сообщение с Color3 не имеет узла ServiceA_Color3 из-за среды окрашивания Color3.,Тогда поток с Color3 попадет в базовую среду ServiceS.,
5. В это время ServiceA создаст сообщение с Color3, и это сообщение будет использовано ServiceB_Color3.

На входах для подачи красителя имеются этикетки с красителем.

После решения задачи прозрачной передачи тегов красителя и логической обработки тегов красителя остается, как донести теги красителя до инициатора трафика. По сути, это вставить теги красителя в поле x-infr-flowtype. заголовок.

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

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

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

краткое содержание

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

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