De NGINX a APISIX: Redefiniendo la dinámica de las pasarelas de aerolíneas

January 24, 2024

Case Study

Visión general

Acerca de

Nombrada la aerolínea de 5 estrellas del mundo por Skytrax, esta destacada compañía aérea ha operado de manera segura durante 30 años, cubriendo un total de casi 1,900 rutas internacionales, incluyendo transporte de pasajeros programado, vuelos chárter para la reanudación de trabajo y escuela, y vuelos de pasajeros en Asia, Europa, África, América del Norte y Oceanía, entre otros.

Como una aerolínea en rápido crecimiento, esta compañía líder necesitaba una puerta de enlace API para facilitar procesos eficientes de reserva de vuelos, integrar y conectar con diferentes sistemas y servicios, y manejar escenarios de alta concurrencia y datos financieros y de riesgo.

Desafíos

  • El auge de los microservicios y las implementaciones en contenedores dificulta la gestión del creciente número de instancias de NGINX y las diversas configuraciones de dominios.
  • La coexistencia de demasiadas versiones de NGINX aumenta la complejidad de actualizar, compilar y adaptar los complementos.
  • La anterior puerta de enlace API solo podía satisfacer los requisitos básicos de esta compañía aérea líder, pero no podía proporcionar funciones avanzadas como el corte de circuito, lanzamientos canarios, etc.

Resultados

  • La configuración de múltiples nodos se simplifica, mejorando enormemente la eficiencia del desarrollo y ahorrando costos de gestión gracias a la función de recarga en caliente de APISIX.
  • La compañía aérea líder aprovecha el ecosistema inclusivo de complementos de APISIX para realizar funciones más avanzadas, simplificando la actualización de complementos y sistemas.
  • La actualización mejora la eficiencia y mantenibilidad de la puerta de enlace, un cambio crucial hacia una gestión de configuración organizada, modular y reutilizable.

Antecedentes

Esta compañía aérea líder ha estado utilizando NGINX como su puerta de enlace norte-sur durante un período considerable. Sin embargo, a pesar de manejar eficazmente sus necesidades de tráfico a medida que el negocio y la cartera de productos se expandían, la empresa encontró puntos de dolor crecientes en varios aspectos.

1. Múltiples instancias y dominios de NGINX

Dentro de esta empresa, había múltiples instancias de NGINX y conjuntos de diferentes dominios, cuya complejidad aumentaba la dificultad de gestión. El núcleo de NGINX radica en sus archivos de configuración. A medida que crecía el número de instancias de NGINX, confiar únicamente en la copia de archivos a través de SCP para la gestión de la configuración se volvía cada vez más difícil. Especialmente con el uso generalizado de microservicios y la implementación en contenedores en el backend, había una mayor demanda de flexibilidad en la configuración del proxy inverso, lo que llevó a un aumento significativo en la carga de trabajo para la consistencia de la configuración.

2. Varias versiones de NGINX y actualizaciones problemáticas de complementos

Debido a razones históricas, el equipo estaba utilizando múltiples versiones de NGINX simultáneamente junto con numerosos complementos de NGINX. Si bien actualizar NGINX en sí no presentaba desafíos significativos, la dificultad surgía al actualizar, compilar y adaptar varios complementos. Muchos de estos no eran oficiales, lo que hacía que la resolución de problemas durante la compilación fuera complicada. Además, no se garantizaba la compatibilidad con las versiones de NGINX.

3. Falta de estándares para las configuraciones de NGINX

Heredar sistemas de varios equipos llevó a una plétora de prácticas de configuración de NGINX, mostrando numerosos enfoques sin una configuración estandarizada. La ausencia de un estándar de configuración unificado subrayó la diversidad en los métodos de implementación entre los equipos, destacando la necesidad de un enfoque cohesivo y estandarizado para las configuraciones de NGINX.

4. Funciones modernas de puerta de enlace insuficientes

Si bien NGINX satisfacía eficientemente las demandas básicas de la puerta de enlace norte-sur, como el proxy inverso y el balanceo de carga, los requisitos dinámicos del negocio de la empresa necesitaban funciones avanzadas. Implementar servicios como corte de circuito, controles de seguridad y lanzamientos canarios se volvió desafiante al depender únicamente de NGINX, lo que llevó a la exploración de soluciones más robustas.

Selección de puerta de enlace para necesidades comerciales precisas

Para abordar los desafíos enfrentados con NGINX, esta compañía aérea líder delineó meticulosamente tres requisitos fundamentales principales para una nueva solución de puerta de enlace:

  1. Facilidad de gestión y configuración: Necesitan una solución que facilite la gestión y despliegue unificado de configuraciones como rutas y servicios upstream en múltiples nodos de puerta de enlace.
  2. Funciones más avanzadas de la puerta de enlace API: La nueva puerta de enlace debe cumplir con los requisitos comerciales modernos de la puerta de enlace API, incluyendo corte de circuito, controles de seguridad y lanzamientos canarios.
  3. Facilidad de uso y curva de aprendizaje baja: Considerando la reducción de costos de gestión, el equipo espera que la nueva solución de puerta de enlace cumpla con la mayoría de los requisitos básicos a través de la configuración y métodos de bajo código sin esfuerzo.

Después de aclarar las actualizaciones iterativas y los requisitos básicos para su puerta de enlace norte-sur existente, la empresa investigó varios productos populares en el mercado y finalmente eligió APISIX como su nueva puerta de enlace.

Por qué no OpenResty

Durante la investigación, OpenResty fue considerado primero, una solución ampliamente adoptada por algunas empresas. Su principal ventaja era la compatibilidad total de los archivos de configuración con NGINX. Migrar de NGINX a OpenResty no fue tan difícil para la empresa, aunque existían configuraciones de dominios complejos.

Sin embargo, en comparación con Kong y APISIX, la versión de código abierto de OpenResty carecía de complementos completos y un panel para la configuración visual. Los usuarios tenían que involucrarse en la codificación para cumplir con algunas funcionalidades básicas.

Por qué no Kong

La compañía aérea consideró Kong como una alternativa. Aunque sus complementos predeterminados abordaban la mayoría de los requisitos, la interfaz visual (Dashboard) de la versión de código abierto permaneció sin cambios durante varios años, lo que llevó a una preferencia por soluciones con interfaces más actualizadas y fáciles de usar.

En pruebas de estrés, APISIX superó a Kong, mostrando un rendimiento impresionante: el doble que Kong sin complementos y hasta diez veces mejor con los complementos de limitación de tasa y Prometheus habilitados. Además, APISIX, basado en OpenResty, demostró excelentes capacidades de enrutamiento, aumentando la confianza del equipo.

Por qué no Envoy

A pesar de las impresionantes características de Envoy, el lenguaje C++ y la curva de aprendizaje más pronunciada, especialmente para la limitación del equipo técnico, llevaron al equipo a decidir no elegir Envoy como la solución de puerta de enlace preferida.

Al final, el equipo técnico optó por APISIX como su nueva puerta de enlace debido a su funcionalidad y rendimiento reconocidos.

¿Por qué destaca APISIX?

APISIX destacó en comparación con Kong por dos razones principales.

  • APISIX Dashboard

    Con el Dashboard, el equipo técnico puede gestionar convenientemente varias rutas y configuraciones de complementos. Notablemente, el APISIX Dashboard es una parte de código abierto del proyecto, asegurando actualizaciones continuas en línea con el desarrollo de APISIX, proporcionando una experiencia de gestión mejorada.

  • Proyecto de código abierto Apache

    Al ser un proyecto de nivel superior en la Apache Software Foundation, APISIX facilitó a los usuarios encontrar documentación técnica relevante en comparación con Kong. Tener el apoyo de la comunidad Apache proporcionó asistencia técnica confiable cuando se enfrentaban a desafíos, lo que hace que APISIX sea una opción más adecuada para la compañía aérea.

Además, APISIX aborda eficazmente los puntos de dolor mencionados anteriormente con respecto a NGINX.

  • APISIX almacena configuraciones en etcd, permitiendo a los desarrolladores gestionar múltiples nodos APISIX para diferentes dominios con facilidad al implementar un solo clúster etcd.

  • APISIX viene con complementos comunes, incluyendo controles de salud y otros complementos de monitoreo, eliminando preocupaciones sobre compatibilidad y actualizaciones similares a las enfrentadas con NGINX.

  • APISIX incluye varios complementos de seguridad y control de tráfico, permitiendo fácilmente funciones como corte de circuito, controles de seguridad, lanzamientos canarios y más.

En general, APISIX destaca como el producto más adecuado para el equipo técnico.

Migración de NGINX a APISIX: Explorando soluciones avanzadas pero más simples

En NGINX, la gestión de dominios y la implementación de funcionalidades se logran principalmente a través de archivos de configuración de NGINX. Aunque todavía basado en NGINX y OpenResty, APISIX adopta un enfoque completamente diferente, ya no utilizando archivos de configuración de NGINX para gestionar dominios e implementar funcionalidades.

En cambio, APISIX configura rutas y upstreams basados en nombres de dominio e implementa varias funciones adicionales en estas rutas a través de complementos. El complemento CORS incorporado de APISIX puede adoptarse para lograr configuraciones entre regiones, ahorrando la necesidad de convertirlo línea por línea.

A continuación se muestra una comparación de código entre la configuración en NGINX y 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"
        ]
      ]
    }

Al comparar NGINX y APISIX, se puede encontrar fácilmente que la configuración de NGINX puede parecer más concisa, pero para personas no familiarizadas con NGINX y CORS, comprender el significado subyacente podría no ser tan sencillo. En contraste, APISIX encapsula diferentes funciones en complementos, haciendo que la configuración sea más modular. Por lo tanto, se vuelve más obvio encontrar características y comprender las funciones. Ejemplos similares de migración de configuración de NGINX a APISIX existen para varios escenarios, como la configuración de WebSocket en NGINX.

Logros

Gestión simplificada de configuración de múltiples nodos

APISIX mejora el almacenamiento de configuración con etcd, facilitando la gestión de diversos nodos APISIX en múltiples dominios. Esto simplifica tareas al usar un solo clúster etcd, asegurando un control efectivo sobre diferentes instancias de APISIX con configuraciones de dominio específicas. Además, el método centralizado reduce la complejidad, promueve una gestión fluida y mejora la escalabilidad y eficiencia de APISIX en varios escenarios de dominio. En consecuencia, en la compañía aérea, implementar un solo clúster etcd es suficiente para supervisar diferentes instancias de APISIX vinculadas a configuraciones de dominio distintas.

Operaciones simplificadas con complementos de APISIX

APISIX viene con complementos incorporados como controles de salud comunes, similares a los complementos frecuentemente utilizados en NGINX. Esta característica elimina la necesidad de que la compañía aérea se preocupe por problemas relacionados con actualizaciones y compatibilidad. La inclusión de estos complementos en APISIX asegura una funcionalidad sin problemas y alivia las preocupaciones asociadas con la actualización y el mantenimiento de la compatibilidad, proporcionando una experiencia sin complicaciones para la compañía aérea.

Además, en APISIX, características como el intercambio de recursos de origen cruzado (CORS) y el soporte de WebSocket pueden implementarse sin problemas utilizando complementos. Este enfoque no solo simplifica el proceso de desarrollo, sino que también contribuye a una resolución más sofisticada y eficiente de los desafíos de la compañía aérea.

Establecimiento de una puerta de enlace API integral

APISIX viene equipado con varios complementos de seguridad y control de tráfico, facilitando la implementación sin esfuerzo de la limitación de servicios, medidas de seguridad y lanzamientos graduales. Esto permite a la compañía aérea aprovechar una gama más amplia de características básicas y avanzadas. La adopción de APISIX se traduce en un logro significativo para la aerolínea, permitiendo una mayor confiabilidad del servicio, controles de seguridad robustos y estrategias de implementación eficientes como lanzamientos graduales, contribuyendo finalmente a una capacidad operativa y rendimiento elevados.

Reestructuración de configuraciones heredadas en módulos reutilizables

A lo largo de todo el proceso de actualización, el equipo técnico descubrió numerosas configuraciones obsoletas en la configuración existente de NGINX, muchas de las cuales involucraban copiar y pegar sin sentido. Esta actualización sirvió como una revisión completa de toda su puerta de enlace norte-sur, enfocándose particularmente en las funcionalidades proporcionadas por APISIX, como plugin_config. Estas características facilitaron significativamente la gestión modularizada y la reutilización de configuraciones a nivel de puerta de enlace. La implementación de plugin_config y capacidades relacionadas de APISIX no solo simplificó el proceso de configuración, sino que también mejoró la eficiencia general y la mantenibilidad de nuestra puerta de enlace norte-sur. Esta actualización marcó un cambio crucial hacia un enfoque de gestión de configuración más organizado, modular y reutilizable.

Resumen

Desde abril de 2023, esta compañía aérea líder encontró inicialmente APISIX, hasta la migración exitosa de NGINX a APISIX en el entorno de producción en julio del mismo año, todo el proceso de migración ha arrojado resultados satisfactorios.

En las primeras etapas de la migración, el equipo técnico lidió con varias configuraciones históricas y planteó preocupaciones sobre si los complementos de APISIX podrían replicar completamente todas las funcionalidades de nuestro NGINX existente. Sin embargo, el resultado final demostró que los complementos de APISIX eran más que capaces de cumplir con este desafío.

En resumen, APISIX proporcionó una solución más elegante y ayudó a la compañía aérea líder a avanzar hacia una nueva fase técnica. Ha abordado perfectamente los diversos puntos de dolor que encontramos en NGINX y su rico conjunto de complementos permite a la compañía aérea abordar fácilmente varios nuevos requisitos planteados por los clientes.

Tags:
Airlines