APISIX стимулирует обновление API Gateway в Tencent BlueKing

Это кейс-стади предоставлено Лей Чжу, техническим директором платформы BlueKing PaaS, IEG (Interactive Entertainment Group), Tencent

О BlueKing

BlueKing — это внутренний набор интегрированных исследований и операций PaaS, разработанный в рамках Tencent IEG (Interactive Entertainment Group), обслуживающий несколько бизнес-подразделений и внутренних платформ. Его роль заключается в предоставлении полного жизненного цикла услуг для проектов компании на этапах CI (Continuous Integration), CD (Continuous Delivery) и CO (Continuous Operation).

Обзор

Проблемы

• Низкая производительность: Низкая производительность в условиях высокой конкуренции и алгоритмов маршрутизации, что приводит к медленному сопоставлению и пересылке маршрутов.
• Высокая нагрузка на базу данных: Политики маршрутизации хранятся в MySQL. Следовательно, база данных испытывает нагрузку из-за большого количества запросов на извлечение данных.
• Высокие затраты: Redis широко используется во многих сценариях, что приводит к высоким накладным расходам.
• Недостаточная изоляция: Невозможно достичь физической изоляции; нестабильные долгосрочные соединения.
• Поддержка одного протокола: Поддерживается только HTTP-протокол.
• Отсутствие динамической маршрутизации: Не поддерживаются динамические правила маршрутизации; неудобно для сценариев canary-релизов и неспособность к сценарной комбинации и инкапсуляции.
• Отсутствие сервиса обнаружения: Неудобно для микросервисной архитектуры.

Цели

• Преобразовать возможности платформы в независимые микросервисы и провести микросервисную трансформацию для формирования архитектуры PaaS.
• Использовать low-code технологии для эффективной разработки SaaS, чтобы использовать микросервисные возможности платформы PaaS.
• Гибко реагировать на различные сервисные сценарии через различные SaaS.

Результаты

• Реализовано единое управление и расширение шлюза с использованием CRD-ресурсов, предоставляемых K8s.
• Предоставлены более богатые функции, интегрированные с APISIX: управление ресурсами, выпуск версий, автоматическая документация, управление правами, наблюдаемость, мониторинг и защита.
• Снижены затраты на поддержку сценариев обнаружения сервисов благодаря унифицированным интерфейсам и правилам для разработчиков.

Разнообразие и сложность игр требуют API-шлюза BlueKing

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

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

Чтобы абстрагировать архитектуру BlueKing, можно получить диаграмму API.

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

• С другой стороны, с развитием облачных технологий многие внутренние SaaS и платформы теперь развернуты в кластерах K8s. Этот сценарий выдвигает новые требования к шлюзу, такие как унифицированное управление трафиком внешних запросов через унифицированный шлюз трафика или API-шлюз.

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

С развитием внутренних бизнес-требований API-шлюз BlueKing должен поддерживать все более разнообразные сценарии.

API-шлюз BlueKing 1.0

API-шлюз BlueKing 1.0 был разработан для того, чтобы вызывающие платформы (включая различные SaaS и процессные движки) могли напрямую вызывать API-шлюз для завершения преобразования протоколов и проверки прав через шлюз.

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

Спустя несколько лет, с увеличением количества запросов и сложных сценариев, недостатки API-шлюза BlueKing 1.0 начали постепенно проявляться. Например:

• Низкая производительность фреймворка: Для реализации был выбран фреймворк Django. Его производительность средняя в сценариях с высокой конкуренцией и становится недостаточной при обработке большого количества запросов.

• Средняя производительность реализации маршрутизации: Производительность алгоритма, используемого в маршрутизации API, низкая, что влияет на скорость сопоставления и пересылки маршрутов.

• Высокая нагрузка на базы данных: Все политики маршрутизации хранятся в MySQL. Когда правил много, требуется много запросов на извлечение данных, что создает высокую нагрузку на базу данных.

• Высокие сетевые затраты: Redis широко используется в различных сценариях, что приводит к высоким сетевым накладным расходам.

API-шлюз BlueKing 2.0

Для решения вышеуказанных проблем BlueKing провел итерацию на основе версии 1.0 и разработал и реализовал версию 2.0. По сравнению с предыдущей версией, наиболее значительным изменением версии 2.0 стала повторная реализация фреймворка шлюза и уровня пересылки на Golang, поскольку Golang имеет больше преимуществ перед Python в обработке большого количества одновременных запросов.

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

В целом, API-шлюз BlueKing 2.0 решает проблемы производительности и большинство болевых точек, с которыми столкнулись в версии 1.0. Но со временем новые проблемы начали постепенно проявляться.

• Недостаточная изоляция: Невозможно достичь реальной физической изоляции; процесс выпуска приводит к разрыву долгосрочных соединений.

• Поддержка одного протокола: Поддерживается только HTTP, а в реальных сценариях растет спрос на не-HTTP протоколы.

• Отсутствие динамических правил маршрутизации: Не поддерживаются динамические правила маршрутизации, сопоставляемые по условиям; недостаточно удобно для сценариев canary-релизов; неспособность к сценарной комбинации и инкапсуляции.

• Отсутствие возможности обнаружения сервисов: Отсутствует автоматическое обнаружение сервисов, что неудобно для микросервисной архитектуры.

APISIX выделяется в выборе технологий для API-шлюза BlueKing

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

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

Компоненты архитектуры распределенного шлюза в основном делятся на две категории: управляющая часть и экземпляры микрогейтов.

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

"В выборе технологий для микрогейта мы рассмотрели несколько популярных открытых шлюзов на рынке, таких как Kong и Tyk. После сравнения популярности, технологического стека, поддержки протоколов и других уровней мы в итоге выбрали APISIX в качестве основной технологии для нашего микрогейта." — сказал Чжу.

Чжу сказал, что BlueKing выбрал APISIX, потому что он реализован на основе NGINX + Lua, поэтому его общая производительность имеет преимущества по сравнению с теми, которые основаны на Golang. Кроме того, APISIX выделяется своей масштабируемостью, а также поддерживает расширение возможностей через плагины на нескольких языках программирования. Было замечено множество типичных случаев использования.

Кроме того, благодаря своей отличной совместимости, APISIX может быть настроен в соответствии с потребностями BlueKing. Например, на основе APISIX BlueKing настроил управляющую поверхность APISIX в соответствии с внутренними требованиями.

API-шлюз BlueKing 3.0 на основе APISIX

В облачной среде K8s является наиболее важным базовым компонентом, который требует внимания. Поскольку весь микрогейт разработан для облачной среды, версия 3.0 имеет новую архитектурную разработку на основе K8s.

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

Как показано на рисунке выше, шлюз вводит набор ресурсов K8s CRD, включая BkGatewayStage (среда шлюза), BkGatewayService (сервис бэкенда) и т.д. С помощью этих CRD BlueKing может контролировать конкретное поведение каждого экземпляра микрогейта.

Несколько "Операторов" на рисунке являются ключевой частью этой архитектуры. Вверху находится сервис Plugin Operators, который содержит ряд плагинов-операторов. Например, оператор, отвечающий за обнаружение сервисов, запишет адрес сервиса бэкенда, зарегистрированного в центре обнаружения сервисов, в кластер K8s.

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

Этот набор микрогейтов делится на два типа развертывания:

• Общий шлюз: Тип по умолчанию, который развернут на платформе, и адрес доступа к API генерируется и управляется платформой.

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

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

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

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

Практические сценарии использования шлюза BlueKing 3.0 с APISIX

Внутри Tencent существует четыре типичных практических сценария: обнаружение сервисов, унифицированная аутентификация, динамическая маршрутизация и управление лицензиями клиента.

Обнаружение сервисов

Обнаружение сервисов — это базовая возможность, необходимая для микросервисной архитектуры. Внутри это может быть реализовано через пользовательские ресурсы CRD. Действительное определение YAML для обнаружения сервисов показано в коде на правой стороне рисунка ниже.

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

Затем согласователь считывает соответствующую информацию о адресах из центра обнаружения сервисов через встроенные интерфейсы обнаружения сервисов, такие как Watcher и Lister, и перезаписывает полученные адреса обратно в кластер K8s через ресурс CRD BkGatewayEndpoints.

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

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

Унифицированная аутентификация

Часть унифицированной аутентификации относительно проста. В повседневной практике есть запросы из трех источников: браузеры, платформы и отдельные пользователи. На основе APISIX BlueKing настроил плагин аутентификации BK-Auth для достижения унифицированной аутентификации.

Конкретный процесс реализации показан на рисунке выше. После запроса плагин считывает соответствующую информацию о учетных данных из заголовка, а затем единообразно вызывает сервис аутентификации BK-Auth для проверки учетных данных и считывания соответствующей информации о SaaS. Затем плагин использует приватный ключ, согласованный с бэкендом, для выпуска JWT-токена и записи его в заголовок запроса, и, наконец, записывает его в переменную APISIX.

Помимо унифицированной аутентификации, во внутренних проектах также есть некоторые сложные сценарии аутентификации. Его основная функция заключается в проверке, имеет ли SaaS право доступа, когда SaaS вызывает определенный ресурс платформы. Унифицированная аутентификация ресурсов также реализована на Golang через плагин APISIX, как показано на рисунке ниже.

Клиентские запросы могут сначала получить информацию о приложении SaaS через этап аутентификации, затем взаимодействовать с плагином аутентификации на основе RPC при прохождении ext-plugin. В этот момент плагин аутентификации будет напрямую запрашивать данные, связанные с аутентификацией, в кэше, синхронизированном управляющей частью через механизм полного и инкрементального обновления, а затем завершает аутентификацию.

Динамическая маршрутизация

Типичный сценарий применения динамической маршрутизации исходит из платформы управления контейнерами BlueKing. Платформа контейнеров BlueKing управляет множеством кластеров K8s, некоторые из которых являются сервисными кластерами, а некоторые — кластерами данных.

Как пользователь, вам часто нужно запрашивать APIServers этих кластеров. Когда пользовательский запрос попадает в микрогейт, шлюз определяет, в какой APIServer кластера его переслать, на основе пути запроса.

После того как запрос попадает внутрь, плагин динамической маршрутизации сначала извлекает информацию о ID кластера, затем переписывает маршрут и определяет, подключен ли кластер напрямую.

Для кластеров, не подключенных напрямую, сначала генерируется вышестоящий сервис BCS Cluster Manager, а затем взаимодействие с BCS Agent происходит через него, и, наконец, запрос передается в APIServer кластера.

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

Управление сертификатами клиента

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

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

Этот процесс использует некоторые ресурсы CRD и официальные ресурсы Secret K8s и будет непрерывно согласовываться центральным сервисом оператора, например, поиск соответствующего сертификата по доменному имени. Эффективная конфигурация сертификата клиента в конечном итоге отражается в соответствующей конфигурации APISIX Service. (Как показано в красной рамке в верхнем правом углу рисунка выше)

Итог

Apache APISIX — это открытый, динамический, масштабируемый и высокопроизводительный облачный API-шлюз для всех ваших API и микросервисов. Будучи переданным в Apache Software Foundation компанией API7.ai, APISIX вырос в топовый открытый проект Apache.

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