Dynamic

Rich Features

Cluster Management

Go for Apache APISIX

Looking for the best API Gateway?

Built on NGINX, with more features than NGINX.

 Many companies have migrated from NGINX to Apache APISIX, immediately achieving fast growth and reducing operational costs.

Apache APISIX vs NGINX:

## Visión general

Como proveedor líder mundial de infraestructura de blockchain de consorcio a nivel empresarial y proveedor de soluciones, [Hyperchain Technologies](https://www.hyperchain.cn/en/about/company) está comprometido en construir infraestructura innovadora y potenciar el desarrollo digital de la sociedad. Durante su rápido crecimiento, Hyperchain enfrentó varios problemas al establecer su plataforma de blockchain Hyperchain, como los siguientes:

- Falta de gestión estandarizada del tráfico con el riesgo potencial de colapso del sistema
- Control de seguridad y gestión de autenticación incompletos
- Control de permisos inconveniente
- Alto costo en direcciones IP de red pública
- Nodos de blockchain inestables: un solo nodo vulnerable a ataques
- Falta de gestión unificada de múltiples protocolos

Hyperchain probó Kong y NGINX, pero desafortunadamente, no pudieron satisfacer los escenarios de negocio de Hyperchain. **Sin embargo, después de adoptar Apache APISIX, todos los problemas mencionados se resolvieron, dotando a la plataforma de blockchain Hyperchain de una vitalidad infinita.**

### Sobre la Plataforma de Blockchain Hyperchain

La plataforma de blockchain Hyperchain se refiere a la integración del marco de blockchain en la plataforma de computación en la nube, aprovechando las ventajas de infraestructura de servicios en la nube para la implementación y gestión. Es una plataforma de blockchain abierta que puede proporcionar a los desarrolladores un ecosistema de blockchain conveniente y de alto rendimiento, junto con servicios de soporte relacionados, y también apoyar la expansión y operación de negocios de los desarrolladores en web3.

**La plataforma de blockchain Hyperchain puede construir la red de blockchain de manera rápida y flexible. Con la plataforma, las empresas pueden gestionar el negocio de blockchain de manera uniforme.** Por ejemplo, a través de la plataforma, podemos firmar contratos en el entorno de desarrollo integrado y luego desplegar los contratos en la red de blockchain creada. El módulo de servicio superior puede llamar a los contratos relacionados con blockchain para continuar el proceso de negocio.

Dado que hay muchos nodos en la cadena, que van desde docenas hasta miles, se vuelve difícil monitorear y mantener la operación de la cadena sin el soporte de la plataforma. **Al utilizar la plataforma de blockchain Hyperchain, los usuarios no solo pueden ahorrar costos, sino también gestionar el blockchain de manera más conveniente y mejorar la seguridad de todo el sistema.**

Tomemos a Hyperchain como ejemplo para entender cómo y por qué las empresas de blockchain deberían seleccionar Apache APISIX entre muchas puertas de enlace API. A continuación, analizaremos la aplicación de APISIX tanto en la plataforma de blockchain Hyperchain como en el nodo de blockchain.

## Aplicación de APISIX en la Plataforma de Blockchain Hyperchain

A continuación se muestra un diagrama de interacción de la aplicación de APISIX en la plataforma de blockchain Hyperchain. El servicio backend registra la información del servicio en etcd según sus características de negocio y luego registra el servicio en APISIX a través del módulo de registro de rutas.

APISIX funciona como la entrada unificada de los microservicios internos en el sistema. Las solicitudes externas se envían primero a APISIX; luego, visitan la capa de acceso a través de la API después de pasar la autenticación y posteriormente acceden a los servicios centrales a través de RPC (llamada a procedimiento remoto).

![Diagrama de interacción de la aplicación Hyperchain](https://static.api7.ai/2022/11/15/637335a53d73c.png)

### Reenvío de Rutas

A veces, se espera que las API se expongan bajo el mismo nombre de dominio. En este caso, podemos agregar algunos prefijos a la ruta de la API del mismo servicio, como `/baas-core` o `/baas-other`. Cuando el cliente solicita estas API, la puerta de enlace API necesita eliminar estos prefijos agregados y luego reenviar la solicitud al servicio backend. El [plugin proxy-rewrite de APISIX](https://apisix.apache.org/docs/apisix/plugins/proxy-rewrite/) puede ayudarnos a manejar estos casos de manera conveniente.

Por ejemplo:
Cuando se visita: http://apisix:8080/baas-{service}/api/v1/…
La solicitud puede ser reenviada a http://{service}/api/v1/…
escribiendo una expresión regular: `^/baas-core/(.*)$,/$1`

![Edición del plugin proxy-rewrite](https://static.api7.ai/2022/11/15/637335b538dc0.png)

### Gestión de Límite de Tráfico

Los usuarios pueden elegir blockchains de consorcio según sus necesidades, no solo la de Hyperchain, sino también IBM Data Fabric, Baidu XuperChain, etc. Por lo tanto, Hyperchain necesita realizar la gestión del ciclo de vida de todos los blockchains de consorcio en el sistema.

Al crear una cadena de consorcio, Hyperchain solo necesita escribir el código duro en la plataforma de blockchain y cargar los componentes de controladores enchufables en la plataforma de blockchain para su llamada y creación de la cadena de consorcio. En algunos casos de implementación privada, los componentes de controladores enchufables pueden soportar rápidamente.

Cada llamada a los componentes de controladores es un proceso que necesita ser limitado, especialmente cuando el número es grande. En consecuencia, el [plugin limit-req de APISIX](https://apisix.apache.org/docs/apisix/plugins/limit-req/) puede ser beneficioso para restringir la entrada y salida de tráfico de la plataforma para asegurar su estabilidad.

El plugin limit-req permite una configuración personalizada sobre la tasa y el burst.

![Modelo del plugin limit-req](https://static.api7.ai/2022/11/15/637335b790f49.jpeg)

### Control de Seguridad y Gestión de Autoridad

Para colaborar con APISIX, Hyperchain desarrolló un plugin para circunstancias de implementación privada. A menudo, la Parte A prefiere utilizar sus servicios de autenticación o sistema de cuentas de servicio. Cuando el tráfico del frontend visita el sitio web, primero pasará por el plugin Access-auth, y solo si pasa la autenticación podrá acceder al backend BFF (Backend for Frontend).

![Diagrama del proceso de autenticación](https://static.api7.ai/2022/11/15/637335b994030.png)

Según los tres factores clave de la especificación estándar Restful (la información de autenticación, la ruta Restful y los verbos HTTP como GET, POST, PUT, DELETE, PATCH, etc.), se realiza la autenticación de cuenta-rol-autoridad. Si la autenticación es exitosa, la información del usuario se devolverá en el encabezado; si no, se devolverá un 403.

![Ruta de autenticación de API](https://static.api7.ai/2022/11/15/637335bd3e080.png)

### Recarga en Caliente

APISIX ofrece [recarga en caliente](https://apisix.apache.org/docs/java-plugin-runner/hot-reloading/) de plugins desarrollados internamente. Ahorra tiempo durante el desarrollo y permite a los usuarios cambiar partes de su código sin reiniciar todo el plugin runner. De esta manera, los desarrolladores pueden hacer ajustes en la interfaz en el backend, que surten efecto inmediatamente, lo que es conveniente y amigable para el lanzamiento en línea.

### ¿Por qué no Kong?

Hyperchain había usado Kong antes, pero finalmente lo reemplazó con Apache APISIX principalmente porque:

- **Alto Costo de Implementación y Mantenimiento**

    El clúster de Kong necesita cooperar con la base de datos Postgresql y requiere un administrador de base de datos específico para alta disponibilidad. La implementación del clúster de la base de datos Postgresql es relativamente difícil de implementar y aumenta el costo de la operación y mantenimiento posterior.

- **Aumenta la Complejidad del Sistema y la Tasa de Fallos**

    La plataforma de blockchain Hyperchain utiliza la base de datos MySQL, lo que resulta en dos bases de datos relacionales en el sistema si se adopta Kong, lo que hace que el sistema sea más complicado. También aumenta la tasa de fallos al mejorar la compatibilidad entre dos conjuntos de bases de datos.

## Aplicación de APISIX en el Nodo de Blockchain

![Diagrama de blockchain Hyperchain](https://static.api7.ai/2022/11/15/637335bfa08dc.png)

### Ahorro de Costos en Direcciones IP de Red Pública

El usuario compra blockchains a través de la plataforma de blockchain Hyperchain. Luego, los negocios de nivel superior y los clientes desarrolladores pueden conectarse a los nodos. Los servicios pueden conectarse a uno o más nodos, y los usuarios pueden acceder a uno o más nodos, lo que genera un problema: casi todos los nodos serán visitados, lo que aumenta la presión de visita en un solo nodo.

Es relativamente fácil de manejar en algunos entornos de empleo privado. Sin embargo, se requieren demasiados nodos y direcciones IP públicas para aquellos sistemas dirigidos a usuarios de internet. El precio de cada dirección IP pública de 4 megabytes de tráfico puede alcanzar casi 200 CNY por mes. Hay miles de nodos en la plataforma Hyperchains, lo que consume un alto costo en direcciones IP públicas.

APISIX gestiona todas las solicitudes de visita y distribuye el tráfico a los nodos de blockchain correspondientes. De esta manera, Hyperchain ahorró un alto costo.

![Modo de Hyperchain con APISIX](https://static.api7.ai/2022/11/15/637335c23f4f8.png)

### Control de Permisos Conveniente

Hay varios blockchains en la plataforma de blockchain Hyperchain, y cada cadena tiene un control de permisos RBAC complicado. Por lo tanto, se requieren diferentes tipos de certificados para ser agregados en el lado del cliente, como certificados TLS, lo que también confunde a los usuarios.

Actualmente, el [plugin key-auth de APISIX](https://apisix.apache.org/docs/apisix/plugins/key-auth/) puede usarse para resolver este problema de manera eficiente. Los usuarios autorizados pueden acceder directamente al blockchain sin preocuparse por la configuración de permisos, ya que APISIX unifica la cadena subyacente.

### Agrupación Mejora la Estabilidad de los Nodos

Como se mencionó anteriormente, los nodos son visitados con frecuencia. Existe una alta concurrencia en la mayoría de los usuarios bancarios, ya que el TPS (Transacciones Por Segundo) puede alcanzar 40,000-50,000 veces.

Resulta que un solo nodo en el blockchain es vulnerable porque cada transacción impactará el nodo visitado.

Hyperchain implementó Apache APISIX en K8s con el Horizontal Pod Autoscaler. Dado que APISIX utiliza etcd con una buena escalabilidad dinámica, puede resolver efectivamente el problema del impacto de tráfico de un solo punto.

### Soporte para Múltiples Protocolos

Los protocolos de las cadenas heterogéneas en la plataforma de blockchain Hyperchain son diversos, como el protocolo HTTP, el protocolo Websocket, el protocolo gRPC, el protocolo TCP, el protocolo UDP, etc.

APISIX soporta múltiples protocolos, adaptándose flexiblemente a las capas subyacentes de diferentes blockchains, reduciendo así los costos de desarrollo.

### ¿Por qué no NGINX?

Parece que Hyperchain podría utilizar NGINX para resolver sus problemas. Sin embargo, después de la prueba, Hyperchain lo descartó porque:

- **No Adecuado para Expansión Dinámica**

    Hyperchain necesita agregar y eliminar nodos en la plataforma de blockchain con frecuencia, lo que solo surte efecto después de reiniciar, lo que es inconveniente para los desarrolladores. Además, los desarrolladores deben escribir código de reglas complejas para los plugins en el archivo conf de NGINX.

- **Difícil de Agrupar**

    NGINX no soporta clúster, lo que es relativamente complejo y poco amigable para los usuarios.

- **No Soporta Directamente TCP y UDP**

    NGINX solo puede hacer proxy del protocolo de capa 7 en lugar del protocolo de capa 4 y no puede soportar directamente los protocolos TCP y UDP. Además, el módulo no está compilado por defecto, requiriendo un procesamiento adicional.

- **Sin Panel de Control**

    No hay una interfaz visualizada de NGINX, lo que dificulta a los desarrolladores y operadores gestionar tantos nodos.

## Resumen

De los contenidos mencionados anteriormente, sabemos que Apache APISIX es una puerta de enlace API dinámica que puede aplicarse en el área de blockchain. Además, Apache APISIX proporciona ricas características de gestión de tráfico como Balanceo de Carga, Upstream Dinámico, Lanzamiento Canario, Circuit Breaker, Autenticación, Observabilidad, etc.

Esperamos que APISIX pueda apoyar a más empresas de blockchain para entrar en otra fase de desarrollo.
Bienvenido a aprender más sobre Apache APISIX.
Puede contactarnos en https://api7.ai/contact.


Cómo la empresa unicornio de blockchain, Hyperchain, utiliza APISIX, una puerta de enlace API de código abierto, para potenciar la Plataforma Blockchain de Hyperchain y gestionar el tráfico de blockchain en web3, mencionando la comparación entre APISIX, Kong y NGINX.

API Gateway para Web3: Cómo APISIX potencia Hyperchain

## 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?

## 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.

Apache APISIX vs NGINX:
Dynamic Configuration,
Cluster Management

Looking for the best API Gateway?

Go for Apache APISIX

Dynamic

Rich Features

Cluster Management

Apache APISIX vs NGINX

Case Studies

API Gateway para Web3: Cómo APISIX potencia Hyperchain

¿Cómo se integra vivo con APISIX?

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

¿Listo para gestionar tus APIs?

Apache APISIX vs NGINX:.css-j8kk69{background-image:var(--chakra-colors-gradient-600);color:transparent;-webkit-background-clip:text;background-clip:text;}Dynamic Configuration,Cluster Management

Looking for the best API Gateway?

Go for Apache APISIX

Dynamic

Rich Features

Cluster Management

Apache APISIX vs NGINX

Case Studies

API Gateway para Web3: Cómo APISIX potencia Hyperchain

¿Cómo se integra vivo con APISIX?

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

¿Listo para gestionar tus APIs?

Apache APISIX vs NGINX:
Dynamic Configuration,
Cluster Management