Как реализовать оркестрацию плагинов в API Gateway

Смотреть видео

Для начала позвольте представиться. Меня зовут Мин Вэнь, я сооснователь API7.ai. Я являюсь вице-президентом и членом PMC (Project Management Committee) в открытом проекте Apache APISIX. Также я коммиттер в Apache SkyWalking. Кроме того, я основатель комитета по открытому исходному коду Qihoo 360, Tencent Cloud TVP и член TOC (Technical Oversight Committee) в TARS Foundation. У меня более 40 патентов в области безопасности.

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

Краткое введение в Apache APISIX

Прежде всего, позвольте кратко представить Apache APISIX. В двух словах, это облачный API-шлюз. Вот репозиторий Apache APISIX на GitHub.

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

Для разработчиков, которые не знакомы с Apache APISIX, его можно просто представить как улучшенную версию NGINX, которая охватывает все функции NGINX, но при этом использует Lua. Это добавляет больше динамических возможностей в NGINX, превращая его в мощный API-шлюз. Главная особенность Apache APISIX — это полная динамичность, включая маршрутизацию, SSL-сертификаты, плагины и т.д. В Apache APISIX все функции настраиваются динамически через административный API, без необходимости перезапуска сервиса. В Apache APISIX бизнес-потребности пользователей реализуются с помощью разработки плагинов на Lua. APISIX имеет более 40 встроенных плагинов, включая аутентификацию, ограничение скорости, ограничение запросов, безопасность, логирование, наблюдаемость и т.д., что охватывает практически все функции, которые могут понадобиться в корпоративной среде.

Что может делать Apache APISIX?

Apache APISIX может обрабатывать трафик на уровнях 4 и 7, включая HTTP, HTTPS, TCP, UDP, MQTT и т.д.

Поскольку Apache APISIX основан на NGINX, его можно использовать вместо NGINX для обработки трафика между севером и югом. В то же время Apache APISIX также хорошо справляется с трафиком между микросервисами, поэтому его можно использовать для замены Envoy. Некоторые пользователи также используют Apache APISIX как ingress-контроллер Kubernetes. С помощью плагина MQTT Apache APISIX можно использовать как шлюз для IoT или с помощью IDP-плагина превратить APISIX в шлюз с нулевым доверием. Таким образом, APISIX больше ориентирован на мощь самого шлюза. С помощью плагинов пользователи могут превратить APISIX в различные шлюзы, необходимые для их бизнеса.

Техническая архитектура Apache APISIX

Это техническая архитектура Apache APISIX. Из нее видно, что APISIX состоит из двух частей: слева — плоскость данных, справа — плоскость управления.

Сначала рассмотрим плоскость данных. После обработки запроса пользователя через Apache APISIX он может быть передан на частный API, публичный API или API партнеров. Внутри Apache APISIX плагины построены по принципу Lego. Вы можете легко удалить или добавить плагин без перезапуска сервиса.

Теперь рассмотрим плоскость управления. В плоскости управления администратор записывает конфигурации в кластер etcd через административный API, а плоскость данных APISIX отслеживает etcd, чтобы конфигурации могли достичь всех плоскостей данных за миллисекунды. После обработки данных узлами плоскости данных они передают метрики и данные логов в такие компоненты, как SkyWalking, Prometheus и т.д.

Из этой архитектурной схемы видно, что APISIX зависит только от etcd и не использует RDS, такие как MySQL и PostgreSQL. Поэтому APISIX лучше спроектирован для высокой доступности. В то же время его архитектура проще, что удобно для развертывания и эксплуатации.

Ландшафт Apache APISIX

На этой картинке показан ландшафт Apache APISIX. Слева видно, что APISIX поддерживает множество протоколов 4-го и 7-го уровней. Он не только поддерживает трафик из браузеров и мобильных приложений, но и позволяет различным IoT-устройствам передавать трафик в APISIX.

Apache APISIX также поддерживает множество внешних сервисов обнаружения, включая etcd и Consul.

Как очень важное инфраструктурное программное обеспечение, API-шлюз обычно размещается на входе трафика. Поэтому он должен не только обрабатывать все запросы от клиентов, но и подключаться к некоторым сервисам, таким как SkyWalking, Datadog, Kafka и т.д.

В нижней части этой картинки видно, что APISIX поддерживает работу не только на bare metal, но и на серверах в различных публичных облаках. Мы также поддерживаем работу на платформе ARM.

Часть 2: Кастомная разработка в API-шлюзе

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

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

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

Решения для разработки плагинов

Давайте сначала рассмотрим Kong. Это известный проект API-шлюза. Ему уже 5 лет. Технологический стек Kong в основном такой же, как у APISIX, и оба реализованы на основе NGINX и Lua. Но техническая архитектура Kong отличается от APISIX. Kong основан на RDS, таких как PostgreSQL и Cassandra. APISIX использует etcd, и решение APISIX ближе к Kubernetes и облачным технологиям.

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

Решение Kong — это поддержка написания плагинов на Go. Этот подход привлечет больше разработчиков на Go для написания плагинов, чтобы удовлетворить кастомные потребности их компании. Это хорошая идея, но, с другой стороны, Kong изначально реализован на основе Nginx и Lua, и плагины, написанные на Go, фактически вызывают другой процесс, что приводит к межпроцессному взаимодействию, что влияет на производительность.

Теперь рассмотрим второй проект, который также является очень известным открытым проектом для обработки трафика между микросервисами — Envoy, который написан на C++. Поэтому плагины Envoy также реализованы на C++. Это не так просто для начала.

Envoy также поддерживает разработку на других языках. Например, Envoy поддерживает Lua-фильтры, и Lua-фильтры имеют ту же проблему, что и Kong, — мало разработчиков, знакомых с Lua. Поэтому Envoy также поддерживает WASM, что может привлечь больше разработчиков на других языках для написания плагинов. Это решение не идеально, и стабильность и производительность WASM все еще нуждаются в улучшении.

Решения Kong и Envoy схожи: они хотят, чтобы больше разработчиков могли разрабатывать плагины, будь то на Go, Lua или WASM. Поэтому, возвращаясь к APISIX, мы хотим найти "серебряную пулю".

Как выглядит "серебряная пуля"?

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

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

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

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

Решение первой проблемы: повторное использование существующих плагинов

Микросервисы уже стали очень популярной технологией, поэтому можем ли мы внедрить эту концепцию в плагины API-шлюза?

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

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

Например, сначала я вызываю плагин блокировки URI. После завершения вызова я проверяю, действительно ли URI заблокирован. Если он заблокирован, то продолжаю вызывать плагин Kafka.

Используя этот метод pipe, эти плагины могут быть соединены. Apache APISIX сейчас имеет более 40 плагинов. Комбинации более 40 плагинов имеют бесконечные возможности, что достаточно для удовлетворения потребностей пользователей.

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

Решение второй проблемы: снижение стоимости разработки

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

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

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

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

Соединив идеи GUI и Lego, мы получаем Scratch, который используется для обучения детей программированию, что делает порог входа очень низким.

Плагин-оркестрация в APISIX

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

В этом видео мы сначала создаем плагин блокировки URI, а затем создаем условное суждение. Если блокировка URI истинна, то мы добавляем его в плагин инъекции ошибок; если результат блокировки URI ложный, мы передаем его в плагин Kafka для записи логов.

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

Теперь я объясню, как реализована плагин-оркестрация. Это также может быть техническим вопросом, который волнует всех.

Для реализации плагин-оркестрации нам нужно выполнить три шага.

На первом шаге нам нужно использовать DAG (Directed Acyclic Graph) для описания нового плагина. Мы видим, что граф со стрелками слева — это DAG, который соответствует коду, описанному в предыдущем видео. Это описание, удобное для человека. Для компьютера мы должны превратить его в описание структуры данных справа. Например, узел 1 указывает на узлы 2, 4 и 6; узел 3 не имеет последующих узлов, и так далее. Таким образом, мы преобразуем DAG в описание структуры данных.

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

После первого шага у нас уже есть строка, описанная JSON, но как мы можем преобразовать эту строку в код, который может быть выполнен APISIX?

Мы знаем, что в APISIX выполняется код на Lua, поэтому нам нужен компилятор, чтобы разобрать JSON в AST (абстрактное синтаксическое дерево) и в конечном итоге сгенерировать код на Lua. Для этого мы использовали jsonschema. Ниже приведен репозиторий с открытым исходным кодом.

После генерации кода на Lua мы используем плоскость управления APISIX, чтобы записать код Lua в etcd через административный API, а затем узел плоскости данных APISIX получает код Lua через отслеживание etcd. APISIX имеет возможность динамически выполнять код Lua, как и плагин serverless в APISIX.

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

Если вы дочитали до этого места, у вас может возникнуть вопрос: где я могу попробовать это? Не беспокойтесь, есть открытый проект, и у нас также есть онлайн-демонстрация.

Мысли о будущем API-шлюзов

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

Один из трендов заключается в том, что традиционные API-шлюзы для трафика между севером и югом начинают обрабатывать трафик между микросервисами. Например, NGINX запустил NGINX Control и NGINX Unit. Kong и APISIX также выступают в роли API-шлюзов для микросервисов.

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

Открытые проекты для обработки трафика процветают, мы можем видеть BFE от Baidu и MOSN от Alibaba. Все они сосредоточены на трафике.

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

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

Третий тренд — это реальное время. С распространением 5G и IoT, а также внедрением Kubernetes в компаниях, предъявляются очень высокие требования к реальному времени конфигурации, обработке запросов и анализу данных в реальном времени. Для шлюза, если он не может быть реальным временем, очень производительным и с очень низкой задержкой, он не выживет в ближайшие три-пять лет.

И последнее, но не менее важное — это открытый исходный код. Мы видим, что программное обеспечение "пожирает" аппаратное обеспечение, а открытое программное обеспечение "пожирает" программное обеспечение. В конечном итоге все инфраструктурное программное обеспечение становится открытым.

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