## Antecedentes

En los últimos años, muchos software de conferencias en línea conocidos han surgido con el desarrollo de reuniones en línea y el trabajo remoto. El típico, Zoom, se ha convertido en una herramienta de reunión popular para la oficina en casa, la enseñanza en línea y los escenarios sociales. Cuenta con 350 millones de participantes diarios en reuniones y casi 470,000 clientes empresariales de pago que utilizan la plataforma. Además, datos recientes muestran que la cantidad de minutos utilizados para facilitar reuniones ha alcanzado más de 3.3 billones por año.

Sin embargo, como otras empresas de SaaS e internet, Zoom ha enfrentado desafíos técnicos a medida que su negocio se expande rápidamente.

- **Un número significativo de microservicios**: Debido al rápido crecimiento del negocio y los equipos de Zoom, se deben entregar más de 100 servicios backend. Sin embargo, es difícil gestionar eficientemente una gran cantidad de microservicios.

- **Diversos entornos de despliegue**: Las empresas SaaS a menudo encuentran escenarios en los que los clientes deben desplegar en nubes dedicadas, nubes privadas y multi-nubes. Los servicios de negocio de Zoom están en todo el mundo, por lo que existen desafíos técnicos con una gran cantidad de entornos de nube híbrida.

- **Infraestructura compleja**: Las empresas de internet de mediano y gran tamaño generalmente tienen equipos de infraestructura dedicados responsables de puertas de enlace API, centros de configuración, gestión de claves, registros, alarmas de monitoreo, bases de datos, etc.
Dado que los equipos de gestión de I+D de Zoom están distribuidos globalmente, es un gran desafío integrar estos middleware e infraestructura complejos en la canalización de entrega continua.

**Los desafíos anteriores no son una relación aditiva simple, sino una relación multiplicativa. En otras palabras, la situación real es mucho más compleja.** Sin embargo, las herramientas de código abierto que Zoom utilizaba anteriormente ya no pueden satisfacer los requisitos actuales de Zoom. Es por eso que una canalización de entrega continua confiable es tan importante.

A continuación se detallan las razones por las cuales Zoom no continuó eligiendo estas herramientas de código abierto anteriores.

| Helm/Kustomize  | Terraform/Pulumi  | KubeVela + Crossplane  |
| ------------ | ------------ | ------------ |
| Incapaz de conectar sistemas excepto Kubernetes  | Difícil de usar Terraform en las capas de Kubernetes y middleware a menos que se desarrollen Proveedores adicionales  | Tecnología demasiado nueva con actualizaciones rápidas, no lo suficientemente segura y estable para ser adoptada en el entorno de producción  |
| Difícil de controlar centralmente la plataforma en el modo de sub-repositorio Git  | Aumenta el costo de aprender otro lenguaje de gestión de configuración: hcl  | La definición de Trait + plantillas Cuelang de Kubevela y sus capacidades de expresión de programación no son suficientes para cubrir varias plataformas de middleware no nativas de la nube fuera del sistema Kubernetes  |
| Difícil de mantener y depurar debido a la lógica compleja de la plantilla Helm Chart  | El modo de control centralizado Mono Repo no es adecuado para equipos masivos  | /  |
| Sistema de parámetros no lo suficientemente potente para gestionar parámetros dinámicos en una gran cantidad de entornos  | /  | /  |

Debido a las limitaciones de las herramientas de código abierto anteriores, Zoom finalmente investigó algunas soluciones principales para construir la canalización de entrega continua subyacente.

Después de algunas rondas de comparación y verificación, Zoom finalmente eligió APISIX Ingress Controller para respaldar su nueva canalización de entrega continua.

## Apache APISIX Ingress Controller

### ¿Qué es Apache APISIX Ingress Controller?

[Apache APISIX Ingress Controller](https://github.com/apache/apisix-ingress-controller) es un controlador de entrada nativo de la nube que utiliza Apache APISIX como el plano de datos para transportar el tráfico y extiende la funcionalidad de Kubernetes utilizando CRD (CustomResourceDefinition). Es responsable de interactuar con el servidor API de Kubernetes, solicitar control de acceso basado en roles (RBAC), monitorear cambios, implementar la conversión de objetos dentro del controlador Ingress, comparar los cambios y luego sincronizarlos con Apache APISIX. Además, puede admitir recursos personalizados, incluyendo APISIX Route, APISIX Upstream y otros ingresos nativos de Kubernetes, para controlar el tráfico externo que accede a los servicios desplegados en Kubernetes.

A continuación se muestra el [Diagrama de Tiempo de APISIX Ingress Controller](https://apisix.apache.org/docs/ingress-controller/design/#timing-diagram).

![Diagrama de Tiempo de APISIX Ingress](https://static.api7.ai/2022/10/27/635a5613af56a.jpeg)

## ¿Por qué Zoom elige APISIX Ingress Controller?

Según los antecedentes anteriores, surge la pregunta: ¿qué tipo de canalización de entrega continua quiere construir Zoom, y cómo adopta APISIX Ingress para establecer su canalización de entrega continua subyacente?

Zoom utilizaba anteriormente NGINX como puerta de enlace API. Sin embargo, con el rápido desarrollo del negocio y el aumento de los microservicios, las limitaciones de la solución actual de NGINX son cada vez más evidentes.

Diferentes equipos deben mantener NGINX por separado, y miles de líneas de archivos de configuración de NGINX hacen que el mantenimiento sea difícil. Además, NGINX no puede escalar rápidamente cuando se despliegan muchas líneas en el servidor en la nube. Sobre el modo de recarga de NGINX, puedes consultar [este blog](https://api7.ai/blog/how-nginx-reload-work). Los negocios de Zoom comenzaron a evolucionar hacia Ingress Controller.

El equipo de Puerta de Enlace API investigó algunas soluciones de código abierto. Después de simular la migración y el análisis de la configuración real del negocio en NGINX y una gran cantidad de pruebas de rendimiento y comparación del ecosistema de plugins, Zoom finalmente eligió el proyecto APISIX Ingress Controller de la Apache Software Foundation, explorando una puerta de enlace Cloud-Native más avanzada.

Considerando sus escenarios de negocio, Zoom puso más énfasis en las siguientes dos partes, que pueden ser satisfechas por APISIX Ingress.

- **Seguridad de los datos**: Zoom toma en serio la privacidad del cliente y la seguridad del servicio; por lo tanto, la autenticación y verificación mTLS se utilizan ampliamente en salas de reuniones en línea y llamadas telefónicas. Sin embargo, muchas puertas de enlace API similares solo pueden proporcionar este servicio en su versión empresarial, mientras que APISIX Ingress ofrece una gran viabilidad y conveniencia para lograr este objetivo.

- **Estabilidad del servicio**: Los servicios backend de Zoom requieren despliegues Multi-AZ (Multi-Zonas de Disponibilidad) para alta disponibilidad en diferentes regiones. Generalmente, coloca negocios en otros DC. Si ocurre un error en el DC original, el tráfico del cliente debe transformarse a otro, en el cual APISIX Ingress puede cumplir con éxito el requisito.

### Características de Apache APISIX Ingress Controller

Tomando Apache APISIX como su plano de datos para transportar el tráfico de negocio, Apache APISIX Ingress Controller hereda las siguientes ventajas de Apache APISIX.

- **Alto rendimiento y estabilidad**: Como una puerta de enlace API dinámica de alto rendimiento, Apache APISIX es resistente y estable en su rendimiento, siendo utilizado en muchos [escenarios de tráfico a gran escala de empresas](https://apisix.apache.org/blog/tags/case-studies/).

- **Comunidad activa**: Como un proyecto de puerta de enlace API de código abierto de primer nivel y más activo, Apache APISIX posee una comunidad activa y ha mantenido una excelente tasa de crecimiento desde el primer día.

- **Ecosistema rico**: Apache APISIX admite protocolos L7, incluyendo HTTP(S), HTTP2, Dubbo, el protocolo IoT MQTT, etc. Además, APISIX admite protocolos L4 como TCP/UDP. Además, Apache APISIX 3.0 admite completamente ARM64.

- **Múltiples plugins**: Hay casi 100 plugins lanzados por APISIX oficialmente que los usuarios pueden usar con un simple arrastrar. La recarga en caliente y la orquestación dinámica de plugins brindan a los usuarios una gran conveniencia.

Además, el APISIX Ingress Controller también tiene las siguientes ventajas únicas:

- **Buena compatibilidad**: APISIX Ingress Controller admite múltiples versiones de recursos de entrada y puede ser compatible con diferentes versiones de Kubernetes.

- **Actualización dinámica**: No es necesario recargar el servicio al modificar rutas, certificados y otras configuraciones, asegurando el funcionamiento fluido del negocio.

- **Escalado flexible**: Dado que el APISIX Ingress Controller adopta una estructura que separa el plano de control y el plano de datos, el clúster del plano de datos de Apache APISIX puede expandirse independientemente sin escalar el APISIX Ingress Controller.

![Arquitectura de APISIX Ingress Controller](https://static.api7.ai/2022/10/27/635a56148940c.jpeg)

- **Amigable con las operaciones y el mantenimiento**: Bajo la arquitectura actual, los usuarios pueden elegir desplegar el clúster del plano de datos APISIX en el clúster de Kubernetes o en el entorno de máquinas físicas de metal desnudo según la situación real. Además, debido a la separación arquitectónica del APISIX ingress, el APISIX en el plano de datos transporta el tráfico mientras que el APISIX ingress controller es el componente del plano de control. Por lo tanto, la falla del APISIX Ingress Controller no afectará el tráfico del negocio.

Después de completar la selección de la puerta de enlace, el equipo de Puerta de Enlace API enfrentó un nuevo desafío: ¿cómo migrar la configuración original de la puerta de enlace API de cientos de servicios a APISIX Ingress? El equipo de Infraestructura de Zoom estaba desarrollando la canalización de entrega continua, lo que puede reducir significativamente el costo de migración de la conversión de nginx.conf y otras configuraciones de Ingress a APISIX Ingress.

## El proceso y las funciones de la construcción de la canalización de entrega continua

### La canalización de entrega continua de Zoom

La canalización de entrega continua es un sistema de entrega de aplicaciones de extremo a extremo que implementa un único modelo para declarar todos los requisitos de entrega de aplicaciones y organizar y ejecutar todos los pasos de entrega continua en una línea.

![Canalización de entrega continua de Zoom](https://static.api7.ai/2022/10/27/635a56149b270.jpg)

Hay seis partes en la canalización de entrega continua:

1. **Preparar**: preparar recursos preestablecidos, incluyendo infraestructura, middleware, recursos de servicios en la nube, etc.;

2. **Configurar**: preparar los archivos de configuración y las claves requeridas por la aplicación;

3. **Desplegar**: usar K8s para el despliegue en escenarios nativos de la nube (incluyendo información sobre contenedores, imágenes de contenedores, parámetros, versiones e instancias);

4. **Acceder**: crear un Servicio de Kubernetes y configurar automáticamente las reglas de enrutamiento del Apache APISIX Ingress si el despliegue requiere acceso externo;

5. **Observar**: Realizar configuraciones relacionadas con la observabilidad, como monitoreo, alarmas, registro y análisis de seguimiento;

6. **Escalar**: Declarar las reglas de escalado dinámico de KEDA (Kubernetes Event-driven Autoscaling) a través de métricas de monitoreo.

### Cómo adoptar APISIX Ingress en la canalización

![Descripción general de la arquitectura de la canalización de Zoom](https://static.api7.ai/2022/10/27/635a5616254ed.jpg)

**Gestión de proyectos**

Los gerentes de proyectos prestan más atención a las iteraciones de I+D y cómo gestionar mejor el progreso de lanzamiento iterativo y la eficiencia del personal en la línea de tiempo correspondiente a las iteraciones. Zoom utiliza internamente un flujo de trabajo GitOps para integrar la configuración de la Puerta de Enlace API en el modelo de entrega de aplicaciones. Bajo este modelo, la definición de las reglas de enrutamiento de APISIX se integra con "Desplegar" y otros enlaces, entregando el control de cambios a GitHub. Con la creación y fusión de ramas de GitHub, la canalización logra líneas de tiempo consistentes entre la aplicación y la configuración de la puerta de enlace, y el lanzamiento y la reversión.

```yaml
# Fragmento de código de la canalización CD de Zoom en el repositorio Git
deploy:
  type: Deployment
  replicas: ~{ replicas, 2 }
  version: "latest"
  containers:
    - name: my-app
      image: "busybox"
      command: "echo 'Demo' && sleep 99d"
access:
  - protocol: https
    host: my-domain.my-org.com
    cert: my-tls-cert
    apisix:
      routes:
        http:
          - name: my-api
            authentication:
              # ......
            match:
              paths:
                - /my-api/*
```

De esta manera, se simplifica la gestión de lanzamientos en la gestión de flujos de trabajo dentro de GitHub y se resuelve el problema del desfase de tiempo entre los sistemas ascendentes y descendentes al coincidir cambios cuando se procesan múltiples iteraciones simultáneamente.

**Desarrollo de aplicaciones**

Los desarrolladores se centran principalmente en las capacidades de enrutamiento y autenticación de las API, que están fuertemente relacionadas con los servicios de negocio y deben ser completadas por los desarrolladores para lograr el efecto automático. Además, se centran en el desarrollo e implementación de funciones de negocio y el negocio de nivel superior, esperando construir una infraestructura lista para usar.

A partir de los códigos mencionados anteriormente, podemos ver que los desarrolladores solo necesitan definir `Authentication` y `Match` en esta canalización de entrega continua. No necesitan conocer la lógica subyacente:

- Primero, traducirlo a Kubernetes Deployment y Service.
- Luego, llamar a la API de la plataforma para verificar la corrección de la ruta.
- Finalmente, traducirlo a objetos ApisixRoute.

La integración de la configuración de APISIX y el flujo de trabajo de la canalización de entrega continua proporciona a los desarrolladores una forma más eficiente.

**Gestión del entorno**

Los requisitos complejos de gestión y control del entorno a menudo ocurren en escenarios toB, y se deben considerar problemas de entrega en algunos escenarios de nube privada, nube dedicada y nube híbrida.

Algunas configuraciones de APISIX ingress se implementaron para cumplir con el requisito de ocultar las diferencias ambientales. De esta manera, los administradores del sistema pueden controlar de manera integral las diferencias en algunos entornos heterogéneos. Todos los servicios desplegados en el entorno son efectivos, evitando la carga cognitiva y las operaciones de despliegue especiales causadas por las diferencias ambientales para los desarrolladores de aplicaciones y operaciones. Por ejemplo, Zoom puede usar configuraciones personalizadas para deshabilitar el seguimiento en algunos entornos, convertir objetos ApisixRoute en objetos Ingress nativos y Anotaciones de NGINX Ingress, y usar diferentes imágenes para extraer secretos.

Además, se requiere aislamiento multi-inquilino cuando múltiples líneas de negocio están utilizando el entorno APISIX. **APISIX Ingress proporciona un selector de Anotaciones** que permite que diferentes objetos ApisixRoute sean recogidos por diferentes instancias del APISIX Ingress Controller.

**Gestión de infraestructura**

El equipo de Puerta de Enlace API necesita controlar todas las instancias de APISIX, configurar políticas de seguridad de manera integral, implementar multi-zonas de disponibilidad, y así sucesivamente.

Cada plugin de la canalización proporciona elementos de configuración para los ingenieros de infraestructura. En el plugin `ingress-apisix`, hay una propiedad `defaultPlugins`.

Después de que el equipo de la puerta de enlace API configure la propiedad, la configuración tendrá efecto para todos los servicios, lo que es adecuado para una estrategia unificada de seguridad y control de riesgos.

## Conclusión

APISIX Ingress Controller juega un papel importante en la canalización de entrega continua de Zoom, liberando la presión en la gestión de proyectos, el desarrollo de aplicaciones, la gestión del entorno y la gestión de middleware e infraestructura. El caso de Zoom es digno de aprender para otras empresas, y esperamos que APISIX Ingress Controller contribuya a la innovación de más empresas.

Además, Apache APISIX Ingress lanzó oficialmente V1.5 en agosto de 2022, que unifica la propuesta de todas las versiones de API de recursos y actualiza todas las versiones de API de CRD a V2. Al mismo tiempo, admite la mayoría de los recursos de la API de Gateway. Apache APISIX Ingress ha permitido que los recursos de Ingress utilicen plugins arbitrarios de APISIX al agregar una nueva Anotación “k8s.apisix.apache.org/plugin-config-name” a los recursos de Ingress. De esta manera, aumentará significativamente la facilidad de uso del APISIX Ingress Controller y reducirá el costo para que los usuarios migren de otros Controladores de Ingress a APISIX Ingress Controller.

Para más información, consulta [Apache APISIX Ingress V1.5](https://apisix.apache.org/blog/2022/08/05/apisix-ingress-1.5rc1-release/).


Zoom integra el APISIX Ingress Controller en su canalización de entrega continua para lograr la gestión integral de proyectos, aplicaciones, entornos y la administración de infraestructura.

¿Cómo utiliza Zoom APISIX Ingress en su pipeline de entrega continua?

## Visión general

Desde mayo de 2021, [vivo](https://www.vivo.com/en) ha introducido [Apache APISIX](https://apisix.apache.org/) 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](https://apisix.apache.org/blog/2022/11/02/apache-apisix-v3-preview/) 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

![Arquitectura de la puerta de enlace de API de vivo con APISIX](https://static.api7.ai/2022/11/23/637dc2f51318e.jpg)

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](https://github.com/apache/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.

![Modo de gestión y publicación de vivo](https://static.api7.ai/2022/11/25/638036da44e7f.jpeg)

[etcd](https://etcd.io/docs/v3.5/learning/why/#comparison-chart "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

![Gestión de separación de clústeres](https://static.api7.ai/2022/11/25/6380381595b00.jpeg)

La versión de código abierto de APISIX proporciona [etcd](https://apisix.apache.org/docs/apisix/FAQ/#why-does-apache-apisix-use-etcd-for-the-configuration-center) 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**.

![Datos que muestran la mejora de vivo en la capacidad de soportar tráfico](https://static.api7.ai/2022/11/23/637dc306a5fa1.jpg)

## 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](https://apisix.apache.org/blog/2022/09/13/why-is-apache-apisix-the-best-api-gateway/) como una puerta de enlace de tráfico a una puerta de enlace de API, utilizando sus ventajas de [limitación de tasa](https://apisix.apache.org/docs/apisix/plugins/limit-count/#attributes), [autenticación](https://apisix.apache.org/docs/ingress-controller/tutorials/mtls/), 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](https://api7.ai/contact).


¿Cómo adopta el famoso fabricante de móviles vivo APISIX como su API gateway y lo ajusta para adaptarse a sus negocios?

¿Cómo se integra vivo con APISIX?

## Visión general

### Desafíos

- Un desafío significativo en la gobernanza de datos a medida que el negocio de Airwallex se expande por todo el mundo
- La gestión complicada de varios sistemas y su interconexión causan problemas en otros sistemas cuando ocurre un problema

### Resultados

- Rendimiento estable durante **15 meses** en un entorno de producción
- **99%** de los retrasos en las respuestas están dentro de **23 ms** cuando se habilitan el enrutamiento dinámico, la limitación de tasa multiinquilino, la lista blanca de IP multiinquilino, la autenticación y la autorización
- Soporte seguro y eficiente de la soberanía de datos que cubre más de **50 monedas** en más de **130 países y regiones**

## Sobre Airwallex

Como una empresa global de fintech, [Airwallex](https://www.airwallex.com/us) ha construido una plataforma financiera global, con su red de pagos cubriendo más de 50 monedas en más de 130 países y regiones en todo el mundo, y ofrece productos de fintech digitales para empresas.

![Negocio de Airwallex](https://static.api7.ai/apisix-webp/202108/1646626634389-7d9a0a82-a76c-4645-93b6-8a431bb1f9a1.webp)

> Este artículo proviene de la entrevista con Yang Li, Ph.D., Committer de Apache APISIX y Líder Técnico de Plataforma de Airwallex, quien es responsable de la evolución de la plataforma tecnológica de Airwallex.

## La Soberanía de los Datos Representa un Desafío para Airwallex

[La soberanía de los datos](https://api7.ai/blog/leveraging-api-gateway-for-data-sovereignty-and-data-compliance) se está volviendo cada vez más importante en la gobernanza de datos en el ciberespacio. Airwallex sirve a usuarios en varias regiones, lo que naturalmente involucra el problema de la soberanía de los datos.

Antes, sin el requisito de la soberanía de los datos, los datos podían colocarse en Europa y sincronizarse en Asia o cualquier centro de datos en el mundo. El diagrama de interacción de datos era así:

![Interacción multi-clúster](https://static.api7.ai/202108/1635907812257-962b1247-f5ca-448f-904d-fd47c3ea4586.png)

Sin embargo, en una era donde se valora la soberanía de los datos, los datos están bajo control, y la arquitectura anterior no puede adoptarse. En Europa, solo se pueden procesar datos europeos, y de manera similar, solo se pueden procesar datos asiáticos en Asia. Los cambios en la interacción de datos son los siguientes.

![Interacción en un entorno de soberanía de datos](https://static.api7.ai/uploads/2023/02/01/63Z7AhJx_2.webp)

Como resultado, la soberanía de los datos representa un desafío significativo para el negocio global de Airwallex. Airwallex pretende migrar datos de Europa a otras regiones, y debe asegurarse de que los requisitos de los países terceros para la soberanía de los datos estén alineados con los de la UE.

## ¿Por qué Airwallex elige APISIX?

Al seleccionar la puerta de enlace API, Airwallex comparó principalmente los productos principales de puerta de enlace desde seis dimensiones:

- **Estabilidad**: Airwallex pone gran énfasis en garantizar la estabilidad de la puerta de enlace API. Entre los 1000 sitios web principales del mundo, **el 62.1% están basados en NGINX**, lo que muestra que los servidores web basados en NGINX han pasado la prueba de escenarios complejos y diversos en el entorno de producción. Apache APISIX está basado en NGINX. Además, el diseño de la característica **[completamente dinámica](https://api7.ai/blog/how-nginx-reload-work)** de Apache APISIX también hace posible modificar la ruta sin recargar y mantener la conexión larga del cliente. Además, **Airwallex también realizó pruebas de estrés en Apache APISIX, que aún puede funcionar de manera estable cuando el uso de la CPU alcanza más del 70%.**

- **Rendimiento**: Cada solicitud API pasará por la puerta de enlace API. Reducir la [pérdida de rendimiento](https://api7.ai/blog/apisix-kong-3-0-performance-comparison) de la puerta de enlace puede reducir significativamente el tiempo de respuesta general de las API de Airwallex.
  
    > "En la PoC, comparamos los principales productos de puerta de enlace: **el retraso en la respuesta de Apache APISIX es más del 50% menor que el de otras puertas de enlace**. Además, el plano de datos independiente de Apache APISIX permite instancias independientes en los clústeres, lo que lo hace inherentemente compatible con la expansión horizontal." dijo Li.

- **Escalabilidad**: Airwallex necesita que APISIX funcione como una puerta de enlace API que admita **[autenticación](https://api7.ai/blog/api-gateway-authentication)**, control de permisos, **[descubrimiento de servicios](https://api7.ai/blog/what-is-service-discovery-in-microservices)**, **[limitación de tasa](https://api7.ai/blog/rate-limiting-in-api-management)**, degradación, balanceo de carga, lista blanca y enrutamiento dinámico complejos.

- **Comunidad Activa**: Una comunidad activa es clave para que la puerta de enlace API mantenga el ritmo de la evolución tecnológica.

    > **La [comunidad](https://api7.ai/category/community) de Apache APISIX ha estado activa desde que aún era un proyecto de incubación de Apache, juzgando por el número de contribuyentes, el tiempo de respuesta de los problemas y el número de Pull Requests.** compartió Li.

- **Despliegue Privado**: La puerta de enlace API es un componente central de la arquitectura técnica de Airwallex, y despliega la puerta de enlace API en el borde de su propia red privada. **Apache APISIX tiene una buena adaptabilidad ambiental y puede desplegarse fácilmente en varios entornos, incluidas las plataformas de computación en la nube.**

- **Licencia de Código Abierto Amigable para los Negocios**: La Licencia Apache 2.0 permite a Airwallex modificar el código de APISIX y comercializarlo sin preocuparse por el bloqueo del proveedor.

## Solución de Enrutamiento Inteligente de Apache APISIX

**Airwallex elige Apache APISIX para hacer una solución de enrutamiento inteligente**, y es la puerta de enlace Apache APISIX la que decide dónde deben procesarse los datos.

![Puerta de enlace de dos capas de Airwallex](https://static.api7.ai/uploads/2023/02/01/cGg9YfNp_3.webp)

La puerta de enlace está compuesta por dos capas. La primera capa es responsable de enrutar las solicitudes, determinando a qué centro de datos debe llegar la solicitud según las condiciones. La segunda capa se encarga del reenvío del tráfico.

Además, **Airwallex implementó las funciones principales como [plugins](https://api7.ai/blog/how-to-implement-plugin-orchestration-in-api-gateway) personalizados** para actualizar a una nueva versión de Apache APISIX en cualquier momento. De esta manera, no habrá condiciones de carrera entre la biblioteca de código de Airwallex y el código central del repositorio principal de Apache APISIX. Sin embargo, modificar el código central es necesario a veces. En este momento, Li haría todo lo posible para implementar estas funciones en la comunidad de código abierto. **Los contribuyentes en la comunidad son muy entusiastas al discutir la implementación de funciones, y en la mayoría de los casos, pueden proporcionar rápidamente soluciones disponibles.**

## ¿Cómo se beneficia Airwallex al usar APISIX?

A continuación se muestra un diagrama que muestra la integración de Airwallex con APISIX.

![Diagrama de Integración de Airwallex y APISIX](https://static.api7.ai/uploads/2023/01/31/Q0LbIb0E_88.webp)

Airwallex toma Apache APISIX como el componente central del modelo de puerta de enlace de microservicios. Se despliega en el borde de la red y proporciona una función de puerta de enlace general para todo el tráfico que ingresa a Airwallex. Los problemas que resuelve incluyen:

- **Soberanía de los Datos**: Para la infraestructura financiera que opera a través de fronteras, la soberanía de los datos es un requisito regulatorio crítico. Para ello, **Airwallex desarrolló un plugin de enrutamiento dinámico compatible con las regulaciones aprovechando las capacidades de selección dinámica de upstream de Apache APISIX**. El enrutamiento dinámico puede seleccionar inteligentemente los upstreams para la distribución de solicitudes según las características de las solicitudes de los usuarios, abstraiendo los problemas complejos de colaboración multi-centro de datos de la capa de servicio a la capa de puerta de enlace. La esencia del enrutamiento dinámico es responder dos preguntas: cómo agrupar los upstreams y cómo coincidir las solicitudes y los grupos.

- **Aislamiento en Microservicios**: Airwallex espera que los equipos de ingeniería de cada microservicio puedan controlar de manera independiente sus propios servicios, reducir efectivamente el costo de comunicación y coordinación, y mejorar la eficiencia de la ingeniería. Este concepto arquitectónico requiere que los componentes de infraestructura compartidos por varios equipos, como la puerta de enlace API, puedan soportar el aislamiento de inquilinos. **APISIX es perfecto para satisfacer el aislamiento de inquilinos.** Mientras garantiza la robustez y el control de costos de todo el sistema, APISIX permite que los equipos de negocio configuren y amplíen las funciones de la puerta de enlace según sus propias necesidades, manteniendo la independencia de los equipos y servicios de microservicios.

- **Limitación de Tasa Multiinquilino**: En un entorno multiinquilino, las características de tráfico de cada inquilino son diferentes. Aplicar la misma limitación de tasa a diferentes inquilinos no puede satisfacer las necesidades comerciales. **La [limitación de tasa](https://api7.ai/blog/rate-limiting-in-api-management) multiinquilino puede ser más apropiada según las características del usuario.**

- **Lista Blanca de IP Multiinquilino**: La IP de acceso de cada inquilino varía en un entorno multiinquilino. **La lista blanca de IP multiinquilino permite que cada inquilino controle su propia lista blanca sin preocuparse por la invasión de otros usuarios en sus propios recursos.**

- **Autenticación**: La actualización frecuente de claves es un enlace crítico para garantizar la seguridad de los recursos del usuario. **APISIX no solo admite la [autenticación](https://api7.ai/blog/understanding-microservices-authentication-services) de solicitudes, sino también la actualización dinámica de claves.**

- **Autorización**: La gestión de permisos de las aplicaciones empresariales es muy complicada, y diferentes escenarios de aplicación tienen modelos de gestión de permisos completamente diferentes. **APISIX puede verificar si el usuario que solicita tiene permisos suficientes para acceder a la interfaz según la configuración de enrutamiento e interceptar el tráfico ilegal la primera vez.**

El entorno de producción de Airwallex ha estado funcionando durante **15 meses**, y el rendimiento general es extremadamente estable. Aproximadamente **el 99% de los retrasos en las respuestas están dentro de 23 ms** cuando se habilitan el enrutamiento dinámico, la limitación de tasa multiinquilino, la lista blanca de IP multiinquilino, la autenticación, la autorización y otras funciones.

**Gracias al excelente mecanismo de plugins de Apache APISIX, Airwallex puede agregar plugins privados que satisfacen las necesidades del negocio sin modificar su código central.** El sistema de pruebas completo garantiza aún más la calidad del software, y puedes aumentar de manera segura los requisitos personalizados del plugin mientras aseguras que la lógica central original no se dañe.

## Planes Futuros

El plan de seguimiento de Airwallex incluye principalmente tres aspectos:

1. Usar una red de múltiples capas para dividir la lógica de la puerta de enlace en diferentes capas, como distribuir el tráfico según la soberanía de los datos u otra lógica de puerta de enlace.

2. La gestión de enrutamiento fácil de leer y usar es crítica para el éxito de la puerta de enlace API. La gestión de enrutamiento debe ser amigable para los desarrolladores, de modo que puedan entender fácilmente lo que la puerta de enlace puede hacer por ellos y cómo configurarla y publicarla.

3. Usar solicitudes de código de color para ayudar a implementar pruebas en el entorno de producción. Usar solicitudes de código de color de la puerta de enlace API para implementar pruebas en el entorno de producción puede brindar más flexibilidad y facilidad de uso.

## ¿Buscas Soporte para APISIX?

[Apache APISIX](https://api7.ai/apisix) es una puerta de enlace API de código abierto, dinámica, escalable y de alto rendimiento para todas tus 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.

¿Quieres acelerar tu desarrollo con confianza como Airwallex? Para maximizar el soporte de APISIX, necesitas [API7](https://api7.ai/). ¡Ofrecemos soporte en profundidad para APISIX y soluciones de gestión de API basadas en tus necesidades!

Contáctanos ahora: [https://api7.ai/contact](https://api7.ai/contact).

Más sobre el entrevistado:

![Yang Li, Airwallex](https://static.api7.ai/uploads/2023/01/31/uGbiZnt5_Airwallex2.webp)


Airwallex resolves technical challenges that data sovereignty brings and makes intelligent routing solutions with the help of Apache APISIX.

What is Apache APISIX?

Why Apache APISIX?

APISIX vs alternatives

To Maximize APISIX, You Need API7

Case Studies

¿Cómo utiliza Zoom APISIX Ingress en su pipeline de entrega continua?

¿Cómo se integra vivo con APISIX?

¿Cómo Airwallex potencia los pagos globales utilizando Apache APISIX?

Looking for Apache APISIX Support?