Apache APISIX объединяет полное управление трафиком с Service Mesh

С быстрым ростом Cloud Native, Service Mesh также начинает набирать популярность. В настоящее время существует множество известных решений Service Mesh, и каждый продукт имеет свои преимущества. Поэтому выбор решений Service Mesh варьируется в зависимости от отрасли или бизнес-контекста.

Текущее состояние и проблемы Service Mesh

Появление Service Mesh тесно связано с текущей эволюцией бизнес-архитектуры. С ростом популярности Cloud Native, большинство предприятий начали переходить на микросервисы, где мы заметили, что приложения стали становиться все меньше и меньше, и каждое приложение содержало некоторые общие элементы. Поэтому мы начали задумываться: "Существует ли технология, которая может решить общие задачи?" Так появился Sidecar.

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

Однако появление Sidecar заставило людей постепенно осознать некоторые его проблемы на практике, такие как:

• Существует так много решений, что миграция после выбора становится сложной. В настоящее время существует множество решений Service Mesh, и характеристики и возможности каждого из них различаются. Как только одно из этих решений выбрано, оно используется без возможности замены. Однако, если мы обнаружим, что решение не соответствует новым требованиям при расширении бизнеса, затраты на миграцию будут огромными.
• Высокая стоимость интеграции с инфраструктурой. Реализация Service Mesh на практике часто требует интеграции с инфраструктурой, такой как предыдущие микросервисные архитектуры, MQ или компоненты инфраструктуры баз данных. Некоторые устаревшие проблемы или технический долг также могут создавать препятствия для процесса интеграции.
• Потери производительности и дополнительное потребление ресурсов. В настоящее время, независимо от того, какое решение Service Mesh вы выберете, оно будет иметь некоторые потери производительности. Кроме того, из-за Sidecar требуется выделение дополнительных ресурсов для него при настройке бизнеса.
• Сложность масштабирования. Некоторые решения Service Mesh не масштабируются в плане протоколов или функций с существующими методами конфигурации, и они не могут быть настроены путем подключения и отключения плагинов.

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

Как выглядит идеальный Service Mesh?

В бизнес-сценариях наши требования к Service Mesh, как показано выше, включают несколько аспектов: ресурсы, производительность, управление трафиком и масштабируемость. Конечно, помимо этого, будут и более детальные требования в других аспектах. Например:

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

Поскольку у нас есть такие четкие требования и цели, следующим шагом является реализация и создание такого близкого к идеальному решения.

Решение Service Mesh на основе APISIX

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

Сотни предприятий по всему миру уже используют Apache APISIX для обработки критически важного бизнес-трафика, охватывая финансы, интернет, производство, розничную торговлю, операторов связи и т.д., такие как NASA, European Factory Platform, China Airlines, China Mobile, Tencent, Huawei, Weibo, Netease, Ke Holdings Inc., 360, Taikang, Nayuki Holdings Limited и другие. Поэтому решение Service Mesh на основе APISIX будет востребовано не только на уровне использования, но и при работе с различными отраслями.

Архитектура текущего решения Service Mesh основана на Istio как контрольной плоскости и APISIX как плоскости данных.

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

Плоскость данных — это то, где Apache APISIX может проявить свои преимущества. Как облачный API-шлюз, какие действия APISIX предпринял в качестве плоскости данных Istio в этом решении Service Mesh?

Те, кто знаком с APISIX, знают, что APISIX использует etcd для хранения данных. Но если мы используем APISIX как Sidecar, откуда берется его конфигурация? Это вопрос, который необходимо рассмотреть. Если мы поместим компонент etcd в Sidecar, мы обнаружим, что общее потребление ресурсов очень велико и недостаточно гибко.

Поэтому в этом процессе мы сначала добавили в APISIX конфигурационный центр под названием xDS, чтобы устранить необходимость в etcd, а затем представили Amesh, как показано выше, программу на Go, скомпилированную в динамическую библиотеку, которая загружается при запуске APISIX. Она использует протокол xDS для взаимодействия с Istio. Затем она записывает полученную конфигурацию в конфигурационный центр xDS APISIX, который генерирует конкретные правила маршрутизации и в конечном итоге использует APISIX для маршрутизации соответствующих запросов.

После настройки вышеуказанной архитектуры можно достичь следующих результатов:

• Amesh и APISIX поддерживают одинаковый жизненный цикл и могут включаться и выключаться вместе.
• Благодаря нативной поддержке xDS Discovery в APISIX, данные преобразуются друг в друга через протокол xDS, что приводит к контролируемому уровню потребления ресурсов.
• CRD может использоваться для быстрого и легкого расширения всего решения, особенно для функций, которые еще не поддерживаются Istio. Например, наиболее богатая конфигурация плагинов в APISIX настраивается через CRD; используя контроллер вместе с Istio, масштабируемость решения Service Mesh Istio и APISIX максимально увеличивается.

Конкретные характеристики решения

Значительное улучшение производительности

Данные всегда являются наиболее интуитивным и эффективным способом представления технологического продукта. Мы используем APISIX и Envoy в качестве плоскости данных в решении Service Mesh, проводим стресс-тестирование в различных сценариях с объемом до 5000 маршрутов и представляем следующие данные для сравнения.

Тестовый сценарий — "Сопоставление 3000-го маршрута из 5000 маршрутов". Из-за большого количества тестовых сценариев ниже описываются только маршруты, соответствующие средней части, а также есть сценарии сопоставления начальных и конечных маршрутов. (Данных слишком много, поэтому ниже приведены результаты теста с объемом 3000 маршрутов).

Как видно из данных выше, APISIX показывает 5-кратное улучшение производительности на уровне QPS при одинаковой нагрузке и конфигурации машины. Также на уровне задержки запросов APISIX ниже, чем у Envoy, на порядок величины, с задержкой APISIX в микросекундах и Envoy в миллисекундах. Конечно, вы также можете видеть, что в этом измерении потребление CPU APISIX составляет только 50%, когда CPU Envoy уже работает на полную мощность.

Снижение использования ресурсов

При внедрении Sidecar в решение Service Mesh обычно потребляются дополнительные ресурсы. Решение на основе API может снизить потребление ресурсов на 60%. Почему это возможно?

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

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

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

Низкая стоимость обучения и высокая способность к настройке

Во-первых, как активный проект с открытым исходным кодом Apache Software Foundation, APISIX предоставляет богатую документацию и учебные ресурсы в сообществе, что снижает стоимость обучения для тех, кто хочет начать работать с APISIX.

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

Наконец, вторичная разработка на основе APISIX очень проста. Когда вы хотите настроить плагины для своего бизнеса, поддерживается не только нативный язык Lua, но и вы можете использовать Plugin Runner APISIX для реализации вторичной разработки на более знакомых языках, таких как Python, Java, Go и даже Wasm.

Экологическая сила APISIX также обусловлена высокой расширяемостью продукта.

APISIX сам по себе предлагает широкий спектр плагинов для безопасности, логирования, наблюдаемости и многого другого. Эти плагины могут быть использованы в полной мере, когда APISIX используется как традиционный компонент шлюза. Однако, когда APISIX используется в сочетании с Istio на контрольной плоскости для создания сервисной сетки, многие ресурсы не определены на контрольной плоскости Istio. Так что можно сделать в этом случае?

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

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

В заключение, решение Service Mesh на основе APISIX проще в использовании и расширяемо для разработчиков или пользователей, имеет отличную производительность и богатую экологическую поддержку. Благодаря возможностям продукта APISIX, оно также имеет хорошую поддержку на уровне плагинов и многопротокольности. Мы ожидаем представить вам следующую версию Service Mesh на основе APISIX в конце года. Пожалуйста, ожидайте!

Перспективы решения Service Mesh на основе APISIX

Оглядываясь назад, решение Service Mesh на основе APISIX уже работает над решением проблем, упомянутых в предыдущей статье, и движется к идеальному решению Service Mesh.

С решением Service Mesh на основе APISIX вы можете видеть, что трафик поступает извне через APISIX Ingress и обрабатывается через APISIX в середине. В этом процессе APISIX Ingress обрабатывает северо-южный трафик, а Amesh + Istio обрабатывают восточно-западный трафик.

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

В последующих итерациях решение Service Mesh на основе APISIX будет продолжать углубляться, выполняя такие запланированные направления, как:

• Реализация возможностей xRPC в сочетании с функциональностью APISIX.
• Нативная поддержка гетерогенных многопротокольных решений.
• Охват всех видов сценариев и конфигураций, включая Istio, для значительного снижения затрат на миграцию пользователей.

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