Практика использования API Gateway в Tencent с Apache APISIX

Что такое API Gateway?

Традиционная архитектура

До интеграции с API Gateway у нас было несколько способов повторного использования некоторых общих функций, таких как:

• Безопасность: аутентификация, авторизация, защита от повторного воспроизведения, защита от подделки, защита от DDoS и т.д.
• Надежность: снижение качества обслуживания, предохранители, ограничение трафика и т.д.

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

Традиционная архитектурная схема включает следующие модули.

• Backend: Бэкенд-сервисы
• AOP: Слой AOP, поддерживаемый фреймворком;
• SD: Сервисный центр, используемый для внутреннего обнаружения сервисов. В облачных технологиях мы часто используем Service для замены этого компонента;
• LB: Балансировщик нагрузки, который мы используем на сетевой границе в качестве точки входа для внешнего трафика.

Такая архитектура была широко распространена в проектировании ранних лет, что привело к созданию множества обширных и всеобъемлющих сервисных фреймворков, таких как Dubbo, SpringCloud и т.д., и мы обнаружим, что большинство из них имеют множество схожих функций.

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

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

Почему бы не разместить эти общие функции в отдельном сервисе, который можно обновлять или поддерживать отдельно?

Режим шлюза

По сравнению с традиционной архитектурой, мы видим дополнительный компонент между бэкенд-сервисами и LB: Gateway.

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

• Шлюз является зависимым компонентом в системах, и мы можем получить лучший опыт обслуживания.
• Шлюз не зависит от языка.

Однако режим шлюза также имеет свои недостатки:

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

Как сбалансировать преимущества и недостатки модели шлюза — это вызов для технической команды. Давайте посмотрим, как Tencent OTeam работает с Apache APISIX.

Введение

OTeam

OTeam Tencent — это группа команд, и каждая команда поддерживает один или несколько технических продуктов. Их цель — создать стабильную, но мощную платформу для внутренних систем. Одна из OTeam поддерживает внутреннюю кастомизированную версию Apache APISIX в Tencent.

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

Некоторые Oteams включают в себя до десятка продуктов, в то время как другие имеют только один. Например, Oteam, в которой находится Apache APISIX, включает только один продукт — Apache APISIX. Изначальная цель этой Oteam — поддерживать кастомизированные функции Apache APISIX внутри Tencent.

Apache APISIX

Apache APISIX — это проект высшего уровня от Apache Software Foundation, и вот некоторые ключевые моменты:

• Apache APISIX — это облачный, динамический API-шлюз на основе OpenResty, с более высокой производительностью маршрутизации, чем у Kong.
• Apache APISIX предоставляет богатые функции управления трафиком, такие как балансировка нагрузки, динамический апстрим, канареечные выпуски, предохранители, аутентификация, наблюдаемость и многое другое.
• Apache APISIX хорошо справляется с традиционным северо-южным трафиком, а также с восточно-западным трафиком между сервисами. Он также может использоваться как контроллер ingress для k8s.
• Apache APISIX по умолчанию использует ETCD в качестве центра конфигурации, что позволяет обновлять конфигурацию за секунды.
• Apache APISIX выпустился из Apache Software Foundation всего за несколько месяцев.

Стратегия работы OTeam Tencent

На приведенной выше схеме показано, как OTeam взаимодействует с сообществом Apache APISIX:

• Пользователи оставляют отзывы или запросы через GitHub Issue.
• Члены OTeam обсуждают решения на еженедельных встречах или отвечают непосредственно в Issue.
• Реализуют функции или исправляют ошибки в соответствии с обсуждением.
• Проводят Code Review и проверку CI, затем выпускают, если необходимо.

Этот процесс похож на другие проекты с открытым исходным кодом. Вот некоторые ключевые моменты:

• После решения Issue инженеры Tencent определяют, является ли проблема также общей для сообщества. Если да, они создают PR для сообщества.
• OTeam Tencent регулярно проверяет новые функции Apache APISIX, чтобы определить, стабильны ли они и являются ли они также болевой точкой для Tencent. Если ответ положительный, выбирают соответствующий код.

Вначале OTeam синхронизировала код с Apache APISIX каждые 12 часов, чтобы быстро следить за Apache APISIX, но этот подход вызвал некоторые проблемы:

• После синхронизации кода с Apache APISIX мы могли убедиться, что правила корректны, но не могли гарантировать стабильность кода. Некоторые случайные ошибки происходили в случаях конкурентности.
• Объединенный код иногда вызывал логические конфликты с несколькими PR вверх по течению, но CI Apache APISIX и OTeam не мог обнаружить этот случай. Только при слиянии PR в мастер-ветку мы могли обнаружить, что что-то пошло не так.

По этим причинам OTeam теперь переходит к выбору кода для требуемых функций после внутренних обзоров.

Тенденции OTeam

По состоянию на май 2021 года OTeam внедрила Apache APISIX для более чем десяти команд внутри Tencent, с ежедневным объемом запросов бизнеса, превышающим миллиард. В то же время OTeam также разработала более десяти функций для Apache APISIX, включая обнаружение сервисов, преобразование протоколов RPC и подключение к платформе мониторинга.

В то же время OTeam также внесла некоторые стандартные функции в сообщество Apache APISIX. В настоящее время два члена команды OTeam также являются PMC Apache APISIX, и OTeam внесла более 50 PR в сообщество. Мы верим, что OTeam продолжит сотрудничество с сообществом Apache APISIX в будущем.

Внутренние функции OTeam

Внутренние болевые точки

Основная ответственность OTeam — поддерживать функции Apache APISIX для Tencent. Давайте рассмотрим, с какими болевыми точками столкнулась OTeam.

• RPC-фреймворк не дружелюбен к фронтенду: внутри Tencent есть множество устаревших проектов, использующих фреймворк TARS, который не поддерживает напрямую HTTP-протокол, как TRPC, он поддерживает только самый традиционный TCP-протокол RPC-фреймворка, а транспортное содержимое использует специфический бинарный протокол. Нам нужно поддерживать промежуточный сервис для преобразования этих интерфейсов в дружелюбную для фронтенда форму HTTP + JSON.
• Разнообразие сервисных центров: Внутренние сервисы Tencent используют множество сервисных центров, таких как CL5, L5, Polaris и т.д. Хотя мы постепенно будем использовать один и тот же сервисный центр, в течение этого длительного периода мы будем использовать несколько сервисных центров одновременно. Изначально Apache APISIX не поддерживал это.
• Оповещения: Как шлюз, оповещения не являются направлением, на которое он должен обращать внимание, но как фундаментальный компонент, оповещения должны быть обязательным компонентом для команды. Как решить проблему оповещений — это также болевая точка.
• Безопасность: Tencent имеет огромный объем трафика и требования к безопасности. Многие продукты toC используют OTeam, и они сталкиваются с множеством злоупотреблений пользователей и атак из сети. Наиболее типичные случаи — это DDos, повторное воспроизведение, подделка запросов и т.д. Можем ли мы решить эти проблемы на уровне шлюза?

Решение проблем

Приведенная выше схема является упрощением случая внедрения внутри Tencent. Мы видим, что несколько проблем, поднятых ранее, были решены в OTeam:

• Преобразование протоколов: на основе Apache APISIX OTeam достигает преобразования протоколов TRPC и TARS. Те, кто не использует HTTP для устаревших сервисов, могут напрямую использовать плагин преобразования в шлюзе для достижения требований передачи HTTP и RPC без написания промежуточных сервисов.
• Множество сервисных центров: Мы внесли эту функцию в сообщество. Отчеты на платформу мониторинга: OTeam Tencent использует плагины для подключения к платформам мониторинга. Пользователям нужно только выполнить некоторые настройки, и система автоматически будет отправлять метрики, логи. Кстати, пользователи могут настроить политики оповещений на платформе мониторинга.
• Защита от повторного воспроизведения и подделки: OTeam реализовала плагины защиты от повторного воспроизведения и подделки, позволяя внешним бизнесам, которым нужны эти возможности, использовать их прямо из коробки для защиты безопасности своих API.

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

Итог

OTeam помогла бизнес-команде решить их болевые точки и непрерывно улучшала функции Apache APISIX внутри Tencent, двигаясь вперед вместе с развитием сообщества.

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