Эта статья составлена на основе одноименного выступления сообщества разработчиков движка вулкана Meetup и в основном знакомит с технологией управления трафиком сервисной сетки в сценарии крупномасштабного трафика гала-концерта Douyin Spring Festival в красных конвертах.
Предыстория и проблемы
Проект красного конверта CCTV Spring Festival Gala в 2021 году оставит очень мало времени для студентов, изучающих бизнес-исследования и разработки, которые должны завершить разработку, тестирование и запуск соответствующих кодов в течение ограниченного времени.
Во всем проекте задействованы разные технические команды и, естественно, множество микросервисов. Эти микросервисы имеют свои собственные стеки языковых технологий, включая Go, C++, Java, Python, Node и т. д., и работают в очень сложных средах, таких как контейнеры, виртуальные машины, физические машины и т. д. Этим микросервисам может потребоваться использовать разные стратегии управления трафиком, чтобы обеспечить стабильность на разных этапах гала-концерта Douyin Spring Festival Gala.
Поэтому инфраструктура должна обеспечивать унифицированные возможности управления трафиком для этих микросервисов от разных команд и написанных на разных языках.
Работа с традиционной микросервисной архитектурой
Говоря о микросервисах, давайте сначала посмотрим, как традиционная микросервисная архитектура решает эти проблемы. С непрерывным развитием корпоративных организаций бизнес-логика продуктов становится все более сложной.Чтобы повысить итеративную эффективность продуктов, серверная архитектура программного обеспечения для Интернета постепенно превратилась из одной большой службы в распределенную микрослужбу. По сравнению с монолитной архитектурой распределенная архитектура менее стабильна и менее наблюдаема.
Чтобы улучшить эти моменты, нам нужно реализовать множество функций на платформе микросервиса. Например:
- Микросервисы должны вызывать друг друга для выполнения функций, реализованных исходным одним большим сервисом, который включает связанныеТелекоммуникации, и сетевое общениеСериализация запроса, десериализация ответа.
- Взаимные вызовы между службами включаютобнаружение службы.
- Для распределенных архитектур могут потребоваться различныеПолитика управления трафикомДля обеспечения стабильности взаимных звонков между сервисами.
- Архитектура микросервиса также должна улучшить возможности наблюдения, включая ведение журнала, мониторинг, отслеживание и т. д.
Реализуя эти функции, микросервисная архитектура также может решить некоторые из проблем, упомянутых выше. Но есть некоторые проблемы с самими микросервисами:
- Реализовать различные функции в многоязычной среде микросервисов, включаяЗатраты на разработку и эксплуатацию очень высоки;
- Для доставки или отзыва версии некоторых новых функций микросервисной инфраструктуры требуется сотрудничество студентов, занимающихся исследованиями и разработками, для внесения соответствующих изменений и публикации в Интернете, что приведет к сбою микросервисной инфраструктуры.Длительная фрагментация и неконтролируемая версияФеномен.
Так как же нам решить эти проблемы? В области разработки программного обеспечения есть поговорка: любую проблему можно решить, добавив промежуточный слой. В ответ на наши предыдущие вопросы, индустрия уже дала ответ, этот средний слой — Service Mesh (сервисная сетка).
Реализация Service Mesh собственной разработки
Далее будет представлена реализация самостоятельно разработанной сервисной сетки Volcano Engine. Взгляните на диаграмму архитектуры ниже.
Узел Proxy в синем прямоугольнике на рисунке — это плоскость данных Service Mesh.Это отдельный процесс, развернутый в той же операционной среде (тот же контейнер или тот же компьютер), что и процесс Service, выполняющий бизнес-логику. Этот процесс прокси используется для проксирования всего трафика, проходящего через процесс службы.Вышеупомянутые функции, такие как обнаружение служб и политики управления трафиком, которые необходимо реализовать в среде микрослужб, могут выполняться этим процессом плоскости данных.
Зеленый прямоугольник на картинке — это поверхность управления сервисной сеткой. Политики маршрутизации трафика и управления, которые нам необходимо реализовать, определяются этой плоскостью управления. Это служба, развернутая на удаленном конце. Она и процесс плоскости данных выдают некоторые правила управления трафиком, которые затем выполняются процессом плоскости данных.
В то же время мы также видим, что плоскость данных и плоскость управления не имеют никакого отношения к бизнесу, их выпуск и обновление относительно независимы, и нет необходимости уведомлять студентов, занимающихся исследованиями и разработками.
На основе этой архитектуры могут быть решены некоторые из упомянутых выше проблем:
- Нам не нужно реализовывать многие функции микросервисной инфраструктуры на каждом языке, нам нужно реализовать их только в процессе плоскости данных Service Mesh;
- В то же время различные сложные операционные среды защищены процессом плоскости данных, а процесс службы должен взаимодействовать только с процессом плоскости данных;
- Различные гибкие и изменяемые политики управления трафиком также могут быть настроены службой плоскости управления процессами Service Mesh.
Технология управления трафиком Service Mesh
Далее я познакомлю вас с технологиями управления трафиком, предоставляемыми нашей реализацией Service Mesh, чтобы гарантировать, что микросервисы могут иметь относительно стабильную производительность перед лицом пиков трафика во время гала-концерта Douyin Spring Festival Gala.
Во-первых, давайте представим ядро управления трафиком:
- маршрутизация: Трафик исходит от объекта микрослужбы, и ему может потребоваться выполнить обнаружение некоторых служб или перенаправить его к следующей микрослужбе с помощью некоторых правил. Этот процесс может получить много возможностей управления трафиком.
- Безопасность: когда трафик проходит между различными микросервисами, необходимо обеспечить безопасность, подлинность и достоверность содержимого трафика посредством аутентификации, авторизации и шифрования.
- контроль: с учетом различных сценариев динамически корректируйте стратегию управления, чтобы обеспечить стабильность микросервисов.
- наблюдаемость: Это более важный момент, нам нужно записывать и отслеживать состояние трафика, а также сотрудничать с системой раннего предупреждения, чтобы вовремя обнаруживать и решать проблемы.
Вышеупомянутые четыре основных аспекта в сочетании с конкретными стратегиями управления трафиком могут повысить стабильность микросервисов, обеспечить безопасность содержимого трафика, повысить эффективность исследований и разработок студентов, изучающих бизнес, и улучшить общее аварийное восстановление перед лицом событий черного лебедя. способность.
Давайте продолжим рассмотрение того, какие стратегии управления трафиком предоставляет технология Service Mesh для обеспечения стабильности микросервисов.
Стратегия стабильности — автоматический выключатель
Во-первых, это предохранитель. В микросервисной архитектуре единая точка отказа является нормой. Когда возникает единая точка отказа, то, как обеспечить общий уровень успеха, является проблемой, которую необходимо решать комплексно.
С точки зрения клиента прерыватель цепи может записывать процент успешных запросов трафика, отправленных службой, достигающих каждого нижестоящего узла. Когда вероятность успеха запроса, достигающего нисходящего потока, ниже определенного порога, мы объединяем узел, чтобы запрос трафика больше не попадал на неисправный узел.
Когда неисправный узел восстанавливается, нам также нужна определенная стратегия для восстановления после предохранителя. Например, вы можете попытаться отправить часть трафика на неисправный узел в течение определенного периода времени.Если узел по-прежнему не может предоставлять услуги, продолжайте объединение, если он может предоставлять услуги, постепенно увеличивайте трафик, пока он не вернется к нормальному уровню. С помощью стратегии прерывателя цепи можно допустить недоступность отдельных узлов в микросервисной архитектуре и предотвратить лавинный эффект, вызванный дальнейшим ухудшением состояния.
Стратегия стабильности - ограничение тока
Еще одна стратегия управления — регулирование. Текущее регулирование основано на том факте, что вероятность успешной обработки запросов будет снижаться при перегрузке сервера. Например, серверный узел может обрабатывать 2000 запросов в секунду при нормальных условиях, но в случае перегрузки (при условии, что он достигает 3000 запросов в секунду) сервер может обрабатывать только 1000 запросов в секунду или даже меньше. Ограничение по току может активно сбрасывать часть трафика, чтобы сам сервер не был перегружен и предотвращал лавинный эффект.
Политика стабильности — переход на более раннюю версию
Когда серверный узел подвергается дальнейшей перегрузке, требуется стратегия перехода на более раннюю версию. Обычно существует два сценария понижения рейтинга:
- Один из них — пропорционально сбрасывать трафик. Например, трафик, отправленный из сервиса А в сервис Б, может отбрасываться в соответствии с определенным процентом (20% и выше).
- Другой — понижение обходных зависимостей. Предполагая, что сервис A должен зависеть от сервисов B, C и D, а D является обходным, трафик, зависящий от D на обходном, можно отрезать, чтобы высвободившиеся ресурсы можно было использовать для расчета ядра. путь и предотвратить дальнейшую перегрузку.
Стратегия стабильности — динамическая защита от перегрузки
Плавкие предохранители, ограничение тока и переход на более раннюю версию — все это стратегии управления при возникновении ошибок.На самом деле, лучшая стратегия — предотвратить проблемы до их возникновения, что представляет собой динамическую защиту от перегрузок, которая будет представлена следующей.
Как упоминалось выше, трудно определить порог для текущей стратегии ограничения.Как правило, испытание под давлением используется для наблюдения за числом запросов в секунду, которое может нести узел.Однако этот верхний предел может работать по-разному на разных узлах из-за разных операционных сред. . Динамическая защита от перегрузок основана на том факте, что сервисные узлы с одинаковыми спецификациями ресурсов не обязательно имеют одинаковые вычислительные возможности.
Как реализовать динамическую защиту от перегрузки? Он разделен на три части: обнаружение перегрузки, обработка перегрузки, восстановление после перегрузки. Наиболее важным является то, как определить, перегружен ли серверный узел.
Ingress Proxy на приведенном выше рисунке — это процесс уровня данных Service Mesh, который будет проксировать трафик и отправлять его серверному процессу. T3 на рисунке можно понимать как время от прокси-процесса, получившего запрос, до возврата сервера после обработки запроса. Можно ли использовать это время для оценки перегрузки? Ответ — нет, потому что Сервер может зависеть от других узлов. Возможно, что время обработки других узлов увеличилось, что привело к увеличению времени обработки Сервера.В настоящее время T3 не отражает, что Сервер находится в перегруженном состоянии.
На рисунке T2 представляет временной интервал, в течение которого сервер фактически обрабатывает запрос после того, как процесс плоскости данных перенаправляет запрос на сервер. Может ли T2 отражать состояние перегрузки? Ответ положительный. Почему? Например, предположим, что операционная среда сервера представляет собой 4-ядерный экземпляр 8g, который определяет, что сервер может обрабатывать только 4 запроса одновременно. Если к серверу будет сделано 100 запросов, остальные 96 запросов будут находиться в состоянии ожидания. Когда время ожидания слишком велико, мы можем считать его перегруженным.
Что делать после обнаружения перегрузки сервера? Существует также много стратегий обработки перегрузок.Стратегия, которую мы используем, заключается в том, чтобы активно отбрасывать некачественные запросы в соответствии с приоритетом запроса, чтобы уменьшить перегрузку сервера. Когда сервер возвращается к нормальному уровню после сброса некоторого трафика, нам необходимо выполнить соответствующее восстановление перегрузки, чтобы QPS мог достичь нормального состояния.
Насколько этот процесс динамичен? Обнаружение перегрузки — это процесс в реальном времени, который имеет определенный период времени. В каждом цикле, когда обнаруживается, что сервер перегружен, он может медленно отбрасывать некоторые некачественные запросы в соответствии с определенной пропорцией. В следующий период времени, если будет обнаружено, что сервер восстановился, коэффициент падения будет постепенно уменьшаться, чтобы постепенно восстановить сервер.
Эффект динамической защиты от перегрузки очень очевиден: он может гарантировать, что сервис не выйдет из строя в случае большого трафика и высокого давления.Эта стратегия также широко используется в некоторых крупных сервисах в проекте красного конверта Douyin Spring Festival Gala.
Стратегия стабильности — балансировка нагрузки
Далее мы рассмотрим стратегию балансировки нагрузки. Предполагая, что трафик от службы A хочет достичь нижестоящей службы B, а A и B имеют 10 000 узлов, как мы можем гарантировать, что трафик от A достигает B сбалансирован? На самом деле есть много способов сделать это. Наиболее часто используемые из них — случайный опрос, взвешенная виртуальная машина и взвешенный опрос. Фактически, вы можете понять, что означают эти стратегии, взглянув на их названия.
Другой более распространенной стратегией является последовательное хеширование. Хэш означает, что в соответствии с некоторыми характеристиками запроса, запрос должен направляться к одному и тому же узлу в нисходящем направлении, а запрос и узел сопоставляются. Стратегия последовательного хеширования в основном используется для служб, чувствительных к кешу, что может значительно улучшить частоту попаданий в кеш, повысить производительность сервера и снизить частоту ошибок из-за тайм-аутов. Когда в службе есть несколько недавно добавленных узлов или некоторые узлы недоступны, непротиворечивость хэша может как можно меньше влиять на установленное отношение сопоставления.
Существует множество других стратегий балансировки нагрузки, которые широко не используются в производственных сценариях и не будут здесь повторяться.
Стратегия стабильности — разделение узлов
Перед лицом крупномасштабной дорожной сцены красного конверта Douyin Spring Festival Gala еще одной полезной стратегией является сегментирование узлов. Разделение узлов основано на том факте, что для микросервисов с большим количеством узлов частота повторного использования длинных соединений очень низка. Поскольку микросервисы обычно взаимодействуют через протокол TCP, сначала необходимо установить TCP-соединение, а трафик проходит по TCP-соединению. Мы будем максимально повторно использовать соединение для отправки ответа на запрос поиска, чтобы избежать дополнительных накладных расходов, вызванных частым соединением и закрытием соединения.
Когда масштаб узлов очень велик, например, служба A и служба B имеют 10 000 узлов, им необходимо поддерживать множество длинных соединений. Чтобы не поддерживать слишком много длинных подключений, обычно устанавливается тайм-аут простоя, когда соединение не имеет трафика в течение определенного интервала, соединение будет закрыто. В сценарии, где масштаб сервисного узла очень велик, длинное соединение вырождается в короткое соединение, из-за чего каждый запрос должен устанавливать соединение для связи. Его эффекты:
- Ошибка, вызванная превышением времени ожидания соединения.
- Производительность будет снижена.
Для решения этой проблемы можно использовать стратегию сегментирования узлов. На самом деле, мы также очень широко использовали эту стратегию в красных конвертах гала-концерта Douyin Spring Festival Gala. Эта стратегия выполняет сегментирование узлов для служб с большим количеством узлов, а затем устанавливает отношение сопоставления, так что трафик, отправленный из сегмента 0 службы A, как показано на рисунке ниже, должен достичь сегмента 0 службы B.
Таким образом можно значительно повысить скорость повторного использования длинных соединений. За оригинал 10000Соответствующее отношение 10000 теперь стало нормальным отношением, таким как 100100. Благодаря стратегии сегментирования узлов мы значительно повышаем скорость повторного использования длинных подключений, уменьшаем количество ошибок, вызванных тайм-аутами подключения, и повышаем производительность микросервисов.
стратегия эффективности
Вышеупомянутые ограничения тока, объединение, переход на более раннюю версию, динамическая защита от перегрузок и сегментирование узлов — все это стратегии, связанные с повышением стабильности микросервисов, а также некоторые стратегии, связанные с эффективностью.
Давайте сначала представим концепцию дорожек и разделения красителей.
Функция, показанная на схеме выше, может включать шесть микросервисов a, b, c, d, e, f. Эти потоки можно изолировать с помощью дорожек.Каждая дорожка содержит эти шесть микросервисов, и они могут выполнять определенную функцию.
Окрашивание перенаправления означает направление движения транспорта по разным полосам в соответствии с определенными правилами, а затем использование этого для выполнения некоторых функций, которые в основном включают:
- Отладка функций: в процессе онлайн-разработки и тестирования вы можете отправить некоторые запросы, выданные отдельными лицами, на установленную вами дорожку и выполнить отладку функций.
- Исправление проблем: После завершения разработки некоторых сервисов гала-концерта Весеннего фестиваля в Доуине требуются учения по устранению различных сбоев. В настоящее время мы можем перенаправить трафик для измерения давления на плавательную дорожку учения по разлому с помощью некоторых правил.
- Запись и воспроизведение трафика: Запишите трафик по определенному правилу, а затем воспроизведите его. В основном используется для отладки ошибок или поиска проблем в некоторых сценариях черного производства.
стратегия безопасности
Политика безопасности также является важной частью управления трафиком. В основном мы предлагаем три стратегии безопасности:
- Разрешить: Авторизация относится к ограничению того, какие службы могут быть вызваны службой.
- Аутентификация: когда служба получает трафик, она должна идентифицировать подлинность источника трафика.
- Двустороннее шифрование (mTLS): Чтобы предотвратить отслеживание, подделку или атаку содержимого трафика, требуется двустороннее шифрование.
С помощью вышеуказанных стратегий мы обеспечиваем надежную аутентификацию, безопасное шифрование передачи и предотвращаем фальсификацию или атаку содержимого передаваемого трафика.
Приземлилась сцена красного конверта гала-концерта Весны
С помощью различных стратегий, упомянутых выше, мы можем значительно повысить стабильность микросервисов и эффективность развития бизнеса. Однако при реализации этого набора архитектур мы также столкнемся с некоторыми проблемами, главная из которых — производительность. Мы знаем, что при добавлении промежуточного уровня, хотя масштабируемость и гибкость улучшаются, в то же время должны быть некоторые дополнительные накладные расходы, и эти накладные расходы — это производительность. Без Service Mesh основные накладные расходы микросервисной инфраструктуры связаны с сериализацией и десериализацией, сетевым взаимодействием, обнаружением сервисов и стратегиями управления трафиком. После использования Service Mesh возникнут две дополнительные накладные расходы:
Анализ протокола
Для трафика, проксируемого процессом плоскости данных, необходимо проанализировать протокол трафика, чтобы узнать, откуда он исходит. Однако накладные расходы на анализ самого протокола очень высоки, поэтому мы можем поместить метаинформацию службы, такую как источник трафика, в этот заголовок, добавив заголовок (набор ключа и значения), чтобы только одна или двести байтов контент необходимо проанализировать. Выполните соответствующую маршрутизацию.
межпроцессного взаимодействия
Процесс плоскости данных будет проксировать трафик бизнес-процесса, обычно через iptables. Накладные расходы этой схемы очень высоки, поэтому мы применяем метод межпроцессного взаимодействия, а затем выполняем перехват соответствующего трафика, согласовывая с инфраструктурой микросервиса адрес сокета домена unix или локальный порт. Хотя этот метод будет иметь некоторые улучшения производительности по сравнению с iptables, он также имеет некоторые дополнительные накладные расходы.
Как уменьшить накладные расходы на связь между процессами? В традиционном межпроцессном взаимодействии, таком как сокеты домена unix или локальные порты, это включает копирование передаваемого содержимого из пользовательского режима в режим ядра. Например, пересылка запроса в процесс плоскости данных будет включать копирование запроса между режимом пользователя и режимом ядра, а когда процесс плоскости данных читает его, это будет включать копирование из режима ядра в пользовательский режим, поэтому до 4 копий памяти.
Наше решение черезОбщая памятьзавершить. Общая память — это высокопроизводительный метод межпроцессного взаимодействия в Linux, но он не имеет соответствующего механизма уведомлений. Когда мы помещаем запрос в разделяемую память, другой процесс не знает о том, что туда помещен запрос. Поэтому нам нужно ввести некоторые механизмы уведомления о событиях, чтобы сообщить об этом процессу плоскости данных. Мы выполнили такой процесс через доменный сокет unix, и его эффект заключается в уменьшении накладных расходов на копирование памяти. В то же время мы ссылаемся на очередь в общей памяти, которая может собирать операции ввода-вывода в пакетном режиме, тем самым сокращая количество системных вызовов. Его эффект также очень очевиден: в некоторых сценариях управления рисками гала-концерта Douyin Spring Festival производительность может быть улучшена на 24%.
После выполнения этих оптимизаций сопротивление приземлению не так велико.
Суммировать
Это совместное использование в основном знакомит с тем, какие возможности управления трафиком может предоставить технология Service Mesh для обеспечения стабильности и безопасности микросервисов. В основном он включает в себя три основных пункта:
- стабильность: В условиях мгновенных пиков трафика в 100 миллионов запросов в секунду технология управления трафиком, предоставляемая Service Mesh, обеспечивает стабильность микросервисов.
- Безопасность: Благодаря политике безопасности, предоставляемой Service Mesh, трафик между службами гарантированно безопасен и надежен.
- эффективный: Мероприятие Spring Festival Gala включает в себя множество микросервисов, написанных на разных языках программирования. Service Mesh, естественно, предоставляет этим микросервисам унифицированные возможности управления трафиком, повышая эффективность исследований и разработок разработчиков.
Q&A
Q: Почему IPC-связь в разделяемой памяти сокращает количество системных вызовов?
A: Когда клиентский процесс помещает запрос в разделяемую память, нам нужно уведомить процесс Сервера об его обработке, будет операция пробуждения, и каждое пробуждение означает системный вызов. Когда сервер не был разбужен или когда он обрабатывает запрос, приходит следующий запрос, и нет необходимости выполнять ту же операцию пробуждения, поэтому нам не нужно часто просыпаться в сценариях с интенсивным запросом. Чтобы уменьшить влияние системных вызовов.
Q: Самостоятельно разработанная реализация Service Mesh полностью разработана самостоятельно или основана на продуктах сообщества, таких как Istio? Используете ли вы язык Go или Java для самоисследования? Использует ли Envoy плоскость данных? Используется ли iptables для захвата трафика?
A:
- Плоскость данных основана на Envoy для вторичной разработки, а язык использует C++.
- Перехват трафика использует uds или локальный порт, согласованный с микросервисной структурой, вместо iptables.
- Ingess Proxy и бизнес-процессы развернуты в одной операционной среде, а обновление релиза не требует перезапуска контейнера.