Преобразование гиганта управления фондами с помощью APISIX

Обзор

О компании Invesco Great Wall

Invesco Great Wall Fund Management Co., Ltd. ("IGW") — это китайско-американская компания по управлению фондами, обладающая возможностями инвестирования в различные классы активов и экспертизой в области акций. Основные направления деятельности компании включают количественные инвестиции, активный доход и фиксированный доход. Управляемые активы IGW превышают 850 миллиардов долларов США, а услугами компании пользуются более 60 миллионов инвесторов.

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

Проблемы

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

Результаты

• Внедрив APISIX, IGW создала единый API-шлюз, решив проблемы избыточных усилий по разработке и несогласованности качества функций.
• Интеграция DevOps и конвейеров значительно повысила стабильность развертывания маршрутов и сервисов, улучшив эффективность выпуска маршрутов и сервисов.
• Горячая перезагрузка APISIX существенно снизила необходимость перезапуска сервисов, тем самым уменьшив нагрузку на системные ресурсы и сократив время простоя.

Предыстория

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

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

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

Следуя стратегии облачных технологий в финансовой сфере и цифровой трансформации, IGW начала проект миграции в облако.

Почему IGW выбрала APISIX

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

Из-за ограничений NGINX в динамическом обновлении конфигураций, требуется перезагрузка при изменениях конфигураций. Более того, в сценариях с постоянными соединениями этот процесс может вызывать колебания трафика в бизнес-системе, что влияет на пользовательский опыт.

Поэтому, учитывая эти четыре ключевых момента, техническая команда IGW провела всестороннее сравнение между APISIX и Kong, двумя популярными и широко признанными API-шлюзами на рынке:

• Техническая архитектура: APISIX и Kong разработаны на основе OpenResty. Что касается центра конфигураций, APISIX использует etcd, а Kong — PostgreSQL. APISIX выделяется как облачный распределенный шлюз благодаря облачной природе etcd и особенностям состояния APISIX. Однако выбор центра конфигураций Kong может вызывать проблемы с единой точкой отказа, требуя дополнительной инфраструктуры для обеспечения высокой доступности.

• Активность сообщества: И APISIX, и Kong имеют активное сообщество со средним количеством коммитов 20 раз в день в их репозиториях.

• Плагины: APISIX имеет 80+ плагинов и только один документ для каждого плагина; Kong имеет 30+ плагинов и 4-5 документов для каждого плагина; 100+ строк кода для каждого плагина APISIX и 300+ для Kong.

• Масштабируемость: APISIX поддерживает множество языков программирования, а также WebAssembly. Kong поддерживает только использование Lua для написания плагинов.

• Горячая перезагрузка: Это то, на что команда обращает особое внимание. APISIX поддерживает горячую перезагрузку на уровне миллисекунд при включении или отключении плагинов, а также при добавлении новых плагинов (например, пользовательских плагинов). APISIX также поддерживает динамическое изменение параметров шлюза. Однако Kong не поддерживал эту функцию на момент выбора технологии IGW.

• Наблюдаемость: И APISIX, и Kong поддерживают OpenTelemetry, но APISIX также может быть подключен к Elasticsearch, Prometheus и SkyWalking. Kong не предоставлял поддержку SkyWalking на момент выбора технологии IGW.

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

Сценарии использования и решения для IGW

Введение в архитектуру системы IGW

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

На диаграмме выше показана архитектура системы IGW. Слой кластера безопасности шлюза использует несколько фреймворков, таких как Zuul, Spring Cloud Gateway, Kong и NGINX. Управление архитектурой не было унифицировано, и управление было относительно сложным.

Решение

Для решения этих проблем IGW сосредоточилась на преобразовании кластеров шлюзов в APISIX. Поскольку APISIX развернут на кластерах Kubernetes, он позволяет унифицировать управление API через YAML в декларативном стиле. Кроме того, APISIX Ingress Controller автоматически отслеживает изменения в ресурсах Kubernetes, обеспечивая синхронизацию конфигураций APISIX в реальном времени, включая ApisixRoute, SSL и другие.

Ниже приведена диаграмма последовательности синхронизации маршрутов IGW после использования APISIX.

Сценарии использования

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

Эффективная интеллектуальная маршрутизация

Интеллектуальная маршрутизация в основном демонстрируется в балансировке нагрузки на уровне 4 и уровне 7. Как показано на диаграмме, информация о маршрутах, синхронизированная через APISIX Ingress Controller, сопровождается конкретными метками, что эффективно предотвращает случайные операции удаления.

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

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

Улучшенная аутентификация

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

До внедрения единого шлюза сертификаты HTTPS для сервисов расшифровывались на конечной точке высокой доступности (HA), что увеличивало сложность, операционные затраты и риски безопасности.

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

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

За пределами мониторинга

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

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

Кроме того, команда активно исследовала и использовала Apache SkyWalking для распределенной трассировки, Prometheus для целей мониторинга и ELK для эффективного сбора логов. Удивительно, но APISIX поддерживает все эти плагины и, таким образом, оказался идеальным решением, полностью соответствующим ожиданиям и требованиям технической команды IGW, что сделало его предпочтительным выбором.

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

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

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

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

На основе стратегии весов сервисы виртуальных машин и контейнеров предоставляются внешним пользователям параллельно. Например, 90% трафика направляется на сервисы виртуальных машин, а 10% — на облачные сервисы для проверки стабильности облачных сервисов. В настоящее время производственная среда IGW настроена на канареечный релиз на основе весов.

Достижения после использования APISIX

Создание единого API-шлюза

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

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

Повышение стабильности развертывания маршрутов и сервисов

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

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

Горячая перезагрузка повышает производительность и время безотказной работы

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

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

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

Итог

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

Успешное внедрение APISIX в Invesco Great Wall принесло значительные преимущества и положительные результаты. С APISIX команда IGW достигла единого фреймворка API-шлюза, что привело к оптимизации операций и снижению затрат. Интеграция также привела к повышению стабильности маршрутов и сервисов, что улучшило производительность и минимизировало сбои.

Учитывая впечатляющие результаты Invesco Great Wall, APISIX доказывает свою эффективность как решение для API-шлюза, адаптированное для финансовых услуг, включая сектор фондов и ценных бумаг. Этот успешный кейс является убедительным доказательством преимуществ внедрения APISIX в финансах и настоятельно рекомендует его использование другим организациям в отрасли.