¿Cómo se integra vivo con APISIX?

Visión general

Desde mayo de 2021, vivo ha introducido Apache APISIX como su puerta de enlace de API. Después de más de un año de práctica en vivo, APISIX ha resuelto muchos problemas técnicos y comerciales y se ha utilizado a gran escala.

Puntos de dolor antes de usar APISIX

• Gestión compleja de escenarios comerciales y mantenimiento del sistema

  Debido al rápido crecimiento del negocio, existen diversos escenarios y sistemas que los atienden, lo que requiere que vivo tenga una forma unificada de gestionarlos.

• Interacción entre el plano de datos y el plano de control

  Para empresas medianas y grandes como vivo, es inesperado que problemas menores en el plano de datos afecten al plano de control.

• Sin soporte para recursos multidimensionales

  Los diversos proyectos generan diferentes nombres de dominio y URLs. El departamento comercial necesita buscar según diferentes dimensiones de recursos.

• Impacto incontrolable de los problemas

  Dado que los proyectos de vivo son complejos, el efecto de los problemas encontrados es incontrolable. El uso de algunos complementos complicados intensifica esto.

Al reemplazar NGINX con APISIX, vivo finalmente logró una serie de logros, como se detalla a continuación.

Logros después de usar APISIX

• Alta disponibilidad

  No ha ocurrido ninguna falla importante desde que APISIX se lanzó en vivo, y la disponibilidad del sistema supera el 99.99%.

• Alto rendimiento

  Al manejar un tráfico en línea significativo y servir a una gran cantidad de servicios, el tráfico de reenvío en línea actual alcanza casi un millón de QPS (Consultas por segundo).

• Funciones ricas

  Gracias a las funciones ricas de APISIX, APISIX puede cubrir casi todos los escenarios comunes de proxy de NGINX. Alrededor del 50% de los proyectos de vivo se han migrado de NGINX a los clústeres de APISIX.

• Apoyo a la construcción y desarrollo de cloud-native

  El metal desnudo de K8s que soporta la contenerización ha alcanzado una escala de 10,000. Alrededor del 40% de los proyectos se ha migrado de metal desnudo y máquinas virtuales a la plataforma de contenedores K8s, apoyando y promoviendo el progreso de la contenerización de vivo.

Diseño del sistema de vivo basado en APISIX

A continuación, veamos el diseño del sistema de vivo después de adoptar APISIX.

Visualización de la arquitectura personalizada en APISIX

Del diagrama anterior, podemos analizar que vivo ha:

• Completado la construcción de las puertas de enlace de tráfico de Capa 4 y Capa 7, que son soportadas por APISIX
• Logrado el acceso al tráfico y la implementación mixta de metal desnudo, máquinas virtuales y contenedores
• Implementado la gestión de clústeres de APISIX
• Conectado la plataforma interna de DevOps y los servicios de implementación comercial para acceder al tráfico de manera rápida y automática
• Mejorado la construcción de monitoreo

Mejoras en la gestión de configuración y lanzamiento

Para satisfacer mejor las necesidades reales del departamento comercial, vivo ha realizado una serie de adaptaciones en APISIX. A continuación, se detallan algunos de esos ajustes, incluyendo la alteración del plano de control, la gestión de separación de clústeres y el reenvío de datos.

Alteración del plano de control

El proceso completo puede ser el siguiente:

Después de configurar los datos en la plataforma de cambios A6, la información se entrega a través de notificaciones RPC a ManagerAPI, que es construido por vivo basado en el APISIX Dashboard de código abierto.

Luego, el tráfico se envía a apisix-agent. APISIX sondea apisix-agent regularmente a través del proceso privilegiado para obtener tareas de cambio en lotes. A continuación, el proceso privilegiado notifica al worker a través de colas compartidas para realizar el cambio en la memoria.

Mientras tanto, APISIX informa a apisix-agent sobre el resultado de las tareas y luego las entrega a ManagerAPI. Además, la plataforma de cambios A6 puede sondear ManagerAPI para obtener los resultados de las tareas.

etcd es un punto destacado de APISIX, permitiendo la operación independiente de los planos de control y datos. Considerando la singularidad de su arquitectura, vivo descartó etcd en el proceso anterior. Aquí hay algunas razones.

Debido a la diversidad de proyectos de vivo, existen varios nombres de dominio y URLs. Además, los departamentos comerciales necesitan consultar diferentes dimensiones. Gracias a la adaptabilidad de APISIX no solo con etcd sino también con diversos tipos de bases de datos, vivo pudo utilizar fácilmente bases de datos como MongoDB para trabajar junto con APISIX.

Además, vivo realizó las siguientes contribuciones para ser compatible con Apache APISIX.

• Desarrollo del componente Agent

  Desde mayo de 2021, vivo introdujo Apache APISIX. Considerando el contexto técnico, vivo no estaba seguro de poder adoptar APISIX debido a la falta de experiencia con OpenResty y Lua. Además, hay muchas tareas no relacionadas con el reenvío, como la recopilación de registros y el manejo de monitoreo, lo que podría aumentar la complejidad de la gestión del plano de datos. En consecuencia, vivo desarrolló el componente agent para reducir la complejidad del desarrollo.

• Escritura de datos en disco

  Para hacer que el sistema sea ajustable y permitir que el plano de datos funcione de manera independiente, reduciendo así la dependencia del plano de control, vivo escribió el archivo de configuración en el disco. Cuando APISIX se inicia, admite la extracción completa desde el centro de configuración y también admite la obtención directa de recursos de configuración desde el directorio de archivos del disco local. Esta forma mejora drásticamente la independencia de los datos y la robustez del sistema. Además, es muy intuitivo entender la información de ruta y upstream configurada en el disco, lo que es útil para la resolución de problemas.

• Devolución de resultados de tareas de cambio

  Como una empresa de gran tamaño, vivo necesita asegurarse de que los cambios en recursos como routers y upstreams puedan garantizarse como efectivos y exitosos, y que el sistema pueda informar el error incluso si estos cambios fallan. Tal lógica de ACK (Código de reconocimiento) asegura que los trabajadores de NGINX en una máquina puedan devolver la llamada. Cuando las tareas de devolución de llamada son exitosas, todos los trabajadores en APISIX actualizarán los cambios de recursos a la memoria relevante.

Gestión de separación de clústeres

La versión de código abierto de APISIX proporciona etcd para que todos lo compartan. Sin embargo, los proyectos de la empresa son complejos, y los problemas encontrados son incontrolables. Además, es inevitable usar complementos complicados, lo que afecta el rendimiento del sistema.

Por lo tanto, se gestiona mediante la separación de clústeres para lograr el aislamiento de la configuración del clúster en APISIX, lo que puede:

• Controlar el dominio de fallas y apoyar efectivamente la complejidad de los proyectos sin afectar a otros proyectos
• Reducir efectivamente la carga causada por la capa no relacionada con el reenvío de APISIX cuando los nodos de contenedores cambian con frecuencia
• Reducir el impacto de la carga causada por la verificación de salud

Aumento del QPS soportado por HTTPS

Según los requisitos relevantes del Ministerio de Industria y Tecnología de la Información de China, el tráfico de la red externa debe pasar por el protocolo HTTPS. Como un protocolo de cifrado HTTP basado en TLS, HTTPS carga mucho la CPU en el proceso de cifrado y descifrado.

Cuando las configuraciones de enrutamiento y otras son las mismas, el tráfico que HTTPS puede soportar es aproximadamente 1/8 - 1/10 del que puede soportar HTTP.

Después de aplicar el parche de la tarjeta aceleradora Intel® QAT (QuickAssist Technology), vivo delega el manejo del descifrado a la tarjeta aceleradora QAT, lo que libera la CPU, aumentando así el QPS soportado por HTTPS en una sola máquina. Como se puede ver en la figura a continuación, la capacidad de carga HTTPS de una sola máquina se duplica aproximadamente.

Cómo combina vivo los negocios con APISIX

Apoyo al desarrollo de contenerización

Para apoyar el desarrollo de contenerización, vivo desarrolló un controlador de ingreso de K8s. A continuación, se detallan algunas de sus funciones.

1. Adaptación al mecanismo de cambio de configuración de empuje asíncrono modificado por vivo

2. Realización de notificaciones de procesamiento de eventos de múltiples clústeres de K8s a APISIX

3. Manejo de escenarios de proyectos complejos como:

• Un servidor con múltiples puertos

• Cuando otros servidores de marcos RPC, como Dubbo y gRPC, se conectan a K8s, se requiere un conjunto unificado de lógica de procesamiento para notificar a APISIX o a otros marcos la información del puerto según las características de configuración de los proyectos

4. Adaptación a las necesidades particulares de los escenarios de automatización internos de la empresa, como DevOps, facilitando la implementación rápida y habilitando el tráfico

Ayuda en la migración de proyectos de NGINX a APISIX

Los proyectos de vivo están desplegados en el clúster existente de NGINX y han estado funcionando de manera estable durante mucho tiempo. Sin embargo, esto trae cargas de trabajo no relacionadas con el negocio e inestabilidad a los proyectos. En consecuencia, es un desafío realizar la migración. Entonces, ¿cómo promover la migración de proyectos a APISIX?

• Primero, encontrar un proyecto de un departamento cooperativo, servir bien al departamento comercial para establecer un punto de referencia y proporcionar orientación técnica y capacitación

• Construir un sistema de plano de control fácil de usar para facilitar el acceso comercial y la gestión multidimensional de los departamentos comerciales

• Proporcionar capacidad de conversión automática y configuración básica para convertir la configuración de NGINX a la configuración de APISIX

Actualización de APISIX y soporte de su versión de código abierto

Basado en la versión 2.4 de APISIX, vivo realizó algunos ajustes y lanzó la nueva versión, que se actualizó a una más reciente en el segundo trimestre de este año.

Por un lado, gracias a la arquitectura modular de APISIX, es relativamente fácil integrar el código Lua modificado por vivo en la rama de la versión superior de APISIX. Por otro lado, vivo también sigue actualizando la sección de OpenResty, con aproximadamente una versión por año. Dado que vivo utiliza mucho PATCH y algunas funciones útiles como QAT, actualizar este componente es difícil y laborioso.

La versión gratuita de las características de la comunidad de NGINX se actualiza lentamente y está inactiva. Vivo está considerando si construir conjuntamente con APISIX. Para reducir la mano de obra necesaria para realizar pruebas relacionadas con el sistema, vivo adoptó Robot Framework, un marco de automatización de pruebas genérico para pruebas de integración del sistema. Están promoviendo los componentes relevantes para la cobertura de pruebas unitarias y el modelo de desarrollo de TDD (Desarrollo guiado por pruebas).

Planificación futura de vivo

El próximo año, vivo planea extender APISIX como una puerta de enlace de tráfico a una puerta de enlace de API, utilizando sus ventajas de limitación de tasa, autenticación, corte de circuito, etc. Considerando combinar APISIX con DPDK-NGINX, vivo también cultivará personal técnico y se unirá al establecimiento de la comunidad. Además, consolidará las habilidades básicas para sentar una buena base, construyendo gobernanza de tráfico y servicios.

Bienvenido a aprender más sobre Apache APISIX.

Puede contactarnos en https://api7.ai/contact.