Snowball Finance transforma su arquitectura activa-activa con APISIX

Wenjie Shi, Ingeniero Senior de Desarrollo del equipo de Infraestructura en Snowball Finance, compartió las prácticas de Snowball Finance con APISIX en el Apache APISIX Summit ASIA 2022. Este artículo se basa en esa presentación, donde se explica cómo Snowball Finance aprovecha Apache APISIX para lograr la evolución de su arquitectura activa-activa interna, permitiendo una gestión de servicios más flexible.

Desafíos

• Los módulos de autenticación complejos del SDK aumentan la complejidad del sistema y los riesgos de seguridad cuando el centro de usuarios se accede entre regiones, debido a que la arquitectura activa-activa solo está disponible en el módulo de servicios de mercado.
• OpenResty carece de un sistema de monitoreo robusto para la observabilidad y requiere scripts personalizados para lograr escalabilidad, lo que resulta en mayores costos de desarrollo y operación.
• Un centro de registro de NGINX incompleto, sin mecanismo de latido, reduce la disponibilidad y estabilidad, impidiendo manejar fallos del sistema de manera oportuna.

Objetivos

• Minimizar los cambios sin introducir demasiadas variables, manteniendo la transparencia para los grupos de negocio.
• Manejar problemas de manera uniforme a nivel de infraestructura y esforzarse por completar los servicios de autenticación dentro del centro de datos local.

Resultados

• Implementación de autenticación unificada, corte de circuito y limitación de tasa en la capa de puerta de enlace, reduciendo el acoplamiento del sistema y mejorando la calidad del servicio en escenarios de doble centro de datos.
• Establecimiento de una solución de monitoreo unificada desde la puerta de enlace hasta la capa de servicio, aprovechando el sistema de monitoreo de APISIX y brindando un excelente soporte para la resolución global de problemas.
• Proporcionar un enfoque de implementación elegante para la conversión de protocolos gRPC y la gestión de servicios.

Antecedentes

Fundada en 2010, Snowball Finance comenzó como una comunidad de inversión y ahora se ha convertido en una plataforma líder de gestión financiera en línea en China, ofreciendo diversos servicios, incluidos contenido de alta calidad, servicios de mercado en tiempo real, herramientas de trading y gestión de patrimonio para inversores.

Entre estos servicios, el servicio de mercado en tiempo real está conectado a múltiples fuentes de datos y proporciona servicios de datos estables a los inversores mediante transmisión, almacenamiento y distribución de datos. Por lo tanto, los servicios de mercado en tiempo real siempre han sido un gran consumidor de recursos en el sistema de Snowball Finance.

En consecuencia, una tarea importante dentro de Snowball Finance es mejorar continuamente la estabilidad, incluyendo la optimización del rendimiento de los servicios de mercado. Aun así, durante los picos de tráfico, algunos sistemas pueden experimentar lentitud en la respuesta o incluso volverse inaccesibles debido a una avalancha de datos, afectando la experiencia del usuario.

En este contexto, Snowball Finance ha lanzado un plan de transformación activa-activa de servicios para brindar servicios estables y de alta calidad a los inversores, donde Apache APISIX simplifica enormemente la implementación. Además, como una puerta de enlace API nativa de la nube, APISIX tiene una comunidad activa y un ecosistema rico, soportando múltiples plugins. Estas ventajas también proporcionan una buena base para la evolución de la arquitectura nativa de la nube de Snowball Finance.

Dificultades de la Transformación Activa-Activa

En el momento en que se aplicaba la arquitectura monolítica, el tráfico de usuarios ingresaba a través del Balanceo de Carga del Servidor (SLB), pasaba por la puerta de enlace para un procesamiento lógico común simple y luego se reenviaba al servicio backend. El servicio backend, a través de un módulo de autenticación integrado, iniciaba la autenticación del usuario con el Centro de Usuarios de Snowball utilizando un SDK y continuaba con el procesamiento posterior tras una autenticación exitosa.

En escenarios prácticos de negocio, algunos puntos problemáticos han surgido gradualmente.

1. Módulos de Autenticación Complejos del SDK

Al implementar la transformación activa-activa, el proveedor y el consumidor de microservicios no pueden desplegarse y lanzarse de manera sincronizada. Cuando el servicio de mercado de Snowball Finance se lanzó por primera vez en la nube, pero el centro de usuarios aún no estaba soportado en la nube, ocurrieron llamadas entre centros de datos. Según estadísticas del centro de usuarios, sus llamadas RPC alcanzaron alrededor de decenas de miles de millones por día, y el volumen máximo puede alcanzar 50,000 QPS, lo que puede resultar en una mayor latencia.

Al mismo tiempo, la lógica de autenticación de Snowball Finance era compleja. Además de los protocolos OAuth2.0/JWT, se debían considerar muchos factores, como las versiones del cliente y múltiples APPs bajo Snowball Finance. Además, el módulo de autenticación estaba integrado en el servicio, lo que dificultaba las actualizaciones.

2. Funcionalidad Limitada de OpenResty

Snowball Finance utilizaba OpenResty como su puerta de enlace anteriormente, pero OpenResty era débil en algunas funciones. Por lo tanto, los desarrolladores necesitaban hacer más personalizaciones al integrar OpenResty con su sistema de monitoreo existente. Además, los ingenieros de DevOps necesitaban agregar scripts personalizados para implementar el proceso de desarrollo secundario.

3. Dependencia del Centro de Registro Autodesarrollado

Actualmente, Snowball Finance realiza el registro de servicios HTTP solicitando al Centro de Registro que lo registre en la puerta de enlace cuando el servicio backend se inicia y que elimine el nodo de servicio cuando el servicio se detiene. El centro de registro realizará verificaciones de salud periódicas de los nodos de servicio. Sin embargo, en comparación con proyectos de código abierto, el costo de mantenimiento de los servicios autodesarrollados es mayor.

Selección de Tecnología de Puerta de Enlace API

Basándose en los puntos problemáticos revelados gradualmente en los escenarios prácticos de negocio, el equipo de Infraestructura de Snowball ha comenzado a investigar productos de puerta de enlace.

El equipo internamente espera garantizar la transparencia del negocio y minimizar los cambios sin introducir demasiadas variables. También desean resolver problemas de manera uniforme a nivel de infraestructura y completar los servicios de autenticación dentro del centro de datos local. Considerando lo anterior, Snowball Finance ha decidido trasladar el servicio de autenticación a la puerta de enlace API.

Snowball Finance espera que la nueva puerta de enlace API cumpla con los siguientes requisitos:

• Alto rendimiento
• Fuerte escalabilidad
• Soporte para múltiples protocolos
• Bajo costo para la autenticación de la puerta de enlace

A continuación, se presenta una lista detallada de selección de tecnología de puerta de enlace API entre OpenResty, Spring Gateway, Kong y APISIX.

Puerta de Enlace	Ventajas	Desventajas	Costo de O&M	Disponibilidad
OpenResty	Altamente personalizable y estable	Poca observabilidad	Alto	Alto
Spring Gateway	Amigable para el desarrollo en Java	el nivel de rendimiento no cumple con los requisitos	Medio	Medio
Kong	Potente y rico en funciones	Base de datos PostgreSQL de un solo punto	Bajo	Medio
APISIX	Nativo de la nube, soporta múltiples lenguajes de programación y tiene una fuerte escalabilidad	/	Bajo	Alto

Después de considerar las demandas internas y comparar los productos de puerta de enlace populares en el mercado, Snowball Finance finalmente eligió Apache APISIX para la arquitectura posterior.

Práctica Basada en Apache APISIX

Arquitectura Ajustada

Como se muestra en la figura anterior, la arquitectura activa-activa actual de los servicios de mercado de Snowball se muestra a la izquierda, que corresponde a la arquitectura en el centro de datos original con pocas modificaciones. El lado derecho muestra la arquitectura activa-activa basada en un diseño multi-región después de la migración a la nube.

Snowball Finance realizó principalmente los siguientes ajustes basados en APISIX:

• Unificó el módulo de autenticación en la capa de proxy y utilizó APISIX para la autenticación unificada. Para los tipos JWT, el plugin jwt-auth de APISIX puede usarse para la autenticación local directamente.
• Compatibilidad con OAuth 2.0 y utilización de APISIX para llamar al Centro de Usuarios de Snowball Finance para su procesamiento.
• Conexión con el centro de registro de servicios RPC backend de Snowball Finance para utilizar sus servicios backend para autenticar cuando falla la autenticación JWT.

Escenarios de Aplicación

Después de conectar el servicio backend a APISIX, se llevaron a cabo algunas prácticas principalmente en los aspectos de autenticación y observabilidad de la puerta de enlace.

Escenario 1: Autenticación en la Puerta de Enlace

Como se mencionó anteriormente, la arquitectura anterior de Snowball Finance no tenía un método de autenticación unificado. Un método dependía del lado de la aplicación interna, que utilizaba un SDK para llamar al centro de usuarios para la autenticación, mientras que el otro utilizaba la autenticación JWT. Cuando estos dos métodos de autenticación coexistían, causaban problemas de escalabilidad y mantenibilidad.

1. Después de integrar APISIX como puerta de enlace, Snowball Finance utilizó la capa de puerta de enlace de APISIX para gestionar uniformemente la autenticación. El método de autenticación JWT original fue reemplazado por el plugin oficial jwt-auth. Configurar y usar el plugin jwt-auth es relativamente simple: solo configurando la información relevante como rutas y upstream en el Dashboard, el plugin se habilita.
2. Snowball Finance utilizó el plugin grpc-transcode para gestionar las llamadas al servicio de autenticación para manejar el método de autenticación relacionado con OAuth 2.0 anterior.

Snowball Finance consideró internamente las siguientes tres soluciones para llamar a gRPC para implementar la autenticación:

• Solución 1: Usar Lua para llamar directamente a gRPC. Dado que esta solución requiere considerar implementaciones relacionadas como el balanceo de carga y el upstream dinámico, el proceso será más complicado, por lo que se descartó.
• Solución 2: Usar corrutinas de Lua para llamar a la lógica de Golang. Snowball Finance descartó esta opción debido a la falta de experiencia práctica correspondiente.
• Solución 3: Usar Lua para hacer llamadas HTTP, y la interfaz gRPC se implementa utilizando el plugin grpc-transcode de APISIX. Gracias a las rápidas iteraciones de optimización de plugins de la comunidad de APISIX, Snowball Finance finalmente eligió esta opción para implementar las llamadas gRPC.

Actualmente, es necesaria la sincronización manual de los archivos de protocol buffer durante la ejecución. Esto se debe a que si el centro de usuarios modifica el archivo de protocol buffer, que no coincide con la versión guardada por APISIX, puede resultar en problemas de autenticación.

Escenario 2: Monitoreo Multidimensional bajo Observabilidad

Es necesario monitorear muchas métricas después del lanzamiento de los sitios web en Snowball Finance, centrándose principalmente en las siguientes tres partes:

• Estado de conexión de NGINX y tráfico de entrada/salida
• Tasa de código de estado de error HTTP (utilizado para la resolución de problemas de servicio o upstream/downstream)
• Latencia de solicitud de APISIX (el tiempo consumido por la ejecución de la lógica cuando APISIX reenvía la solicitud)

Por ejemplo, en algunos casos, la latencia de APISIX parece ser alta (como se muestra en la figura a continuación), lo que está relacionado con la lógica de cálculo de la latencia. Actualmente, la lógica es el tiempo consumido por una sola solicitud HTTP en NGINX menos la latencia de esta solicitud enrutada al upstream. La diferencia entre los dos tiempos consumidos es la métrica de latencia de APISIX.

Después de usar APISIX, agregar o modificar algunos plugins llevará a algunos cambios en la lógica, lo que puede llevar a desviaciones en los datos relacionados con la latencia. Para evitar confundir la autenticidad de los datos, Snowball Finance también agregó un plugin de monitoreo de latencia. Mientras se asegura la precisión de cada monitoreo de datos, también es conveniente para localizar problemas de antemano, facilitando la resolución de problemas.

También es posible utilizar las capacidades de observabilidad de APISIX para recopilar el registro de acceso y entregarlo al panel de tráfico de manera formateada y estandarizada para su visualización y resumen. Esto facilita una comprensión proactiva de las tendencias generales desde múltiples perspectivas, identificando posibles problemas y abordándolos de manera oportuna.

Escenario 3: Escalado del Registro de ZooKeeper

En Snowball Finance, las llamadas gRPC se registran y descubren basándose en el registro de ZooKeeper. En el proceso de implementación de la autenticación, cuando falla la verificación local de JWT, la puerta de enlace API necesita acceder al servicio gRPC en el Centro de Usuarios de Snowball Finance para la autenticación, lo que requiere que la puerta de enlace API obtenga la lista de direcciones del servicio gRPC backend desde el centro de registro.

El plugin oficial de APISIX apisix-seed puede integrar ZooKeeper para el descubrimiento de servicios. Snowball Finance ha realizado algunas personalizaciones más específicas para su propio negocio.

La implementación específica se realiza principalmente en un nodo de contenido de APISIX. Cuando el proceso Worker se inicia, sondea el clúster ZK-Rest como el de la figura a continuación, y luego extrae regularmente los datos de origen y la información de todo el servicio, y los actualiza en la caché local del proceso Worker para actualizar las listas de servicios.

También se puede ver en la figura anterior que el clúster ZK-Rest accede a los datos de ZooKeeper en forma de Rest. Solo agregando una instancia de él se pueden lograr características de alta disponibilidad, eliminando algunas operaciones complicadas. Pero esta operación también trae una desventaja más evidente. Al sondear periódicamente el clúster ZK-Rest, puede causar un retraso en la actualización de la lista de servicios.

Resumen y Perspectivas

Actualmente, Apache APISIX funciona bien como la capa de puerta de enlace dentro de Snowball Finance. Específicamente:

• Se implementan funciones unificadas de autenticación, corte de circuito y limitación de tasa en la capa de puerta de enlace, reduciendo el acoplamiento del sistema general y mejorando la calidad del servicio bajo centros de datos duales.
• Con la ayuda del monitoreo de APISIX, se establece una solución de monitoreo unificada desde la puerta de enlace hasta el servicio, brindando un buen soporte para la resolución global de problemas.
• Se proporciona un enfoque de implementación elegante para la conversión y gestión de servicios del protocolo gRPC.

En el uso posterior, Snowball Finance también planea:

• Aplicar el APISIX Ingress Controller al clúster K8s.
• Usar el plugin grpc-transcode para la conversión de protocolos HTTP/gRPC para lograr una interfaz backend unificada.
• Usar el plugin traffic-split para el etiquetado de tráfico, conectarse al centro de registro de Nacos e implementar lanzamientos canarios y otras gobernanzas de servicios.

En los planes posteriores, Apache APISIX se utilizará para reemplazar el OpenResty existente y finalmente lograr la gestión del tráfico norte-sur de ciclo de vida completo.