Почему Apache APISIX — лучший API Gateway?

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

В ландшафте API-шлюзов CNCF представлено почти 20 типов API-шлюзов (не включая услуги облачных провайдеров), включая Apache APISIX, Kong, Tyk и другие. Многие из них заявляют, что являются самыми популярными проектами API-шлюзов с открытым исходным кодом, API-шлюзами следующего поколения, но так ли это?

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

Разработчики программного обеспечения знают это хорошо

Разработчики программного обеспечения являются пользователями и создателями API и API-шлюзов, поэтому популярность среди инженеров является прямым индикатором тенденций. Ниже приведен график, сравнивающий общее количество участников на GitHub для четырех API-шлюзов: Apache APISIX, Kong, Tyk и Gloo.

Из графика видно, что Kong и Tyk начали свою деятельность примерно в 2015 году, в то время как Apache APISIX и Gloo появились позже, в 2019 году. Более того, можно заметить, что самый молодой Apache APISIX имеет самый крутой рост среди всех и накопил более 320 участников, опередив второго по популярности Kong на 57 человек, став проектом API-шлюза с наибольшим количеством участников.

Помимо общего количества участников, количество ежемесячно активных участников имеет большее значение. Количество ежемесячно активных участников для Tyk составляет всего около 5 и редко превышает 10, в то время как Kong и Gloo колеблются между 10 и 20. В то же время Apache APISIX стабильно имеет более 20 ежемесячно активных участников, а на пике — почти 40, что делает его самым активным проектом API-шлюза.

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

По состоянию на 2022 год Kong и Tyk имеют соотношение 4%, а Gloo — 24%. В то же время APISIX почти достиг 100%. Причина этого заключается в том, что с самого начала, когда компания API7.ai запустила проект APISIX, она прилагала постоянные усилия для развития сообщества с открытым исходным кодом и завоевала репутацию среди разработчиков.

Лицензия с открытым исходным кодом: самый важный фактор при выборе API-шлюза с открытым исходным кодом

С тех пор как MongoDB изменила свою лицензию с открытым исходным кодом на SSPL (Server Side Public License) в 2018 году, предприятия теперь должны открывать исходный код своего собственного программного обеспечения, если MongoDB используется как управляемая услуга. В результате предприятия должны серьезно учитывать лицензию проекта при выборе проекта.

На первый взгляд, Apache APISIX, Kong и Gloo используют коммерчески дружественную лицензию Apache License Version 2.0, а Tyk использует Mozilla Public License Version 2.0. Однако, если копнуть глубже, Kong, Gloo и Tky поддерживаются коммерциализированными поставщиками с открытым исходным кодом. Они могут изменить свою лицензию в любой момент, как это сделала MongoDB, ограничивая использование публичными облаками или другими компаниями и вынуждая платить за доступ к новым версиям.

Никто не знает вероятность изменения лицензии. Однако этот риск, как меч Дамокла, висит над пользователями.

В таких условиях выбор проекта с открытым исходным кодом Apache Software Foundation (ASF) или CNCF является лучшим выбором, потому что они не могут изменить лицензию проекта. Apache APISIX — это именно такой проект. Это проект верхнего уровня ASF, что означает, что ни одна коммерческая компания не имеет абсолютного контроля над проектом Apache APISIX, весь код принадлежит ASF, и лицензия не будет изменена. Корпоративные пользователи могут свободно использовать его, не беспокоясь о получении запросов от юристов и отделов соответствия.

Производительность Apache APISIX, Kong и Gloo

Часто задаваемый вопрос в сообществе: какой из них имеет лучшую производительность, Gloo на основе Envoy или APISIX на основе NGINX? Хотя производительность не является самым критическим показателем, это, безусловно, самый прямой показатель. В таблице ниже приведены результаты тестирования Apache APISIX и Gloo. QPS Apache APISIX в 4,6 раза выше, чем у Gloo, а задержка Apache APISIX составляет всего 7% от задержки Gloo.

Выбор NGINX или Envoy не является основным фактором разницы в производительности, но основная оптимизация APISIX в исходном коде. Даже по сравнению с KONG, который также основан на NGINX, APISIX имеет огромное преимущество в производительности. График ниже взят из отчета GigaOm о тестировании корпоративной версии Kong и корпоративной версии AP7 (Вы можете связаться с нами для получения полных данных).

Задержка Kong в десятки или даже сотни раз выше, чем у API7 (корпоративная версия, созданная авторами Apache APISIX).

Почему APISIX имеет такое большое преимущество в производительности? В коде нет секретов.

Разговоры дешевы, покажите мне код

Теперь давайте проанализируем Apache APISIX, Kong и Gloo с технической точки зрения. Преимущество Apache APISIX в основном основано на оптимизации и инновациях в исходном коде. Преимущества этих технологий не обязательно проявляются в простом PoC (Proof of Concept), но видны в более сложной производственной среде.

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

Однако шлюз — это промежуточное программное обеспечение, которое обрабатывает весь трафик от клиента. Требования к доступности чрезвычайно высоки. Если API-шлюз зависит от реляционной базы данных, это означает, что в случае сбоя реляционной базы данных (например, остановки или потери данных) API-шлюз также будет затронут, и доступность всей системы пострадает.

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

1. Это больше соответствует облачной архитектуре.
2. Это лучше отражает тип данных, необходимых для API-шлюза.
3. Это обеспечивает более высокую доступность.
4. Изменения могут быть уведомлены на уровне субмиллисекунд.

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

Высокопроизводительный алгоритм сопоставления маршрутов

Для обработки запроса API-шлюзу необходимо сопоставить целевое выражение с информацией о хосте, URI, методах HTTP и другой информацией каждого запроса. Таким образом, эффективный алгоритм сопоставления имеет решающее значение. Алгоритм на основе хэша имеет хорошую производительность, но не может выполнять нечеткое сопоставление. Регулярные выражения могут выполнять нечеткое сопоставление, но производительность не так хороша. Решение Apache APISIX — использовать дерево, эффективную структуру данных для поиска, которая поддерживает нечеткое сопоставление. Более точно, Apache APISIX использует radix tree (сжатое префиксное дерево), структуру данных, которая сжимает только промежуточные узлы с одним дочерним элементом. Среди всех известных продуктов API-шлюзов Apache APISIX первым применил radix tree для сопоставления маршрутов и поддерживает сценарии, где один префикс может соответствовать нескольким маршрутам. Подробности реализации см. в lua-resty-radixtree.

При сопоставлении запроса алгоритм с radix tree будет сопоставлять его постепенно, с сложностью O(K) (K — длина URI в маршруте, и она не зависит от количества API). Этот алгоритм очень хорошо подходит для сценариев, когда существует большое количество маршрутов, таких как публичные облака или CDN. Он также без проблем справляется с большим количеством маршрутов, которые быстро увеличиваются.

Высокопроизводительный алгоритм сопоставления IP

IP-адрес имеет два обозначения: стандартное обозначение IP и обозначение CIDR, на примере 32-битного IPv4:

• Стандартное обозначение IP: 192.168.1.1
• Обозначение CIDR: 192.168.1.1/8

Сопоставление IP и маршрутов в Apache APISIX использует разные алгоритмы. Возьмем IP 192.168.1.1 в качестве примера, так как диапазон каждого сегмента IP составляет от 0 до 255, мы можем считать, что IP-адрес состоит из четырех 16-битных целых чисел, и длина IP фиксирована. Таким образом, мы можем использовать более эффективный алгоритм для завершения сопоставления.

Предположим, что существует библиотека IP, содержащая 500 записей IPv4, APISIX кэширует эти 500 записей IPv4 в хэш-таблице и использует хэш-таблицу для сопоставления IP. Временная сложность составляет O(1). Другие API-шлюзы выполняют сопоставление IP через итерацию списка, и каждый запрос, отправленный на шлюз, может быть итерирован до 500 раз. Поэтому высокоточный алгоритм сопоставления IP APISIX значительно повышает эффективность сценариев, требующих массового сопоставления списков разрешенных и запрещенных IP (например, WAF).

Уточнение маршрутов

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

Во-первых, Apache APISIX поддерживает встроенные переменные NGINX, что означает, что мы можем использовать десятки встроенных переменных NGINX в качестве параметров сопоставления, включая uri, server_name, server_addr, request_uri, remote_port, remote_addr, query_string, host, hostname, arg_name.

Список встроенных переменных NGINX см. в NGINX Variables.

Во-вторых, Apache APISIX поддерживает условные выражения в качестве правил сопоставления, и его структура выглядит как [var, operator, val], ...]], где:

• Значения var могут быть встроенными переменными NGINX.
• operator поддерживает равенство, больше, меньше, регулярные выражения, содержит и т.д.

Предположим, что выражение ["arg_name", "==", "json"] означает, есть ли в параметрах запроса URI текущего запроса значение параметра name, равное json. Apache APISIX реализует эту функцию через свою библиотеку lua-resty-expr. Подробности см. в lua-resty-expr. Эта функция предоставляет пользователю большую гибкость и высокую расширяемость.

Кроме того, Apache APISIX позволяет пользователям устанавливать время жизни (ttl) маршрутов.

$ curl http://127.0.0.1:9080/apisix/admin/routes/2?ttl=60 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -i -d '
{
    "uri": "/aa/index.html",
    "upstream": {
        "type": "roundrobin",
        "nodes": {
            "39.97.63.215:80": 1
        }
    }
}'

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

Наконец, Apache APISIX поддерживает пользовательские функции фильтрации, можно написать пользовательские функции Lua в параметре filter_func, например:

$ curl http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -i -d '
{
    "uri": "/index.html",
    "hosts": ["foo.com", "*.bar.com"],
    "filter_func": "function(vars)
                    return vars['host'] == 'api7.ai'
                end",
    "upstream": {
        "type": "roundrobin",
        "nodes": {
            "127.0.0.1:1980": 1
        }
    }
}'

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

Поддержка плагинов на нескольких языках

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

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

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

В ответ на эту ситуацию APISIX предлагает два решения.

Первое решение — поддержка более популярных языков программирования (таких как Java, Python, Go и т.д.) через Plugin Runner. Используя Plugin Runner, backend-инженеры могут общаться через локальный RPC для разработки плагинов APISIX на знакомых им языках программирования. Преимущество этого заключается в снижении затрат на разработку и повышении эффективности разработки. Недостатком будут потери производительности. Есть ли способ достичь почти родной производительности Lua с использованием высокоуровневых языков, знакомых разработчикам?

Второе решение — использование Wasm для разработки плагинов, как показано на левой части рисунка выше. Wasm (WebAssembly) изначально использовался как новая технология, работающая в браузерах, но теперь она также постепенно демонстрирует свои преимущества на стороне сервера. Мы встроили Wasm в APISIX, и пользователи могут использовать Wasm для компиляции байткода Wasm для запуска в APISIX. Чтобы использовать Wasm, мы разработали плагин Wasm, где пользователи могут разрабатывать почти родные плагины APISIX с использованием высокоуровневых языков программирования.

В результате пользователи могут использовать Lua, Go, Java, Python, Node.js и Wasm для написания пользовательских плагинов на APISIX. Упрощая разработку, это открывает двери для разработки плагинов APISIX.

Заключение

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

Apache APISIX — это не только API-шлюз, который может обрабатывать северо-южный трафик, но также имеет продукты с открытым исходным кодом, такие как APISIX Ingress Controller и Service Mesh.

Он также предоставляет корпоративные продукты и SaaS-продукты на основе APISIX.

Попробуйте Apache APISIX и корпоративные продукты API7 уже сегодня!