Почему стоит выбрать Apache APISIX вместо NGINX или Kong

API-шлюз является важным компонентом инфраструктуры в эпоху облачных технологий. Существует два основных критерия для оценки API-шлюза: насколько он динамичен и насколько зрелой является его наблюдаемость. Многие компании ранее использовали Nginx или Kong в качестве своего API-шлюза, но затем перешли на Apache APISIX. Как API-шлюз, созданный для эпохи облачных технологий, Apache APISIX действительно решает множество проблем для бизнеса в различных аспектах. Теперь вы можете задаться вопросом: почему?

Ограничения NGINX и Kong

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

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

Kong решает недостатки NGINX, но привносит новые ограничения:

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

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

Преимущества Apache APISIX

Хорошо продуманная архитектура

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

Как показано на рисунке выше, слева и справа находятся Data Plane и Control Plane APISIX:

Data Plane: Основан на сетевой библиотеке NGINX (без использования маршрутизации NGINX, статической конфигурации и C-модулей), использует Lua и NGINX для динамического управления трафиком запросов;
Control Plane: Администраторы могут управлять etcd через встроенный RESTful API. Благодаря механизму Watch etcd, APISIX может синхронизировать конфигурацию на каждый узел за миллисекунды.

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

Поскольку и APISIX, и etcd поддерживают развертывание в нескольких экземплярах, отсутствует единая точка отказа.

Богатая экосистема

На следующем рисунке показана карта экосистемы APISIX. Из этого рисунка видно, что APISIX поддерживает протоколы уровня L7, включая HTTP(S), HTTP2, Dubbo, IoT-протокол MQTT и другие. Кроме того, APISIX поддерживает протоколы уровня L4, такие как TCP/UDP.

Правая часть рисунка содержит некоторые открытые или SaaS-сервисы, такие как Apache SkyWalking, Prometheus, HashiCorp Vault и другие. В нижней части рисунка находятся более распространенные операционные системы, облачные провайдеры и аппаратные среды. Как открытое программное обеспечение, APISIX также может работать на серверах с архитектурой ARM64.

APISIX поддерживает не только множество протоколов и операционных систем, но и плагины для программирования на нескольких языках. Когда APISIX только появился, он поддерживал только использование языка Lua для написания плагинов. В этом случае разработчикам необходимо было освоить стек технологий, связанных с Lua и NGINX. Однако Lua и NGINX являются относительно нишевыми технологиями, знакомыми немногим разработчикам. Поэтому мы затем включили разработку плагинов на APISIX на нескольких языках и официально поддерживаем такие языки, как Java, Golang, Node.js и Python.

Активное сообщество

На следующем рисунке показана кривая роста числа участников, где горизонтальная ось представляет временную шкалу, а вертикальная ось — общее количество участников. Мы видим, что два проекта, Apache APISIX и Kong, являются относительно более активными. Apache APISIX с первого дня поддерживает отличный темп роста и растет почти в два раза быстрее, чем Kong. По состоянию на июль 2022 года количество участников APISIX превысило количество участников Kong, что показывает популярность APISIX. Конечно, существует множество других способов оценить активность проекта, таких как количество активных задач в месяц, общее количество PR и т.д. Хорошая новость заключается в том, что APISIX также непревзойден в этих аспектах.

Унифицированная прокси-инфраструктура

Из следующего рисунка, я уверен, вы уже поняли цель APISIX: унификация прокси-инфраструктуры.

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

Балансировка нагрузки и API-шлюз

Первый сценарий — это традиционные LB и API-шлюзы. Поскольку APISIX реализован на основе NGINX + LuaJIT, он обладает высокой производительностью и функциями безопасности, поддерживает динамическую загрузку SSL-сертификатов, оптимизацию SSL-рукопожатия и другие функции. В плане балансировки нагрузки APISIX также показывает лучшие результаты. Переход с NGINX на APISIX не снижает производительность, а, наоборот, повышает эффективность управления благодаря таким функциям, как унифицированное управление.

Микросервисный шлюз

APISIX позволяет писать расширяющие плагины на нескольких языках, что решает основную проблему, с которой сталкиваются восточно-западные микросервисные API-шлюзы — как управлять в гетерогенных средах. APISIX также поддерживает сервисное обнаружение, такое как Nacos, etcd и Eureka, а также стандартные методы DNS, что позволяет полностью заменить микросервисные API-шлюзы, такие как Zuul, Spring Cloud Gateway и Dubbo.

Kubernetes Ingress

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

APISIX Ingress Controller идеально решает все вышеупомянутые ограничения: он поддерживает полную горячую перезагрузку. В то же время он наследует все преимущества APISIX и также поддерживает нативные CRD Kubernetes, что удобно для миграции пользователей.

Service mesh

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

Итог

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

Если у вас есть вопросы, вы можете оставить сообщение в GitHub issue; участники сообщества быстро ответят; конечно, вы также можете присоединиться к каналу APISIX Slack и списку рассылки; пожалуйста, ознакомьтесь с Join Us.