Práctica de API Gateway en Tencent con Apache APISIX

¿Qué es un API Gateway?

Arquitectura tradicional

Antes de integrarnos con un API Gateway, teníamos pocas formas de reutilizar algunas funcionalidades generales, como:

• Seguridad: autenticación, autorización, anti-replay, anti-manipulación, anti-DDoS, etc.
• Fiabilidad: degradación de servicios, fusión, limitación de tráfico, etc.

Bajo la arquitectura tradicional, la forma más común de manejar este caso es colocarlos en un marco de servicios e implementarlos a través de AOP, similar al siguiente diagrama de arquitectura:

El diagrama de arquitectura tradicional tiene los siguientes módulos.

• Backend: Servicios backend
• AOP: Capa AOP llevada por el marco;
• SD: Centro de servicios, utilizado para la detección de servicios internos. En tecnologías nativas de la nube, a menudo usamos Service para reemplazar este componente;
• LB: Balanceador de carga, lo usamos en el límite de la red como punto de entrada para el tráfico externo.

Este tipo de arquitectura fue muy común en los diseños de los primeros años, lo que dio lugar a muchos marcos de servicios extensos y completos, como Dubbo, SpringCloud, etc., y encontraremos que la mayoría de ellos tienen muchas características similares.

La ventaja de esta arquitectura es que las relaciones entre los componentes son más accesibles y evidentes, y reduce un reenvío en la transmisión de la red. Pero sus desventajas también son evidentes:

• Las características estándar obligan a actualizaciones de los servicios de negocio: dado que se utilizan referencias de código, tenemos que recompilar los servicios de negocio para que las características sean efectivas. Algunos equipos que no logran un lanzamiento continuo tienen que liberar durante el tiempo de inactividad del negocio.
• Difícil de gestionar versiones: Dado que no podemos actualizar todos los servicios a la última versión cada vez que lanzamos, después de un tiempo, el rendimiento de varios servicios será inconsistente.

¿Por qué no poner esas mismas funciones en un servicio independiente, que pueda actualizarse o mantenerse por separado?

Modo Gateway

En comparación con la arquitectura tradicional, podemos ver un componente adicional entre los servicios backend y el LB: Gateway.

Un gateway generalmente contiene muchas características estándar y reutilizables, como Autenticación, Gestión de Tráfico, etc. A continuación, se presentan los beneficios que podríamos obtener:

• Gateway es un componente dependiente en los sistemas, y podríamos tener una mejor experiencia de mantenimiento.
• Gateway es independiente del lenguaje.

Sin embargo, el modo gateway también tiene sus desventajas:

• Debido a que primero redirigimos el tráfico al gateway, tenemos un reenvío adicional y una mayor latencia. Esto causará una mayor complejidad en la resolución de problemas.
• Si el gateway no funciona correctamente, puede convertirse en un cuello de botella para todo el sistema.

Cómo equilibrar los beneficios y desventajas del modelo de gateway es un desafío para el equipo técnico. Veamos cómo el OTeam de Tencent trabaja con Apache APISIX.

Introducción

OTeam

El OTeam de Tencent es un grupo de equipos, y cada equipo mantiene uno o varios productos técnicos. Su objetivo es construir una plataforma intermedia estable pero robusta para los sistemas internos. Uno de los OTeams soporta la distribución personalizada interna de Apache APISIX en Tencent.

Para integrar las ruedas duplicadas dentro de la empresa y consolidar el terreno técnico intermedio. Tencent colocó varios productos técnicos de la misma naturaleza en el mismo Oteam, integrando al personal de mantenimiento y lanzándolos todos juntos, para que pudieran fusionarse gradualmente en un producto grande y completo, que es Oteam.

Algunos Oteams tienen hasta una docena de productos bajo su responsabilidad, mientras que otros tienen solo uno. Por ejemplo, el Oteam donde se encuentra Apache APISIX tiene solo un producto, Apache APISIX. El propósito original de este Oteam es mantener las características personalizadas de Apache APISIX dentro de Tencent.

Apache APISIX

Apache APISIX es un proyecto de nivel superior de la Apache Software Foundation, y aquí hay algunos puntos clave:

• Apache APISIX es un API Gateway dinámico y nativo de la nube basado en OpenResty, con un rendimiento de enrutamiento superior a Kong.
• Apache APISIX proporciona ricas características de gestión de tráfico, como balanceo de carga, upstream dinámico, lanzamiento canario, corte de circuito, autenticación, observabilidad, y más.
• Apache APISIX es bueno manejando tráfico tradicional norte-sur, así como tráfico este-oeste entre servicios. También puede usarse como un controlador de ingress de k8s.
• Apache APISIX utiliza por defecto ETCD como centro de configuración, lo que permite actualizar la configuración en segundos.
• Apache APISIX se gradúa de la Apache Software Foundation y solo toma unos meses.

Estrategia operativa del OTeam de Tencent

El diagrama anterior muestra cómo el OTeam trabaja con la comunidad de Apache APISIX:

• Los usuarios dan retroalimentación o requisitos a través de GitHub Issue.
• Los miembros del OTeam discuten soluciones en reuniones semanales o responden directamente en el Issue.
• Implementan características o corrigen errores según la discusión.
• Revisión de código y verificación de CI, luego se libera si es necesario.

Este proceso es similar al de otros proyectos de código abierto. Aquí hay algunos puntos clave:

• Después de resolver el Issue, los ingenieros de Tencent determinarán si el problema también es un problema común para la comunidad. Si es así, presentarán un PR a la comunidad.
• El OTeam de Tencent revisará regularmente las nuevas características de Apache APISIX para determinar si son estables y si también son un punto de dolor para Tencent. Si la respuesta es sí, seleccionarán los códigos relevantes.

Al principio, el OTeam sincronizaba códigos con Apache APISIX cada 12 horas para poder seguir rápidamente a Apache APISIX, pero este enfoque trajo algunos problemas:

• Después de sincronizar códigos con Apache APISIX, podíamos asegurarnos de que las regulaciones eran correctas, pero no podíamos garantizar que los códigos fueran estables. Algunos errores ocasionales ocurrían en casos de concurrencia.
• Los códigos fusionados a veces causaban conflictos lógicos con múltiples PRs upstream, pero el CI de Apache APISIX y el OTeam no podían detectar este caso. Solo cuando fusionábamos PRs a la rama principal podíamos descubrir que algo había salido mal.

Por estas razones, el OTeam ahora está seleccionando códigos para las características requeridas después de revisiones internas.

Tendencias del OTeam

Hasta mayo de 2021, el OTeam ha implementado Apache APISIX en más de diez equipos dentro de Tencent, con un tráfico diario de solicitudes de negocio que supera los mil millones. Al mismo tiempo, el OTeam también ha desarrollado más de diez características para Apache APISIX, incluyendo Descubrimiento de Servicios, Conversión de Protocolo RPC y conexión con la plataforma de monitoreo.

Al mismo tiempo, el OTeam también ha contribuido con algunas características estándar a la comunidad de Apache APISIX. Actualmente, dos miembros del equipo OTeam también son PMCs de Apache APISIX, y el OTeam ha contribuido con más de 50 PRs a la comunidad. Creemos que el OTeam seguirá cooperando con la comunidad de Apache APISIX en el futuro.

Características internas del OTeam

Puntos de dolor internos

La responsabilidad principal del OTeam es mantener las características de Apache APISIX para Tencent. Veamos qué puntos de dolor encontró el OTeam.

• El marco RPC no es amigable con el frontend: hay muchos proyectos heredados dentro de Tencent que usan el marco TARS, no soporta directamente el protocolo HTTP como TRPC, solo soporta el protocolo TCP más tradicional del marco RPC, y el contenido de transporte utiliza un protocolo binario específico. Necesitamos mantener un servicio intermedio para convertir estas interfaces en una forma amigable para el frontend, HTTP + JSON.
• Diversificación de los centros de servicios: Hay muchos Centros de Servicios en los servicios internos de Tencent, como CL5, L5, Polaris, etc. Aunque gradualmente usaremos el mismo Centro de Servicios, durante este período extendido usaremos múltiples centros de servicios simultáneamente. El Apache APISIX inicial no soporta esto.
• Alarma: Como un gateway, la alarma no es una dirección en la que debería enfocarse, pero como un componente fundamental, la alarma debe ser un componente requerido para el equipo. Cómo resolver el problema de la alarma también es un punto de dolor.
• Seguridad: Tencent tiene un gran volumen de tráfico y requisitos de seguridad. Muchos productos toC están usando el OTeam, y tienen que enfrentar un gran número de abusos de usuarios y ataques desde la red. Los casos más típicos son DDos, replay, manipulación de solicitudes, etc. ¿Podemos resolver estos problemas en la capa del gateway?

Resolución de problemas

El diagrama anterior proviene de una simplificación de un caso de implementación dentro de Tencent. Podemos ver que varios problemas planteados anteriormente han sido resueltos en el OTeam:

• Conversión de Protocolo: basado en Apache APISIX, el OTeam logra la conversión de protocolos TRPC y TARS. Aquellos que no realizan servicios heredados HTTP pueden usar directamente el plugin de conversión en el gateway para cumplir con los requisitos de transferencia HTTP y RPC sin escribir servicios intermedios.
• Múltiples Centros de Servicios: Hemos contribuido con esta característica a la comunidad. Informe a la plataforma de monitoreo: El OTeam de Tencent usa plugins para conectarse con plataformas de monitoreo. Los usuarios solo necesitan hacer algunas configuraciones, y luego el sistema reportará automáticamente métricas, logs. Por cierto, los usuarios pueden configurar políticas de alarma en la plataforma de monitoreo.
• Anti-replay y anti-manipulación: El OTeam implementa plugins anti-replay y anti-manipulación, permitiendo que los negocios externos que necesitan estas capacidades las usen directamente para proteger la seguridad de sus APIs.

Esperamos que estos ejemplos puedan ayudarte a explorar más escenarios de uso de Apache APISIX y a usarlo mejor como una plataforma útil. Por ejemplo, alguien usó el gateway para implementar algunas especificaciones de API obligatorias según las políticas de Tencent Cloud.

Resumen

El OTeam ayudó al equipo de negocio a resolver sus puntos de dolor y mejoró continuamente las características de Apache APISIX dentro de Tencent, avanzando junto con el desarrollo de la comunidad.

Si tu equipo no tiene un gateway, puedes buscar y aprender más sobre Apache APISIX y eres bienvenido a participar en la comunidad de Apache APISIX.