Технические исследования Open-Source API Gateway Apache APISIX
Предыстория
Apache APISIX — это динамичный, высокопроизводительный API-шлюз с открытым исходным кодом, который предоставляет богатые функции управления трафиком, такие как балансировка нагрузки, динамическая маршрутизация, канареечные выпуски, разрыв цепи, аутентификация и наблюдаемость.
Как API-шлюз, Apache APISIX помогает предприятиям быстро и безопасно обрабатывать API и микросервисный трафик в таких сценариях, как шлюзы, Kubernetes Ingress и сервисные сетки. Кроме того, он может обрабатывать север-южный трафик от клиента к серверу и восточно-западный трафик между различными микросервисами предприятия.
APISIX был открыт 6 июня 2019 года, а в октябре 2019 года был передан в Apache Software Foundation и быстро стал топовым проектом Apache Software Foundation в течение нескольких месяцев.
Почему APISIX так быстро стал популярным? Какие технические инновации были сделаны в APISIX? Почему всё больше разработчиков и предприятий выбирают APISIX? Давайте разберёмся.
Основные функции Apache APISIX
Независимость от баз данных
До появления APISIX существовало множество коммерческих и открытых API-шлюзов. Однако большинство этих продуктов хранят свои данные API, конфигурации, сертификаты и маршруты в реляционных базах данных.
Очевидные преимущества хранения в реляционной базе данных заключаются в удобстве выполнения гибких запросов с помощью SQL, а также в простоте резервного копирования и последующего обслуживания.
Однако у каждой медали есть две стороны. Как базовое промежуточное ПО, API-шлюз обрабатывает весь клиентский трафик, что повышает требования к доступности. Если ваш API-шлюз зависит от реляционной базы данных, то при возникновении ошибки в базе данных, такой как сбой или потеря данных, шлюз также пострадает. Это ограничивает общую доступность системы.
Поэтому разработчики APISIX постарались избежать таких проблем на уровне архитектуры.
Архитектура APISIX разделена на две части. Первая часть, называемая плоскостью данных, обрабатывает запросы и трафик клиентов. Она поддерживает аутентификацию, выгрузку сертификатов, анализ логов и наблюдаемость. Плоскость данных не хранит данные, что делает её безсостоятельной структурой.
Вторая часть — это плоскость управления. APISIX не использует традиционные базы данных, такие как MySQL, а вместо этого использует etcd на плоскости управления.
Преимущества такого подхода:
- Более унифицированная архитектура с облачными продуктами
- Более подходящая для типов данных, хранимых API-шлюзом
- Лучше отражает характеристики высокой доступности
- Уведомления об изменениях за миллисекунды
Используя etcd, плоскость данных просто отслеживает изменения в etcd. Если вы опрашиваете базу данных, это может занять 5-10 секунд для получения последней конфигурации. Однако, если вы отслеживаете изменения в etcd, вы можете получить обратную связь в течение миллисекунд, что обеспечивает эффект реального времени.
Таким образом, использование etcd вместо реляционной базы данных делает APISIX более совместимым с облачной средой на уровне архитектуры и усиливает его преимущества высокой доступности.
Плагины для нескольких языков программирования
API-шлюзы несколько отличаются от баз данных и другого промежуточного ПО. По сравнению с последними, шлюзы чаще используются в кастомизированной разработке и интеграции систем.
Хотя APISIX выпустил множество официальных плагинов, всё же сложно охватить все сценарии использования для разных пользователей. Поэтому на практике часто требуется разрабатывать кастомные плагины для бизнеса. APISIX также интегрирует больше протоколов или систем через шлюз, что позволяет достичь единого управления на уровне шлюза.
Изначально APISIX поддерживал разработку плагинов только на языке Lua. Преимущество заключается в том, что разработанные плагины могут быть высокопроизводительными благодаря оптимизации на уровне языка. Однако есть и очевидный недостаток: изучение нового языка, такого как Lua, требует времени и затрат.
APISIX решает эту проблему двумя способами.
Первый способ — поддержка более популярных языков программирования, таких как Java, Python, Go, через Runner Plugin. Если вы backend-разработчик, вы, вероятно, знаете хотя бы один из этих языков; тогда вы можете легко использовать протокол RPC и разработать плагин для APISIX на знакомом вам языке.
С одной стороны, это снижает затраты на разработку и повышает её эффективность. Однако с другой стороны, на уровне производительности может возникать задержка. Возникает вопрос: есть ли решение, которое может обеспечить нативную производительность Lua и при этом учитывать высокоуровневые языки?
Второй способ, показанный на левой части изображения выше, — это использование WebAssembly. Изначально WebAssembly использовался как технология на стороне клиента или в браузере, но постепенно его преимущества стали применяться и на стороне сервера.
Встраивая WebAssembly в APISIX, пользователи могут компилировать код в байткод WebAssembly, который будет выполняться в APISIX. В результате можно эффективно разрабатывать плагины для APISIX, которые будут одновременно высокопроизводительными и написанными на высокоуровневых языках программирования.
Таким образом, в текущей версии APISIX пользователи могут использовать Lua, Go, Python, Wasm и другие методы для кастомизации кода на основе APISIX. Это снижает порог входа для разработчиков и предоставляет больше возможностей для функциональности APISIX.
Горячая перезагрузка плагинов
APISIX имеет два значительных преимущества по сравнению с NGINX: поддержка кластерного управления и динамической перезагрузки.
Если вы использовали NGINX, вы знаете, что все конфигурации NGINX записываются в файл nginx.conf. Для управления кластером необходимо изменять файл nginx.conf на каждом сервере. В этом процессе отсутствует централизованное управление. Каждый NGINX представляет собой комбинацию плоскости данных и плоскости управления. Если у вас десятки или сотни серверов NGINX, затраты на управление будут чрезвычайно высокими.
В упомянутом сценарии каждый сервер NGINX требует перезагрузки после изменения файла nginx.conf. Например, для обновления сертификатов или изменений upstream необходимо сначала изменить конфигурационный файл, а затем перезагрузить сервер, чтобы изменения вступили в силу. Этот метод может быть приемлемым, если ваш запрос не слишком большой. Однако с увеличением количества API и микросервисов влияние на клиента будет огромным, если серверу потребуется перезагрузка для каждого изменения.
- Горячие обновления и плагины: Постоянно обновляет свои конфигурации и плагины без перезагрузок!
- Proxy Rewrite: Поддержка перезаписи хоста, URI, схемы, метода и заголовков запроса перед отправкой на upstream.
- Response Rewrite: Установка кастомного статуса ответа, тела и заголовков для клиента.
- Динамическая балансировка нагрузки: Круговой алгоритм балансировки нагрузки с весами.
- Балансировка нагрузки на основе хэша: Балансировка нагрузки с использованием хэширования сессий.
- Проверка здоровья: Включение проверки здоровья узлов upstream и автоматическая фильтрация нездоровых узлов при балансировке нагрузки для обеспечения стабильности системы.
- Разрыв цепи: Интеллектуальное отслеживание нездоровых сервисов upstream.
- Proxy Mirror: Возможность зеркалирования клиентских запросов.
- Разделение трафика: Позволяет пользователям направлять проценты трафика между различными upstream.
На изображении выше перечислены компоненты, в которых APISIX в настоящее время реализует горячую перезагрузку. Мы видим, что код вступает в силу в реальном времени, начиная с upstream и заканчивая сертификатами и даже плагинами. Некоторые участники сообщества могут понять, почему upstream и сертификаты динамичны, так как данные часто меняются. Однако они могут задаться вопросом, почему изменения плагинов должны быть динамичными, считая, что изменение плагинов происходит редко и не требует высокой активности.
Как разработчики APISIX, мы стремимся к тому, чтобы шлюз был полностью динамичным, что открывает больше возможностей для предприятий. Например, пользователи могут устранять неполадки в коде, изменяя плагин для отладки, без необходимости перезапуска. В таких случаях пользователь может воспроизвести проблему в любое время и записать её без перезагрузки. Плагин с функцией отладки в сочетании с механизмом горячей перезагрузки будет очень гибким, что поможет разработчикам сэкономить время и усилия при устранении неполадок.
Динамическая оркестрация плагинов
Помимо горячей перезагрузки, APISIX поддерживает динамическую оркестрацию между плагинами в реальном времени. Динамическая оркестрация также открывает бесконечные возможности для работы с плагинами.
Что такое оркестрация плагинов? Когда мы ставим различные требования, мы хотим превратить запрос в плагин, как будто играем в LEGO. Мы можем создавать бесконечное количество возможных форм через единый стандарт, такой как совместимость форм и пересечение, что является одной из радостей LEGO. Для плагинов APISIX каждый плагин выполняет независимую задачу. Мы не можем не задаться вопросом, возможно ли позволить пользователям кастомизировать свои потребности с помощью плагинов, как будто они играют в LEGO.
Например, если в APISIX есть 100 плагинов, пользователи видят только функции этих 100 плагинов, а не их гибкость на уровне архитектуры. Поэтому при разработке промежуточного ПО мы должны учитывать, что может быть продуктом и как наделить его большими возможностями, когда люди его используют.
В настоящее время APISIX имеет около 100 плагинов, но у него гораздо больше возможностей. Следовательно, после разработки возможности оркестрации плагинов комбинации становятся 100 * 99 * 98 * 97 * 96 * ..., что приближается к бесконечности.
Например, ошибка обычно возникает после ограничения скорости пользователя. Вы можете попробовать подключить плагин логирования или плагин отчётов об ошибках для последующей записи активности. На изображении ниже показана модель оркестрации плагинов APISIX.
Эта функция имеет скрытое преимущество: полный набор тестов покрывает код каждого плагина. Когда пользователь оркестрирует плагины, ему не нужно писать код. Это будет крайне удобно для менеджеров продуктов, инженеров безопасности и инженеров по эксплуатации, которым не нужно тратить много времени на обучение. Вместо этого они могут создавать новые плагины APISIX, просто перетаскивая плагины и настраивая параметры. Кроме того, качество кода нового плагина будет таким же высоким, как и у официального кода APISIX.
Шлюз для всестороннего трафика
Инженеры, занимающиеся разработкой шлюзов, могут быть знакомы с двумя основными концепциями: Север-Южный трафик, который относится к трафику от клиентов, браузеров или устройств Интернета вещей (IoT) к серверу, и Восточно-Западный трафик, который относится к взаимным вызовам между системами и микросервисами внутри предприятий.
Компоненты, обрабатывающие север-южный и восточно-западный трафик, различаются. Например, север-южный трафик может проходить через балансировщик нагрузки, попадать в API-шлюз, а затем в сервисный шлюз. Именно поэтому существуют такие компоненты, как NGINX, APISIX и Spring Cloud Gateway. При обработке восточно-западного трафика с помощью сервисной сетки вы можете использовать такие компоненты, как Envoy, что кажется много, но если сосредоточиться на их функциях, можно найти их сходства. Большинство из них — это плагины для маршрутизации, динамического upstream и безопасной аутентификации. В таком случае, можем ли мы унифицировать компоненты, обрабатывающие север-южный и восточно-западный трафик? Идеальный способ — это когда запрос клиента попадает на сервер, он полностью обрабатывается APISIX. Независимо от того, север-южный это или восточно-западный трафик, весь трафик и данные контролируются через плоскость управления. Это вполне достижимо с текущими технологиями APISIX.
Некоторые из наших пользователей уже подтвердили, что этот режим может значительно снизить затраты на эксплуатацию и обслуживание. В то же время это может снизить сложность, тем самым повышая скорость отклика всей системы. Более того, такие положительные отзывы дают более чёткое направление для последующих итераций APISIX, позволяя APISIX пробовать больше функций и ролей на уровне шлюза для всего трафика.
Поддержка нескольких компонентов для обнаружения сервисов
Шлюз — это фундаментальный, но важный компонент. Он обрабатывает все клиентские запросы и интегрируется с различными системами и открытыми проектами, что ещё более важно.
Другой важный компонент — обнаружение и регистрация сервисов — будет использоваться при интеграции с другими элементами. Пользователи размещают различные сервисы в отдельных частях, таких как Eureka и Nacos. Следовательно, в крупных и долгоживущих ИТ-системах часто сосуществуют несколько компонентов для обнаружения сервисов.
В такой ситуации все входы и выходы трафика становятся шлюзами. Почти все шлюзы поддерживают только одно обнаружение сервисов. Вам нужно указать отдельный компонент Nacos для обнаружения сервисов на маршруте A и другой компонент Consul на маршруте B. Следовательно, вам нужно развернуть несколько шлюзов, чтобы соответствовать определённым шлюзам для разных компонентов обнаружения сервисов.
В настоящее время APISIX не только поддерживает обнаружение сервисов на плоскости данных, но и постепенно поддерживает компоненты регистрации и обнаружения сервисов на плоскости управления. Это высокоэффективное решение для некоторых крупных и долгосрочных корпоративных сервисов. Вы можете легко подключиться к различным компонентам обнаружения и регистрации сервисов, развернув только один API-шлюз.
Исследование сценариев мультиоблачных и гибридных облаков
Если пользователи развертывают шлюз в производственной среде, оснащённой облачной архитектурой, мультиоблачные и гибридные облака должны быть долгосрочным техническим сценарием. С другой стороны, если APISIX настроен с полным набором функций, производительностью, плагинами и поддержкой нескольких компонентов для обнаружения сервисов, проблема неизбежно возникает в том, как сделать так, чтобы пользователи могли лучше работать в производственной среде. Мультиоблачные и гибридные облачные сценарии приносят больше вызовов для APISIX. Поэтому необходимо учитывать больше деталей, как описано ниже.
1. Поддержка mTLS как для upstream, так и для downstream
Ранее мы не считали, что функция поддержки mTLS для upstream имеет высокий приоритет. Однако в сценариях кросс-облачных сред upstream может быть сервисом в другом облаке или даже стать другим SaaS-сервисом. Таким образом, необходимо поддерживать mTLS для upstream, чтобы повысить безопасность данных.
2. Полное разделение архитектуры плоскости управления и плоскости данных
В прошлом году были выявлены несколько уязвимостей безопасности APISIX, большинство из которых связано с гибридным развёртыванием его плоскостей управления и данных. Другими словами, плоскости управления и данных находятся в одном сервисе после запуска сервиса APISIX. Поэтому, если хакер проникает в определённую плоскость данных через уязвимость, он также может получить доступ к плоскости управления и контролировать все данные, что приводит к катастрофическим последствиям.
3. Усиление управления безопасностью
Шлюз обычно хранит некоторые чувствительные данные. Например, некоторые пользователи могут хранить SSL-сертификаты или критическую информацию для подключения к etcd на шлюзе. В таких случаях, если etcd или плоскость данных будут скомпрометированы, это может привести к серьёзной утечке данных. Следовательно, при хранении важной информации необходимо рассмотреть использование компонента, предназначенного для хранения ключей, такого как Vault, для защиты чувствительных данных.
4. Интеграция большего количества облачных стандартов
Мы намерены обеспечить, чтобы пользователи могли беспрепятственно работать на различных облачных платформах без необходимости настройки в мультиоблачных сценариях. Это не означает, что пользователям нужно настраивать кастомные плагины, но APISIX напрямую интегрирует стандарты, API или другие сервисы из различных облаков. Такой подход помогает пользователям адаптироваться заранее и обеспечивает удобство и комфорт при последующем использовании.
Поддержка Apache APISIX
На протяжении истории развития APISIX было сделано множество технических инноваций. Растущее сообщество разработчиков работает рука об руку с момента создания кода, чтобы превратить APISIX в интегрированный API-шлюз. Сегодня APISIX поддерживает быстрые итерации благодаря усилиям сторонников.
Итерации и обновления открытого продукта должны быть приписаны вкладу разработчиков и пользователей.
Когда APISIX был передан в Apache Software Foundation три года назад, это был незрелый проект с всего 20 разработчиками. К счастью, благодаря быстрому развитию APISIX привлёк больше пользователей, разработчиков и предприятий по всему миру. Например, среди наших клиентов такие компании, как Tencent, WPS, Sina Weibo и iQiyi, которые обрабатывают десятки миллиардов API-вызовов ежедневно. Более того, многие международные пользователи из различных отраслей, такие как NASA, European Factory Platform, Swisscom и другие, также входят в список наших клиентов.
Возьмём, к примеру, WPS. Это китайская компания, предоставляющая SaaS-офисное ПО, аналогичное Microsoft Office 365. Независимо от того, работаете ли вы с несколькими людьми на мобильных устройствах, в браузерах или на терминалах, десятки или сотни пользователей могут редактировать один и тот же документ и видеть изменения в реальном времени. Эта функция реализована через множество API-вызовов.
Большинство гигантов обрабатывают десятки миллиардов API-вызовов с пиковым значением QPS, превышающим миллион. Такой масштаб использования также позволяет APISIX получать обратную связь от реальных пользователей в крупных масштабах. Благодаря поддержке этих корпоративных пользователей APISIX быстро развился в зрелый открытый проект.
Кроме того, многие пользователи также делятся своим опытом или итерациями функций кода при использовании APISIX в сообществе, что способствует взаимной выгоде и win-win для обеих сторон. Это демонстрирует, что пользователи воспринимают APISIX не только как хороший продукт, но и как достойный открытый проект. Только после того, как мы завоюем доверие разработчиков, у нас появится возможность стать ценным открытым проектом.
Разработчики адаптируют опыт и обратную связь для создания множества функций продукта; пользователи могут использовать эти функции для принесения ценности предприятиям. Возникает добродетельный круг, что и является сутью открытого исходного кода. Мы всегда стремимся к этой истине, а не слепо преследуем пузыри многочисленных последователей.
Предварительный обзор APISIX 3.0
До сих пор мы много говорили о том, что APISIX сделал в прошлом и делает сейчас. Процесс развития APISIX можно разделить на несколько этапов.
APISIX 1.0 был создан для построения его фреймворка, укрепления базовой архитектуры и представления некоторых основных функций API-шлюза. В версии 2.0 мы углубились в исследования, сделав базовый уровень более гибким, а архитектуру — более зрелой.
Для зрелого открытого проекта признаком его зрелости является не столько его великолепная функциональность, сколько улучшение опыта для пользователей и разработчиков.
На текущем этапе APISIX провёл множество технических исследований и инноваций, но не полностью учитывал опыт пользователей. Проблема проявляется в нестабильном качестве документации и отсутствии обучающих видео. Поэтому многие пользователи теряются, когда впервые сталкиваются с APISIX. Они не знают, как его использовать или применять определённые функции в различных случаях, и не уверены, какую уникальную ценность APISIX может принести предприятиям.
Поэтому в следующей версии APISIX 3.0 мы постараемся решить подобные проблемы и переработать многие недостатки, недружелюбные к опыту разработчиков. Например, мы переработаем API, чтобы убрать зависимость от определённых возвращаемых значений etcd, и обновим официальную документацию, чтобы она стала более удобной для пользователей с простыми описаниями. На уровне функций плоскость управления и плоскость данных также будут разделены для повышения безопасности; будет добавлена поддержка большего количества протоколов уровня 4 и RPC-протоколов, чтобы пользователи могли быстро получать трафик со всех направлений шлюза.
После реализации вышеуказанных функций APISIX 3.0 станет более безопасным, надёжным и удобным в использовании. Мы всегда уделяем внимание отличной работе и опыту пользователей. Мы надеемся, что APISIX сможет обрабатывать запросы от всех API и микросервисов по всему миру и помогать предприятиям более эффективно управлять API и микросервисным трафиком.
Ожидается, что APISIX выпустит новую версию 3.0 в конце 2022 года. Мы надеемся, что вы будете продолжать следить за трендами последней версии APISIX и активно участвовать в разработке проекта Apache APISIX.
Будущее APISIX
Развитие и замена серверных технологий происходят очень быстро, так как многие популярные технологии и фреймворки пятилетней давности постепенно уходят в прошлое. Причина не в том, что инженеры предпочитают новые вещи, а в том, что эти технологии не могут удовлетворить реальные потребности инженеров и предприятий. Их судьба предрешена: быть вытесненными. Важная реальность говорит нам, что технологии должны служить бизнесу и продуктам и не могут выжить, если не соответствуют текущим рыночным потребностям.
"Не стройте замок на болоте." Эта поговорка всегда напоминает разработчикам Apache APISIX, что они должны опираться на реальные потребности и сценарии для руководства развитием и эволюцией продукта. В противном случае продукт постепенно будет забыт инженерами.
Как мы можем поддерживать технологическое лидерство Apache APISIX в отрасли? Это ключевой вопрос, который определяет, сможет ли Apache APISIX продолжать привлекать разработчиков и корпоративных пользователей в будущем. Ответ прост: присоединяйтесь к быстрорастущим компаниям и инженерам, растите вместе и поддерживайте друг друга. Это позволяет Apache APISIX всегда оставаться на переднем крае технологий. Только так APISIX сможет стать мировым вечнозелёным открытым проектом.
Будущее APISIX заключается в лучшей поддержке сценариев Serverless, улучшении сервисной сетки, создании платформ для полного жизненного цикла API и улучшении пользовательского опыта на публичных облаках. Эти планы разрабатываются не несколькими внутренними разработчиками, а тысячами разработчиков в отрасли. Поэтому присоединяйтесь к нам, чтобы ощутить очарование открытого исходного кода!