NGINX к APISIX – Переосмысление динамики шлюза авиакомпаний

January 24, 2024

Case Study

Обзор

О компании

Эта ведущая авиакомпания, признанная Skytrax как 5-звездочная авиакомпания мира, безопасно работает уже 30 лет, охватывая почти 1900 международных маршрутов, включая регулярные пассажирские перевозки, чартерные рейсы для возобновления работы и учебы, а также пассажирские рейсы в Азии, Европе, Африке, Северной Америке и Океании.

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

Проблемы

  • Рост микросервисов и контейнерных развертываний усложняет управление увеличивающимся количеством экземпляров NGINX и разнообразными конфигурациями доменов.
  • Сосуществование множества версий NGINX увеличивает сложность обновления, компиляции и адаптации плагинов.
  • Предыдущий API-шлюз мог удовлетворить только базовые требования авиакомпании, но не предоставлял таких продвинутых функций, как автоматическое отключение (circuit breaker), канареечные релизы и т.д.

Результаты

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

Предыстория

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

1. Множество экземпляров NGINX и доменов

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

2. Различные версии NGINX и сложности с обновлением плагинов

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

3. Отсутствие стандартов для конфигураций NGINX

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

4. Недостаток современных функций шлюза

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

Выбор шлюза для точных бизнес-потребностей

Чтобы решить проблемы, связанные с NGINX, авиакомпания тщательно определила три основных требования к новому шлюзу:

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

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

Почему не OpenResty

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

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

Почему не Kong

Авиакомпания рассматривала Kong как альтернативу. Хотя его стандартные плагины удовлетворяли большинству требований, визуальный интерфейс (Dashboard) открытой версии не обновлялся несколько лет, что побудило предпочесть решения с более современными и удобными интерфейсами.

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

Почему не Envoy

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

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

Почему APISIX выделяется?

APISIX выделялся по сравнению с Kong по двум основным причинам.

  • APISIX Dashboard

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

  • Apache Open Source Project

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

Кроме того, APISIX эффективно решает проблемы, упомянутые ранее в отношении NGINX.

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

  • APISIX поставляется с общими плагинами, включая проверки здоровья и другие плагины мониторинга, устраняя проблемы совместимости и обновлений, с которыми сталкивались при использовании NGINX.

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

В целом, APISIX стал наиболее подходящим продуктом для технической команды.

Миграция с NGINX на APISIX: Изучение более продвинутых, но простых решений

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

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

Ниже приведено сравнение кода между конфигурацией в NGINX и APISIX.

#   NGINX  conf
    add_header 'Access-Control-Allow-Origin' $corsHost;
    add_header 'Access-Control-Allow-Methods' 'GET,POST,OPTIONS';
    add_header 'Access-Control-Allow-Credentials' 'true';
    add_header 'Access-Control-Allow-Headers' 'DNT,X-CustomHeader,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Accept,Authorization,appver';
    if ($request_method = 'OPTIONS') {
            return 204;
     }

#  APISIX  plugins config
    "cors": {
      "allow_credential": true,
      "allow_headers": "DNT,X-CustomHeader,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Accept,Authorization,appver",
      "allow_methods": "GET,POST,PUT,OPTIONS",
      "allow_origins": "https://wap.test.com,http://wap.test.com,",
    },
    "response-rewrite": {
      "status_code": 204,
      "vars": [
        [
          "request_method",
          "==",
          "OPTIONS"
        ]
      ]
    }

Сравнивая NGINX и APISIX, можно легко заметить, что конфигурация NGINX может казаться более лаконичной, но для тех, кто не знаком с NGINX и CORS, понимание смысла может быть не таким простым. В то же время APISIX инкапсулирует различные функции в плагины, делая конфигурацию более модульной. Таким образом, становится проще находить функции и понимать их назначение. Подобные примеры миграции конфигураций с NGINX на APISIX существуют для различных сценариев, таких как настройка WebSocket в NGINX.

Достижения

Упрощение управления конфигурациями для нескольких узлов

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

Упрощение операций с плагинами APISIX

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

Кроме того, в APISIX такие функции, как кросс-доменные запросы (CORS) и поддержка WebSocket, могут быть легко реализованы с помощью плагинов. Этот подход не только упрощает процесс разработки, но и способствует более эффективному решению проблем авиакомпании.

Создание комплексного API-шлюза

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

Преобразование устаревших конфигураций в повторно используемые модули

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

Итог

С апреля 2023 года, когда авиакомпания впервые познакомилась с APISIX, до успешной миграции с NGINX на APISIX в производственной среде в июле того же года, весь процесс миграции принес удовлетворительные результаты.

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

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

Tags:
Airlines