Snowball Finance преобразует свою архитектуру Active-Active с помощью APISIX

Вэньцзе Ши, старший инженер по разработке команды инфраструктуры в Snowball Finance, поделился опытом использования APISIX в Snowball Finance на Apache APISIX Summit ASIA 2022. Эта статья основана на его выступлении и рассказывает о том, как Snowball Finance использует Apache APISIX для эволюции своей внутренней активной архитектуры, что позволяет достичь более гибкого управления сервисами.

Проблемы

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

Цели

• Минимизировать изменения, не внося слишком много переменных, сохраняя прозрачность для бизнес-групп.
• Унифицированно решать проблемы на уровне инфраструктуры и стремиться завершать аутентификацию в пределах локального центра обработки данных.

Результаты

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

Предыстория

Основанная в 2010 году, Snowball Finance начинала как инвестиционное сообщество, а теперь стала ведущей онлайн-платформой для управления финансами в Китае, предлагая инвесторам различные услуги, включая качественный контент, услуги реального времени, торговые инструменты и управление капиталом.

Среди этих услуг услуги реального времени подключены к нескольким источникам данных и предоставляют стабильные данные инвесторам через потоковую передачу, хранение и распространение данных. Поэтому услуги реального времени всегда были основным потребителем ресурсов в системе Snowball Finance.

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

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

Проблемы активной трансформации

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

В практических бизнес-сценариях постепенно проявились некоторые проблемы.

1. Сложные модули аутентификации SDK

При реализации активной трансформации поставщик и потребитель микросервисов не могут быть развернуты и запущены синхронно. Когда рыночные услуги Snowball Finance были впервые запущены в облаке, но центр пользователей еще не был поддержан в облаке, происходили вызовы между центрами обработки данных. По статистике центра пользователей, его RPC-вызовы достигали десятков миллиардов в день, а пиковая нагрузка могла достигать 50 000 QPS, что могло привести к более высокой задержке.

В то же время логика аутентификации Snowball Finance была сложной. В дополнение к протоколам OAuth2.0/JWT необходимо было учитывать множество факторов, таких как версии клиентов и несколько приложений под управлением Snowball Finance. Кроме того, модуль аутентификации был встроен в сервис, что усложняло его обновление.

2. Ограниченная функциональность OpenResty

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

3. Зависимость от самостоятельно разработанного регистрационного центра

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

Выбор технологии API-шлюза

На основе проблем, постепенно выявленных в практических бизнес-сценариях, команда инфраструктуры Snowball начала исследование продуктов для шлюзов.

Команда внутренне надеется обеспечить прозрачность для бизнеса и минимизировать изменения, не внося слишком много переменных. Команда также хочет решать проблемы унифицированно на уровне инфраструктуры и завершать аутентификацию в пределах локального центра обработки данных. Учитывая вышесказанное, Snowball Finance решила перенести службу аутентификации на API-шлюз.

Snowball Finance надеется, что новый API-шлюз сможет удовлетворить следующие требования:

• Высокая производительность
• Сильная масштабируемость
• Поддержка множества протоколов
• Низкая стоимость аутентификации на шлюзе

Ниже приведен подробный список выбора технологии API-шлюза среди OpenResty, Spring Gateway, Kong и APISIX.

Шлюз	Преимущества	Недостатки	Стоимость эксплуатации	Доступность
OpenResty	Высокая кастомизация и стабильность	Плохая наблюдаемость	Высокая	Высокая
Spring Gateway	Удобство для разработки на Java	уровень производительности не соответствует требованиям	Средняя	Средняя
Kong	Мощный и богатый функциями	PostgreSQL как единая точка отказа базы данных	Низкая	Средняя
APISIX	Облачный, поддерживает множество языков программирования и имеет сильную масштабируемость	/	Низкая	Высокая

Учитывая внутренние требования и сравнивая популярные продукты для шлюзов на рынке, Snowball Finance в конечном итоге выбрала Apache APISIX для последующей архитектуры.

Практика на основе Apache APISIX

Измененная архитектура

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

Snowball Finance в основном внесла следующие изменения на основе APISIX:

• Унифицировала модуль аутентификации на уровне прокси и использовала APISIX для унифицированной аутентификации. Для типов JWT можно использовать плагин jwt-auth APISIX для локальной аутентификации напрямую.
• Совместимость с OAuth 2.0 и использование APISIX для вызова центра пользователей Snowball Finance для обработки.
• Подключение к регистрационному центру серверных RPC-сервисов Snowball Finance для использования его серверных сервисов для аутентификации, если аутентификация JWT не удалась.

Сценарии применения

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

Сценарий 1: Аутентификация на шлюзе

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

1. После интеграции APISIX в качестве шлюза Snowball Finance использовала уровень шлюза APISIX для унифицированного управления аутентификацией. Оригинальный метод аутентификации JWT был заменен на официальный плагин jwt-auth. Настройка и использование плагина jwt-auth относительно проста: достаточно просто настроить соответствующую информацию, такую как маршруты и апстримы в Dashboard, и плагин будет включен.
2. Snowball Finance использовала плагин grpc-transcode для проксирования вызовов службы аутентификации для обработки предыдущего метода аутентификации, связанного с OAuth 2.0.

Snowball Finance внутренне рассмотрела следующие три решения для вызова gRPC для реализации аутентификации:

• Решение 1: Использовать Lua для прямого вызова gRPC. Поскольку это решение требует учета связанных реализаций, таких как балансировка нагрузки и динамический апстрим, процесс будет более сложным, поэтому оно было отклонено.
• Решение 2: Использовать Lua-корутины для обратного вызова логики на Golang. Snowball Finance отказалась от этого способа из-за отсутствия соответствующего практического опыта.
• Решение 3: Использовать Lua для выполнения HTTP-вызовов, а интерфейс gRPC реализовать с помощью плагина grpc-transcode APISIX. Благодаря быстрой оптимизации плагинов сообществом APISIX, Snowball Finance в конечном итоге выбрала этот вариант для реализации вызовов gRPC.

В настоящее время требуется ручная синхронизация файлов protocol buffer во время выполнения. Это связано с тем, что если центр пользователей изменяет файл protocol buffer, который не соответствует версии, сохраненной APISIX, это может привести к проблемам с аутентификацией.

Сценарий 2: Многомерный мониторинг в рамках наблюдаемости

Необходимо отслеживать множество метрик после запуска веб-сайтов в Snowball Finance, в основном сосредоточившись на следующих трех частях:

• Состояние соединений NGINX и входящий/исходящий трафик
• Частота ошибок HTTP (используется для устранения неполадок в сервисе или апстриме/даунстриме)
• Задержка запросов APISIX (время, затраченное на выполнение логики, когда APISIX перенаправляет запрос)

Например, в некоторых случаях задержка APISIX кажется высокой (как показано на рисунке ниже), что связано с логикой расчета задержки. В настоящее время логика заключается в том, что время, затраченное на один HTTP-запрос на NGINX, минус задержка этого запроса при маршрутизации к апстриму. Разница между двумя временными затратами является метрикой задержки APISIX.

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

Также можно использовать возможности наблюдаемости APISIX для сбора Access log и доставки его на панель управления трафиком в формате и стандартизированном виде для просмотра и обобщения. Это позволяет активно понимать общие тенденции с нескольких точек зрения, выявлять потенциальные проблемы и оперативно их устранять.

Сценарий 3: Масштабирование регистрационного центра ZooKeeper

В Snowball Finance вызовы gRPC регистрируются и обнаруживаются на основе регистрационного центра Zookeeper. В процессе реализации аутентификации, когда локальная проверка JWT не удается, API-шлюзу необходимо получить доступ к gRPC-сервису в центре пользователей Snowball Finance для аутентификации, что требует от API-шлюза получения списка адресов серверных gRPC-сервисов из регистрационного центра.

Официальный плагин APISIX apisix-seed может интегрировать ZooKeeper для обнаружения сервисов. Snowball Finance провела некоторую кастомизацию, более специфичную для своего бизнеса.

Конкретная реализация в основном заключается в узле контента APISIX. Когда процесс Worker запускается, он опрашивает кластер ZK-Rest, как показано на рисунке ниже, а затем регулярно извлекает исходные данные и информацию обо всем сервисе и обновляет их в локальном кэше процесса Worker для обновления списков сервисов.

Как видно из рисунка выше, кластер ZK-Rest получает доступ к данным ZooKeeper в форме Rest. Только добавив его экземпляр, можно достичь функций высокой доступности, устраняя некоторые сложные операции. Но эта операция также имеет более очевидный недостаток. При периодическом опросе кластера ZK-Rest может возникнуть задержка в обновлении списка сервисов.

Итоги и перспективы

В настоящее время Apache APISIX хорошо работает в качестве уровня шлюза в Snowball Finance. Конкретно:

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

В последующем использовании Snowball Finance также планирует:

• Применить APISIX Ingress Controller в кластере K8s.
• Использовать плагин grpc-transcode для преобразования протокола HTTP/gRPC для достижения унифицированного серверного интерфейса.
• Использовать плагин traffic-spilt для маркировки трафика, подключения к регистрационному центру Nacos и реализации канареечного выпуска и других методов управления сервисами.

В последующих планах Apache APISIX будет использоваться для замены существующего OpenResty и в конечном итоге для управления полным жизненным циклом север-южного трафика.