APISIX impulsa la actualización de la API Gateway en Tencent BlueKing

Este estudio de caso es compartido por Lei Zhu, Director Técnico de la Plataforma BlueKing PaaS, IEG (Interactive Entertainment Group), Tencent

Acerca de BlueKing

BlueKing es un conjunto interno de investigación y operación integrada PaaS incubado dentro de Tencent IEG (Interactive Entertainment Group), que sirve a múltiples unidades de negocio y plataformas internas. Su función es proporcionar servicios de ciclo de vida completo para los proyectos de la empresa en las etapas de CI (Integración Continua), CD (Entrega Continua) y CO (Operación Continua).

Resumen

Desafíos

• Bajo rendimiento: Bajo rendimiento en condiciones de alta concurrencia y algoritmo de enrutamiento, lo que resulta en un enrutamiento lento y reenvío
• Presión enorme en la base de datos: Las políticas de enrutamiento se almacenan en MySQL. Por lo tanto, la base de datos está estresada con muchas solicitudes de recuperación
• Costos elevados: Redis se usa ampliamente en muchos escenarios, lo que genera altos costos generales
• Aislamiento insuficiente: No se puede lograr un aislamiento físico; conexiones de larga duración inestables
• Soporte de un solo protocolo: Solo soporta el protocolo HTTP
• No soporta enrutamiento dinámico: No es amigable con la liberación canaria y no puede encapsular escenarios
• Falta de descubrimiento de servicios: No es amigable con la arquitectura de microservicios

Objetivos

• Convertir las capacidades de la plataforma en microservicios independientes y llevar a cabo una transformación de microservicios para formar una arquitectura PaaS
• Usar tecnología de bajo código para desarrollar SaaS de manera eficiente y utilizar las capacidades de microservicios de la plataforma PaaS
• Responder de manera flexible a diferentes escenarios de servicio a través de varios SaaS

Resultados

• Se logró la operación y expansión unificada de la puerta de enlace utilizando el recurso personalizado CRD proporcionado por K8s
• Se proporcionaron características más ricas integrando APISIX: gestión de recursos, lanzamiento de versiones, documentos automáticos, gestión de permisos, observabilidad, monitoreo y protección de seguridad
• Se redujeron los costos para soportar escenarios de descubrimiento de servicios con interfaces y regulaciones unificadas para desarrolladores

La Diversidad y Complejidad de los Juegos Requiere la Puerta de Enlace API de BlueKing

Dentro de Tencent, puede haber miles de juegos. Excepto por algunos juegos desarrollados internamente, otros pertenecen a agencias. Los juegos difieren en idiomas, el almacenamiento del que dependen y el estilo arquitectónico determinan que BlueKing desarrolló su propia puerta de enlace API.

Frente a un escenario de negocio tan complejo que involucra una gran cantidad de arquitecturas heterogéneas, BlueKing, como plataforma interna, necesita transformar su puerta de enlace API para desarrollar una arquitectura PaaS, luego usar la tecnología de bajo código para desarrollar SaaS de manera eficiente y utilizar la capacidad de microservicios de la PaaS, y usar varios SaaS para manejar escenarios de servicio.

Para abstraer la arquitectura de BlueKing, podemos obtener un diagrama de API.

• Por un lado, BlueKing es una plataforma complicada con requisitos complejos para una puerta de enlace unificada. Además de funcionar como un proxy para llamar a la API de las plataformas, BlueKing requiere más capacidades de puerta de enlace, por ejemplo, descubrimiento de servicios, autorización y autenticación, enrutamiento dinámico, liberación canaria y limitación de tasa, etc.

• Por otro lado, con el desarrollo de la tecnología nativa en la nube, muchos SaaS y plataformas internas ahora se implementan en clústeres de K8s. Este escenario plantea nuevos requisitos para la puerta de enlace, como el control unificado del tráfico de solicitudes de llamadas externas a través de una puerta de enlace de tráfico unificada o una puerta de enlace API.

Al mismo tiempo, algunos sistemas de negocio internos utilizan algunas de las capacidades de infraestructura de la plataforma BlueKing, como la gestión de contenedores o el monitoreo. También necesitan una puerta de enlace de servicio unificada para gestionar todo el tráfico de llamadas.

Con el desarrollo de los requisitos de negocio internos, la puerta de enlace API de BlueKing necesita soportar escenarios cada vez más diversos.

Puerta de Enlace API de BlueKing 1.0

La Puerta de Enlace API de BlueKing 1.0 tenía como objetivo permitir que el llamador de las plataformas (incluidos varios SaaS y motores de procesos) llamara directamente a la puerta de enlace API para completar la conversión de protocolos y la verificación de autoridad a través de la puerta de enlace.

La arquitectura también era relativamente simple, que se dividía en dos partes: el lado del servidor y el lado de la gestión. Las plataformas deben acceder al lado de la gestión, configurar las direcciones de recursos API y sus permisos correspondientes de las plataformas, y finalmente registrar sus servicios con la Puerta de Enlace API.

Después de varios años, con el aumento de solicitudes y escenarios complejos, las deficiencias de la Puerta de Enlace API de BlueKing 1.0 comenzaron a aparecer gradualmente. Por ejemplo:

• Rendimiento deficiente del marco: Se eligió el marco Django para la implementación. Su rendimiento es promedio en escenarios de alta concurrencia y se vuelve limitado cuando procesa solicitudes masivas.

• Rendimiento promedio de la implementación de enrutamiento: El rendimiento del algoritmo utilizado en el enrutamiento de API es bajo, lo que afecta la velocidad de coincidencia y reenvío de rutas.

• Las bases de datos están estresadas: Todas las políticas de enrutamiento se almacenan en MySQL. Cuando hay muchas reglas, muchas solicitudes de recuperación necesitan ser llevadas con una gran presión de consulta.

• Costos de red elevados: Redis se usa ampliamente en varios escenarios, lo que resulta en demasiados costos generales de red.

Puerta de Enlace API de BlueKing 2.0

Para resolver los problemas anteriores, BlueKing iteró sobre la base de la versión 1.0 y diseñó e implementó la versión 2.0. En comparación con la generación anterior, el cambio más significativo de la versión 2.0 fue la reimplementación del marco de la puerta de enlace y la capa de reenvío en Golang porque Golang tiene más ventajas que Python en el manejo de solicitudes concurrentes masivas.

También se hicieron otros cambios de optimización. Por ejemplo, se mantuvo una implementación de enrutamiento más eficiente en la memoria; se introdujo una caché basada en memoria en la capa intermedia para reducir la dependencia de Redis. La nueva arquitectura también agrega la gestión del ciclo de vida para puertas de enlace con múltiples versiones y entornos e introduce un mecanismo de plugin extensible para facilitar que los desarrolladores amplíen las capacidades de la puerta de enlace a través de plugins.

En general, la Puerta de Enlace API de BlueKing 2.0 aborda los problemas de rendimiento y la mayoría de los puntos de dolor encontrados en la versión 1.0. Pero con el tiempo, nuevos problemas comenzaron a surgir lentamente.

• Aislamiento insuficiente: No se puede lograr un aislamiento físico real; el proceso de liberación causará que las conexiones de larga duración se desconecten

• Soporte de un solo protocolo: Solo se soporta HTTP, y la demanda de protocolos no HTTP está aumentando en escenarios reales

• No soporta reglas de enrutamiento dinámico: No soporta reglas de enrutamiento dinámico coincidentes por condiciones; no es lo suficientemente amigable para escenarios de liberación canaria; no puede combinar y encapsular escenarios

• Falta de capacidad de descubrimiento de servicios: Falta de capacidad de descubrimiento de servicios automático, no es amigable con la arquitectura de microservicios

APISIX Destaca en la Selección Tecnológica de la Puerta de Enlace API de BlueKing

Hay muchos sistemas de productos en la empresa que necesitan usar la puerta de enlace API. Es muy difícil integrar todos los diversos requisitos para la puerta de enlace en el mismo conjunto de puertas de enlace.

Por lo tanto, tenemos la idea de diseñar una puerta de enlace distribuida. Es decir, una gran puerta de enlace se divide en muchas micro puertas de enlace, que se utilizan para equilibrar las diferencias en los requisitos de diferentes sistemas para puertas de enlace." dijo Zhu.

Los componentes de la arquitectura de puerta de enlace distribuida se dividen principalmente en dos categorías: el lado de la gestión y la instancia de micro puerta de enlace.

El lado de la gestión gestiona y controla uniformemente cada micro puerta de enlace, y el administrador de cada puerta de enlace configura y gestiona la puerta de enlace. Las instancias de micro puerta de enlace son servicios de puerta de enlace individuales implementados de forma independiente, que asumen el tráfico de acceso de cada grupo específico de servicios y realizan controles de acceso relacionados según la configuración del lado de la gestión. Todas las instancias de micro puerta de enlace están controladas por el mismo conjunto de lados de gestión.

"En términos de la selección tecnológica de la micro puerta de enlace, nos referimos a varias puertas de enlace de código abierto populares en el mercado, como Kong y Tyk. Después de comparar popularidad, pila tecnológica, soporte de protocolos y otros niveles, finalmente elegimos APISIX como la tecnología de backend más importante de nuestra micro puerta de enlace." dijo Zhu.

Zhu dijo que BlueKing seleccionó APISIX porque está implementado basado en NGINX + Lua, por lo que su rendimiento general tiene ventajas en comparación con aquellos basados en Golang. Además, APISIX es notable en escalabilidad, y también soporta la expansión de capacidades a través de plugins de múltiples lenguajes de programación. Se presenciaron muchos casos de uso típicos.

Además, gracias a su gran compatibilidad, APISIX puede personalizarse según las necesidades de BlueKing. Por ejemplo, sobre la base de APISIX, BlueKing personalizó la superficie de control de APISIX según los requisitos internos.

Puerta de Enlace API de BlueKing 3.0 Basada en APISIX

En el entorno nativo en la nube, K8s es el componente básico más crítico que necesita atención. Debido a que toda la micro puerta de enlace está diseñada para el entorno nativo en la nube, la versión 3.0 tiene un nuevo diseño de arquitectura basado en K8s.

La parte central es usar el recurso personalizado CRD proporcionado por K8s para realizar todo el conjunto de operaciones y expansión de la puerta de enlace API.

Como se muestra en la figura anterior, la puerta de enlace introduce un conjunto de recursos CRD de K8s, incluyendo BkGatewayStage (entorno de puerta de enlace), BkGatewayService (servicio backend), etc. A través de estos CRDs, BlueKing puede controlar el comportamiento específico de cada instancia de micro puerta de enlace.

Varios "Operadores" en la figura son la parte central de esta arquitectura. Arriba está el servicio Plugin Operators, que contiene una serie de operadores de plugins. Por ejemplo, el Operador responsable del descubrimiento de servicios escribirá la dirección del servicio backend registrado en el centro de descubrimiento de servicios en el clúster de K8s.

El Operador central en el medio monitorea todos los recursos CRD relacionados con la puerta de enlace. El reconciliador de recursos es responsable de convertir la configuración de la puerta de enlace en un formato que la instancia de micro puerta de enlace APISIX pueda entender, logrando así la gestión del ciclo de vida completo de la micro puerta de enlace.

Este conjunto de micro puerta de enlace se divide en dos tipos de implementación:

• Puerta de enlace compartida: El tipo predeterminado, que se implementa en la plataforma, y la dirección de acceso API se genera y gestiona de manera uniforme por la plataforma.

• Puerta de enlace dedicada: El usuario implementa una instancia de "micro puerta de enlace", que se convierte en una "puerta de enlace dedicada" después de acceder a la plataforma. La dirección de acceso API necesita ser gestionada manualmente, y el tráfico fluye directamente desde la "puerta de enlace dedicada" al servicio backend.

Solo hay un lado de gestión unificado, cuyas capacidades, como la gestión de múltiples entornos y el control de acceso, son compartidas por todas las puertas de enlace. Sin embargo, entre los diferentes tipos de instancias de micro puerta de enlace que gestiona, los conjuntos de características soportados difieren entre sí.

Tomando como ejemplo la instancia de puerta de enlace compartida, el conjunto de características que soporta es relativamente básico, que incluye principalmente autenticación de inicio de sesión unificada, limitación de tasa y soporte de múltiples protocolos. Pero las instancias de puerta de enlace dedicada independientes tienen sus capacidades personalizadas únicas. Debido a que la puerta de enlace dedicada y el negocio pertenecen al mismo clúster, puede realizar rápidamente enrutamiento dinámico, descubrimiento de servicios personalizado, etc., y usar la robusta escalabilidad de APISIX para personalizar más capacidades.

Basado en la arquitectura y modos anteriores, la Puerta de Enlace API de BlueKing 3.0 proporciona funciones más ricas con el soporte de APISIX. Por ejemplo, gestión de recursos, lanzamiento de versiones, documentos automáticos, SDK, gestión de permisos, observabilidad, monitoreo y alertas, y protección de seguridad.

Escenarios Prácticos de la Puerta de Enlace BlueKing 3.0 Usando APISIX

Hay cuatro escenarios prácticos típicos dentro de Tencent: descubrimiento de servicios, autenticación unificada, enrutamiento dinámico y gestión de licencias del cliente.

Descubrimiento de Servicios

El descubrimiento de servicios es una capacidad básica requerida por la arquitectura de microservicios. Internamente, se puede implementar a través del recurso personalizado CRD. Una definición YAML válida de descubrimiento de servicios se muestra en el código en el lado derecho de la figura a continuación.

Después de que los recursos CRD anteriores se escriben en el clúster de K8s, se activarán las acciones relacionadas de los controladores relacionados con el descubrimiento de servicios. Posteriormente, el reconciliador puede capturar la configuración de descubrimiento de servicios correspondiente y crear objetos de programa relacionados con el descubrimiento de servicios.

Luego, el reconciliador lee la información de dirección relevante del centro de descubrimiento de servicios a través de la interfaz de descubrimiento de servicios integrada como Watcher y Lister y reescribe la dirección obtenida en el clúster de K8s a través del recurso CRD BkGatewayEndpoints.

Después de un procesamiento complejo por parte del Operador central en el lado derecho, estos puntos finales finalmente se sincronizan con el upstream correspondiente a APISIX. Se completa un proceso completo de descubrimiento de servicios.

Para facilitar el desarrollo, BlueKing implementó un marco de descubrimiento de servicios general, que proporciona una interfaz y especificación de desarrollo unificada y puede usarse para soportar otros tipos de escenarios de descubrimiento de servicios a bajo costo.

Autenticación Unificada

La parte de autenticación unificada es relativamente simple. En la práctica diaria, hay solicitudes de tres fuentes: navegadores, plataformas y usuarios individuales. Basado en APISIX, BlueKing personalizó un plugin de autenticación, BK-Auth, para lograr la autenticación unificada.

El proceso de implementación específico se muestra en la figura anterior. Después de la solicitud, el plugin leerá la información de credenciales relevante del encabezado y luego llamará uniformemente al servicio de autenticación BK-Auth para verificar la credencial y leer la información de SaaS correspondiente. Luego, el plugin usará la clave privada acordada con el backend para emitir un token JWT y escribirlo en el encabezado de la solicitud, y finalmente, escribirlo en la variable APISIX.

Además de la autenticación unificada, también hay algunos escenarios de autenticación complejos en proyectos internos. Su función principal es juzgar si el SaaS tiene permiso cuando el SaaS llama a un cierto recurso de una plataforma. La autenticación de recursos unificada también se implementa en Golang a través del plugin APISIX, como se muestra en la figura a continuación.

Las solicitudes del cliente pueden obtener primero la información de la aplicación SaaS a través del enlace de autenticación, luego interactuar con el plugin de autenticación basado en RPC al pasar el ext-plugin. En este momento, el plugin de autenticación consultará directamente los datos relacionados con la autenticación en la caché, sincronizada por el lado de la gestión a través del mecanismo completo e incremental, y luego completará la autenticación.

Enrutamiento Dinámico

Un escenario de aplicación típico de enrutamiento dinámico proviene de la plataforma de gestión de contenedores de BlueKing. La plataforma de contenedores de BlueKing gestiona muchos clústeres de K8s, algunos de los cuales son clústeres de servicios y otros son clústeres de datos.

Como usuario, a menudo necesita solicitar los APIServers de estos clústeres. Cuando una solicitud de usuario ingresa a la micro puerta de enlace, la puerta de enlace determina a qué APIServer del clúster reenviarla según la ruta de la solicitud.

Después de que la solicitud ingresa, el plugin de enrutamiento dinámico primero extrae la información de ID del clúster, luego reescribe la ruta y luego determina si el clúster está conectado directamente.

Para clústeres no conectados directamente, primero se genera un upstream del administrador de clústeres BCS y luego interactúa con el Agente BCS a través de él, y finalmente pasa la solicitud al APIServer del clúster.

Para clústeres conectados directamente, el proceso es similar al plugin de autenticación unificada anterior, y el plugin sincronizará periódicamente alguna información básica relacionada con el clúster. Después de encontrar la información del clúster, genera el upstream relevante, redefine la lógica de conexión a través del plugin APISIX y finalmente envía la solicitud al APIServer del clúster.

Gestión de Certificados de Cliente

En los escenarios prácticos de BlueKing, hay una clase de sistemas que utilizan un modo de verificación de certificados de cliente más complejo al registrar recursos en la puerta de enlace. Por lo tanto, si un usuario desea solicitar sus recursos, debe proporcionar un certificado de cliente válido.

La implementación específica se muestra en la figura anterior. El administrador de la puerta de enlace necesita configurar el certificado de cliente utilizado por la puerta de enlace para diferentes entornos en el lado de la gestión. Después de la configuración, el certificado se publicará en el clúster de K8s, donde se encuentra la micro puerta de enlace correspondiente.

Este proceso utiliza algunos recursos CRD y recursos Secret oficiales de K8s y será reconciliado continuamente por el servicio Operador central, como encontrar el certificado correspondiente según el nombre de dominio. La configuración efectiva del certificado de cliente finalmente se reflejará en la configuración relevante del Servicio APISIX. (Como se muestra en el cuadro rojo en la parte superior derecha de la figura anterior)

Resumen

Apache APISIX es una puerta de enlace API nativa en la nube de código abierto, dinámica, escalable y de alto rendimiento para todas sus API y microservicios. Donado a la Fundación Apache Software por API7.ai, APISIX ha crecido hasta convertirse en un proyecto de código abierto de nivel superior de Apache.

Con el desarrollo de la arquitectura de microservicios y los proyectos de negocio internos, la puerta de enlace API anterior ya no puede satisfacer las necesidades. Tencent BlueKing no solo resolvió el problema, sino que también proporcionó características más ricas aprovechando APISIX.