Эволюция архитектуры унифицированного уровня доступа Youzan

Эта статья представляет собой сборник выступлений на мероприятии Hangzhou Station, посвященных передовым методам работы с облачными приложениями. На мероприятии станции в Ханчжоу были приглашены Вэнь Мин, вице-президент проекта Apache APISIX, Мо Хунбо, старший инженер отдела разработки облачных платформ, Ван Факан, технический эксперт Ant Financial, и Чжан Чао, инженер по разработке промежуточного программного обеспечения Youzan, чтобы поделиться опытом облачных вычислений. нативное приложение, как показано ниже.

Чжан Чао, инженер-разработчик команды промежуточного программного обеспечения Youzan, эксперт в области шлюзов и сервисных сеток, увлекается технологиями и глубоко изучает языки Golang, Nginx, Ruby и т. д.

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

Сначала кратко представлю слой доступа Youzan.Внутреннее название YZ7.Концептуально он близок к шлюзу.Реализован на базе OpenResty и Nginx,в основном включает стандартные модули C и модули C собственной разработки Nginx.И модули на основе реализации lua. Являясь общедоступным сетевым входом для бизнес-трафика Youzan, он обеспечивает формирование трафика, включая текущее ограничение, функции, связанные с безопасностью, такие как WAF, и маршрутизацию запросов.Маршрутизация запросов включает стандартные сине-зеленые публикации, серые публикации и функции балансировки нагрузки. Сегодняшний обмен в основном подробно анализирует следующие три аспекта:

• Болевые точки устаревшей архитектуры уровня доступа

• Анализ дизайна новой архитектуры

• Резюме проекта новой архитектуры

Болевые точки устаревшей архитектуры уровня доступа

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

На картинке выше показан вертикальный разрез старой архитектуры уровня доступа, а решение было найдено несколько лет назад. В то время Redis был популярен для синхронизации конфигурации, и его естественный протокол синхронизации master-slave действительно очень подходил. Линия желтой стрелки — это синхронизация конфигурации, данные синхронизируются от мастера redis к слейву redis на каждом инстансе, а затем YZ7 этого уровня перейдет к редису этого уровня и прочитает данные в свою память.

Почему внизу справа находится контроллер k8ssync? Поскольку K8S постепенно становится популярным в последние несколько лет, многие приложения начали переходить на контейнеризацию.

YZ7 разработан на основе OpenResty, а весь стек технологий основан на lua, который не входит в экосистему K8S. Если вы хотите наблюдать за сервисом в K8S, вам нужно знать, какие конечные точки у него есть в режиме реального времени. Хотя это может быть достигнуто с помощью lua, для этого необходимо заново создать клиентскую библиотеку, аналогичную стандарту K8S, что не стоит потери. Поэтому будет применен контроллер k8sssync, написанный GoLang, который отвечает за получение данных конечных точек интересующих его бэкенд-сервисов от K8S, а затем снова записывает их в мастер redis через API, настроенный YZ7, и, наконец, распределяет мастером Redis на каждом экземпляре YZ7.

Недостатки устаревшей архитектуры уровня доступа

• Единственная проблема мастера redis: не используется схема redis closter или sentinel, это просто режим master-slave.Если есть проблема, конфигурация не может быть доставлена.

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

• Когда возникает проблема с мастером Redis, это означает, что данные конечной точки внутренней службы K8S, синхронизированные с контроллера k8ssync, не могут быть синхронизированы с экземпляром YZ7 в режиме реального времени. Если точка некоторых экземпляров службы очищается, уровень доступа не может определить это в первый раз. В результате, когда приходит запрос, IP-адрес точки, который был отключен, все еще используется здесь, в результате чего запрос будет 502, 504, что приведет к недоступности службы. Есть и недостаток, контроллер k8ssync в силу исторических причин тоже одна точка, если он зависнет, K8S сервер не сможет синхронизироваться, что тоже приведет к недоступности сервиса и даже к масштабным сбоям.

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

Три компонента новой архитектуры

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

• Во-первых, решить основную проблему одной точки и предоставить гарантию доступности услуги.

• Дизайн компонентов должен быть без состояния, в оттенках серого, с откатом и наблюдаемым.

• Без сохранения состояния: это означает, что сервис может эластично расширяться и сжиматься, что очень полезно при работе с эластичным трафиком.

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

• Откат: когда выпускается обновление службы, происходят некоторые цепные реакции, которые можно откатить по отдельности.

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

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

После выполнения вышеуказанных пунктов новое архитектурное решение выглядит как разделение плоскости управления и плоскости данных в Service Mesh и разделение плоскости управления и плоскости данных в APISIX. Над средней пунктирной линией находится плоскость управления, а под ней — плоскость данных. Основной компонент плоскости управления называется YZ7-manager. Он подключается к K8S слева и ETCD справа. ETCD является его центром хранения конфигураций. Все конфигурации уровня доступа будут храниться в ETCD, а также будут наблюдать за K8S.

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

диспетчер основных компонентов плоскости управления

• Менеджер — это поставщик конфигурации, аналогичный Istio Pilot, который до Istio 1.5 состоял из нескольких компонентов, наиболее важным из которых был Pilot. Конфигурация хранится в ETCD.Характеристика ETCD заключается в том, что она стабильна и надежна, поэтому для выбора используется ETCD.

• Менеджер не имеет состояния и может масштабироваться горизонтально.

• Менеджер взял на себя функцию оригинального контроллера k8ssync и позволил ему наблюдать за K8S вместо оригинальной функции K8S-think. Поскольку менеджер не имеет состояния и расширяется по горизонтали, он решает одноточечную проблему YZ7 K8S-мышления. При этом в исходной архитектуре админ-сервер настроенный YZ7 очень похож на текущий APISIX.Его админ-сервер ставится вместе со шлюзом.В новой архитектуре админ-сервер шлюза заменяется и ставится только на YZ7 на плоскости управления.

• Последней основной функцией является настройка функции распределения, которая распределяет данные по каждой плоскости данных из плоскости управления YZ7-manager.

Агент основного компонента плоскости управления

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

Уровень доступа YZ7

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

Ключевые моменты деталей дизайна новой архитектуры

Поговорив о трех основных компонентах, давайте поговорим о некоторых наиболее важных деталях новой архитектуры.

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

Во-вторых: между агентом YZ7 и YZ7 данные находятся в режиме push или в режиме pull?

Третье: как реализовать аннотации конфигурации?

Четвертое: как обеспечить зависимости конфигурации?

Далее я подробно объясню эти четыре вопроса и разберу их один за другим:

Плоскость управления YZ7-менеджер в плоскость данных YZ7-агент

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

Во-вторых, протокол должен поддерживать активный толчок сервера, точно так же, как конфигурация APISIX вступает в силу очень быстро, потому что ETCD поддерживает функцию наблюдения. Время настройки Kong относительно велико, поскольку PostgreSQL и Cassandra подключены к Kong, а эти две реляционные базы данных не поддерживают контроль. На стороне сервера происходят изменения данных, а клиентская сторона может получить их только путем опроса. Если интервал опроса слишком длинный, время действия конфигурации будет высоким; если интервал слишком короткий, изменения данных могут быть получены вовремя, но потребление ресурсов будет выше.

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

На картинке выше фрагмент gRPC, XDS. Наверху находится ConfigDiscoverService.Этот gRPC является ядром синхронизации конфигурации.Два основных сообщения — configrequest и configresponse.

В configrequest узел — это данные, относящиеся к экземпляру канала передачи данных, такие как кластер, в котором он находится, имя хоста, IP-адрес и т. д. Условие ресурса — это конфигурация, которая объявляет интерес к плоскости данных, например, конфигурация маршрутизации, восходящая конфигурация или междоменная конфигурация. Объявите все интересующие конфигурации в списке и сообщите об этом серверу, чтобы плоскость управления могла точно передать интересующую конфигурацию в плоскость данных.

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

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

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

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

Агент плоскости данных YZ7 для доступа к уровню YZ7

От агента YZ7 к YZ7, то есть от агента плоскости данных к экземпляру плоскости данных, является ли выбор синхронизации конфигурации pull или push?

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

Второй — это режим отправки, когда агент YZ7 должен активно передавать данные в YZ7. Преимущество заключается в том, что YZ7 нужно только выполнить простое действие сохранения, не нужно учитывать истечение срока действия данных, а степень связанности комбинации будет ниже. Такой YZ7 можно доставить на тест, и можно добавить несколько интерфейсов для проталкивания тестовых данных, которые нужно использовать, без необходимости развертывания дополнительного YZ7-агента, что более выгодно для теста доставки. Недостатком является то, что есть проблема полагаться на других для отправки.Если сервис только что запустился или Nginx только что завершил горячее обновление, в общей памяти нет данных.Чтобы принять режим push, эту проблему необходимо решить. решено. Используемый нами метод заключается в том, что агент периодически сбрасывает кеш данных на диск.Когда экземпляр уровня доступа YZ7 обновляется в горячем режиме или только что запущен, старые данные будут загружаться с диска, чтобы убедиться, что он может работать нормально. Кроме того, обязательно требуется, чтобы агент YZ7 передал данные в полном объеме в это время, и последняя конфигурация может быть достигнута немедленно.

Реализация аннотаций конфигурации

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

На картинке выше показан фрагмент полезной нагрузки конфигурации. Доступ к данным конфигурации осуществляется сверху вниз. В нем всего один сервер, а аннотациями является эта аннотация. Канареечное поле в нем можно оформить как поле, необходимое для настройки оттенков серого. . Это настраивается в соответствии с именем хоста, и только hosts2 или hosts3 вступят в силу. Идентификатор, имя и тип используются для идентификации конфигурации, такой как имя, тип, UUID и т. д. На самом деле, декларативная конфигурация K8S также одинакова. Конкретная конфигурация размещается на поверхности стейка, а снаружи будут облачные данные, такие как лейбол. Антотации на рисунке — это антотации, которые следуют за декларативной конфигурацией K8S. .

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

Создайте конфигурацию оттенков серого с аннотациями оттенков серого. Распространяется на каждого агента через YZ7-manager. Агент определит, является ли конфигурация удачной или неудачной на машине. Если это не так, эта конфигурация будет проигнорирована и не будет отправлена. Если это хит, подтолкните его к YZ7 в этой машине.

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

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

Управление зависимостями конфигурации

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

Резюме проекта архитектуры

Переход на облачные технологии требует, чтобы мы узнавали больше и учились у хороших компонентов в облачных аспектах нашей работы, таких как K8S, Envoy и т. д., которые являются отличными моделями, достойными изучения. Новая архитектура уровня доступа Youzan следует принципу разделения функций между плоскостью управления и плоскостью данных, который относится к дизайну Service Mesh; протокол конфигурации и доставки относится к Envoy и xDS; функция добавления аннотаций относится к K8S. в дизайне Декларативное определение декларативной конфигурации.

На пути к «нативному облаку» мы должны больше смотреть вперед, лучше интегрировать функции, необходимые для «нативного облака», и новые знания в нашу работу, а также лучше вписывать компоненты, используемые в «нативном облаке».

Рекомендуемое чтение

Выбор технологии: почему мы выбрали Flink для пакетной обработки

[Боевой обмен] От выбора модели до реализации проекта: расскажите о gRPC