Transformando a un gigante de la gestión de fondos con APISIX

Visión general

Acerca de Invesco Great Wall

Invesco Great Wall Fund Management Co., Ltd. ("IGW") es una empresa de gestión de fondos chino-estadounidense, con capacidades de inversión en múltiples activos y experiencia líder en renta variable. Las principales actividades de la empresa incluyen inversión cuantitativa, renta activa y renta fija. IGW gestiona activos por más de 850 mil millones de USD, brindando servicios a más de 60 millones de inversionistas.

IGW enfoca su atención principal en la gestión de activos, ofreciendo una amplia gama de estrategias de inversión que abarcan múltiples clases de activos, como renta variable, renta fija y estrategias cuantitativas.

Desafíos

• La falta de pasarelas estandarizadas entre los diferentes sistemas de negocio generó numerosos servicios asociados con pasarelas y operaciones independientes, lo que resultó en mayores costos de mantenimiento.
• Las pasarelas anteriores de IGW tenían una capacidad limitada en términos de carga y funcionalidades, como el balanceo de carga y el lanzamiento canario, que son complejos y consumen mucho tiempo al implementarse, lo que podría causar cuellos de botella operativos.
• Debido a la ausencia de capacidades de autenticación en la configuración anterior, varias interfaces del sistema podían accederse directamente, lo que representaba un riesgo significativo para la seguridad de los sistemas de negocio.

Resultados

• Al implementar APISIX, IGW construyó su pasarela API unificada, resolviendo los problemas de esfuerzos de desarrollo redundantes y la inconsistencia en la calidad de las funcionalidades.
• La integración de DevOps y pipelines mejoró significativamente la estabilidad del despliegue de rutas y servicios, aumentando la eficiencia en la publicación de rutas y servicios.
• La recarga en caliente de APISIX redujo considerablemente la necesidad de reinicios de servicios, aliviando la presión sobre los recursos del sistema y minimizando el tiempo de inactividad.

Antecedentes

Primero, profundicemos en la evolución arquitectónica del sistema de negocio de IGW. Inicialmente, IGW adoptó un enfoque de servicio monolítico, con aplicaciones de servicio desplegadas en máquinas físicas. Sin embargo, a medida que los servicios y el negocio crecieron, los costos de operaciones y desarrollo comenzaron a aumentar. Esto impulsó la transición a la etapa de máquinas virtuales.

Durante la fase de máquinas virtuales, no había uniformidad en las pasarelas utilizadas por los diferentes sistemas de negocio. Cada negocio operaba de manera independiente, lo que resultó en numerosos servicios asociados con pasarelas y altos costos de mantenimiento.

En los sectores de fondos y valores, existen requisitos regulatorios relacionados con las zonas de red. Cada zona de red debe dividirse en diferentes zonas seguras físicamente aisladas o zonas lógicas seguras según los niveles de seguridad de la información, durante las cuales se emplea un firewall.

Alineado con la estrategia de nube en tecnología financiera y transformación digital, IGW inició su proyecto de migración a la nube.

Por qué IGW eligió APISIX

Debido al mayor énfasis del sector financiero en la estabilidad del servicio en comparación con otras industrias, la estabilidad es prioritaria. A medida que los entornos de máquinas virtuales experimentaron un crecimiento descontrolado de los servicios de pasarela, se volvió imperativo satisfacer la amplia gama de requisitos comerciales. Por lo tanto, la escalabilidad de la pasarela es muy valorada. Además, la observabilidad juega un papel crucial, con fuertes demandas de registro, seguimiento y monitoreo del sistema de negocio. Finalmente, la capacidad de recarga en caliente también es esencial.

Debido a las limitaciones de NGINX para actualizar configuraciones de manera dinámica, requiere una recarga cuando se enfrenta a cambios de configuración. Además, en escenarios de conexión persistente, este proceso puede resultar en fluctuaciones de tráfico dentro del sistema de negocio, afectando la experiencia del usuario.

Por lo tanto, considerando estos cuatro puntos focales, el equipo técnico de IGW realizó una comparación exhaustiva entre APISIX y Kong, dos pasarelas API populares y ampliamente reconocidas en el mercado:

• Marco Técnico: APISIX y Kong están desarrollados basados en OpenResty. En cuanto al centro de configuración, APISIX adopta etcd, mientras que Kong opta por PostgreSQL. APISIX destaca como una pasarela distribuida nativa de la nube debido a la naturaleza nativa de la nube de etcd y las características de estado de APISIX. Sin embargo, la elección del centro de configuración de Kong puede introducir problemas potenciales de punto único de fallo, requiriendo soporte adicional de infraestructura para alta disponibilidad.

• Actividad de la Comunidad: Tanto APISIX como Kong tienen una comunidad activa con un promedio de 20 commits por día en sus repositorios.

• Plugins: APISIX tiene más de 80 plugins y solo un documento para cada plugin; Kong tiene más de 30 plugins y 4-5 documentos para cada plugin; 100+ líneas de código para cada plugin de APISIX y 300+ para Kong.

• Escalabilidad: APISIX admite muchos lenguajes de programación y también admite WebAssembly. Kong solo admite el uso de Lua para escribir plugins.

• Recarga en Caliente: Esto es en lo que el equipo se enfoca. APISIX admite la recarga en caliente a nivel de milisegundos al habilitar o deshabilitar plugins, y al agregar nuevos plugins (como plugins personalizados). APISIX también admite la modificación dinámica de los parámetros de la pasarela. Sin embargo, Kong no admitía esta función cuando IGW realizó la selección de tecnología.

• Observabilidad: Tanto APISIX como Kong admiten OpenTelemetry, pero APISIX también puede conectarse a Elasticsearch, Prometheus, y SkyWalking. Kong aún no proporcionaba soporte para SkyWalking cuando IGW estaba realizando la selección de tecnología.

Basándose en las preocupaciones y puntos de comparación anteriores, el equipo técnico de IGW finalmente eligió APISIX como la pasarela API.

Escenarios de usuario y soluciones para IGW

Introducción a la arquitectura del sistema de IGW

El sistema de negocio de IGW se dividía aproximadamente en tres partes: área de transacciones, área de producción y área de gestión, cada una utilizando diferentes pasarelas API. Originalmente, IGW utilizaba NGINX como servidor web y proxy inverso. Los negocios en la misma clasificación de red utilizaban el mismo NGINX. Como resultado, cada cambio de servicio o actualización de ruta requería una actualización manual y una recarga en NGINX.

El diagrama anterior ilustra la arquitectura del sistema de IGW. La capa de clúster de seguridad de la pasarela utiliza múltiples marcos como Zuul, Spring Cloud Gateway, Kong y NGINX. La gestión arquitectónica no estaba unificada y la gestión era relativamente engorrosa.

Solución

Para resolver estos desafíos, IGW enfatiza en transformar los clústeres de pasarela en APISIX. Dado que APISIX se despliega en clústeres de Kubernetes, permite la gestión unificada de APIs a través de YAML de manera declarativa. Además, el APISIX Ingress Controller observa automáticamente los cambios en los recursos de Kubernetes, permitiendo la sincronización en tiempo real de las configuraciones de APISIX, incluyendo ApisixRoute, SSL y más.

A continuación se muestra el diagrama de secuencia de sincronización de rutas de IGW después de usar APISIX.

Escenarios de usuario

Después de usar APISIX, IGW logró muchos beneficios, entre los cuales el equipo de IGW está más preocupado desde la perspectiva del negocio, incluyendo el enrutamiento inteligente, la autenticación, la observabilidad y el control de tráfico.

Enrutamiento inteligente eficiente

El enrutamiento inteligente se demuestra principalmente en el balanceo de carga en las capas 4 y 7. Como se muestra en el diagrama, la información de enrutamiento sincronizada a través del APISIX Ingress Controller está acompañada de etiquetas específicas, evitando efectivamente operaciones de eliminación accidentales.

Después de las pruebas en el entorno, incluso si se eliminan datos, Kubernetes es capaz de sincronizarse rápida y automáticamente con APISIX, resolviendo así el problema de pérdida de datos.

Además, las actualizaciones de enrutamiento en APISIX logran una respuesta a nivel de milisegundos, con un retraso de sincronización de configuración casi imperceptible, proporcionando una excelente experiencia de usuario.

Autenticación mejorada

Antes de introducir la pasarela unificada, cada unidad de negocio tenía que desarrollar individualmente componentes relacionados con la autenticación para garantizar la seguridad de sus interfaces de datos. En el lado del negocio, cada sistema estaba cargado con el desarrollo de funcionalidades de autenticación redundantes, lo que resultó en mayores costos de desarrollo y una calidad variable de las funcionalidades implementadas. En consecuencia, para la verificación de seguridad, IGW introdujo plugins unificados de autenticación y redirección HTTPS.

Antes de la introducción de la pasarela unificada, los certificados HTTPS para los servicios se descifraban en el punto final de Alta Disponibilidad (HA), lo que aumentaba la complejidad, la sobrecarga operativa y los riesgos de seguridad.

Reconociendo estos desafíos, el equipo técnico de IGW ideó un plan para centralizar la funcionalidad de autenticación dentro de la pasarela, abordando así los problemas mencionados. Este enfoque mejora significativamente la eficiencia de investigación y desarrollo de los sistemas de negocio, permitiendo a los desarrolladores centrarse más en el desarrollo del negocio central.

Al migrar a APISIX, estos inconvenientes pueden mitigarse. APISIX puede manejar la terminación HTTPS, cargar certificados SSL dinámicamente y proporcionar una gestión centralizada y segura para manejar tareas relacionadas con la seguridad, mejorando el rendimiento general del sistema y la flexibilidad.

Más allá del monitoreo

Anteriormente, el débil soporte para la observabilidad en el sistema de negocio original de IGW afectó negativamente la resolución de problemas del sistema, la optimización del rendimiento, la confiabilidad y el monitoreo proactivo.

Por lo tanto, el equipo técnico de IGW buscó integrar rápidamente múltiples plugins proporcionados por APISIX, como el monitoreo de registros y el seguimiento, para mejorar las capacidades de observabilidad.

Además, el equipo estaba investigando y aprovechando activamente Apache SkyWalking para el seguimiento distribuido, Prometheus para fines de monitoreo y ELK para la recopilación eficiente de registros. Sorprendentemente, APISIX admite todos estos plugins y, por lo tanto, ha demostrado ser una solución ideal que cumple plenamente con las expectativas y requisitos del equipo técnico de IGW, convirtiéndose en la opción preferida.

El diagrama anterior ilustra la topología de servicio de IGW después de que el equipo técnico integró SkyWalking en producción. Este diagrama integral ofrece una visualización clara y concisa de las relaciones de invocación entre servicios, abarcando información crucial como la dirección del tráfico a través de la pasarela y las tasas de éxito. Aprovechando este diagrama de topología, el equipo de IGW puede identificar rápidamente la ubicación exacta de cualquier error o problema dentro de la cadena de servicios.

Dominando el control de tráfico

APISIX ha demostrado ser una solución efectiva para facilitar mecanismos versátiles de control de tráfico para IGW. Al adoptar APISIX, el equipo técnico de IGW ha logrado sin problemas el control de tráfico a través de lanzamientos canarios y estrategias basadas en peso. Esta capacidad robusta permite una gestión eficiente de la distribución del tráfico, permitiendo al equipo implementar fácilmente lanzamientos canarios y ajustar los pesos del tráfico según sea necesario.

En un escenario basado en lanzamiento canario, la pasarela necesita llamar a una interfaz descendente a través de una solicitud HTTP para obtener datos específicos, y juzgar en función de los resultados devueltos para determinar si la solicitud necesita enviarse al entorno de lanzamiento canario.

Basado en la política de peso, los servicios de máquinas virtuales y contenedores se proporcionan al exterior en paralelo. Por ejemplo, el 90% del tráfico llega al servicio de máquinas virtuales y el 10% del tráfico llega al servicio en la nube para verificar la estabilidad del servicio en la nube. Actualmente, el entorno de producción de IGW ha sido configurado con un lanzamiento canario basado en peso.

Logros después de usar APISIX

Construcción de una pasarela API unificada

Al implementar APISIX, el equipo técnico de IGW ha logrado la estandarización del marco de la pasarela API que proporciona funciones ricas de gestión de tráfico, como balanceo de carga, upstream dinámico, lanzamiento canario, corte de circuito, autenticación y observabilidad.

IGW ha implementado una funcionalidad de autenticación unificada en la pasarela, abordando los problemas de esfuerzos de desarrollo redundantes y la inconsistencia en la calidad de las funcionalidades. Esto permitió a los desarrolladores centrarse más en el desarrollo y mejoró significativamente la eficiencia de investigación y desarrollo de los sistemas de negocio.

Mejora de la estabilidad del despliegue de rutas y servicios

Las actualizaciones de enrutamiento en APISIX son capaces de ofrecer respuestas a nivel de milisegundos, garantizando un rendimiento rápido y eficiente. Además, la sincronización de configuraciones es casi instantánea, lo que resulta en una experiencia de usuario mejorada.

Además, la integración de DevOps y pipelines ha mejorado significativamente la estabilidad del despliegue de rutas y servicios. Este enfoque simplificado ha mejorado la eficiencia en la publicación de rutas y servicios, asegurando resultados más confiables y consistentes.

La recarga en caliente mejora el rendimiento y el tiempo de actividad

El equipo técnico de IGW valora mucho el poder de la recarga en caliente. APISIX ofrece un proceso de despliegue en caliente sin interrupciones para habilitar o deshabilitar plugins, facilitando la adición de plugins personalizados y permitiendo actualizaciones dinámicas de los parámetros de la pasarela.

Como resultado, las modificaciones a las configuraciones de plugins y los ajustes de la pasarela pueden aplicarse instantáneamente sin la necesidad de reinicios del sistema o interrupciones. Esta notable función de recarga en caliente mejora enormemente la flexibilidad y agilidad de la plataforma APISIX, permitiendo a los desarrolladores realizar ajustes en tiempo real a sus configuraciones y personalizar la pasarela para cumplir con sus requisitos específicos.

La capacidad de recarga en caliente de APISIX ha aliviado enormemente la presión de los reinicios de servicios. Esta función permite que las actualizaciones y modificaciones se apliquen a los servicios sin la necesidad de un reinicio completo, lo que resulta en un mejor rendimiento del sistema y un tiempo de inactividad reducido.

Resumen

El equipo técnico de IGW también expresó expectativas sobre la mejora adicional de la funcionalidad, confiabilidad y rendimiento de APISIX para una operación sin problemas en el futuro.

La implementación exitosa de APISIX en Invesco Great Wall ha generado beneficios significativos y resultados positivos. Con APISIX, el equipo de IGW ha logrado un marco de pasarela API unificada, lo que ha resultado en operaciones simplificadas y costos reducidos. La integración también ha traído una mayor estabilidad en el enrutamiento y los servicios, lo que ha llevado a un mejor rendimiento y minimización de interrupciones.

A la luz de los notables resultados de Invesco Great Wall, APISIX demuestra ser una solución de pasarela API altamente efectiva diseñada para la industria de servicios financieros, incluyendo el sector de fondos y valores. Este caso de estudio exitoso es un testimonio convincente de los beneficios de adoptar APISIX en finanzas y recomienda encarecidamente su implementación a otras organizaciones en la industria.