Open-Source Project

Community-Driven

High Availability, Stability

Ultimate Performance,

Developer Friendly

Go for Apache APISIX

Looking for the best API Gateway?

Companies choose Apache APISIX as their API gateway after comparing it with Kong. Not only is Apache APISIX is faster, but the experience is also excellent.

Apache APISIX vs Kong:

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

### Desafíos

1. El gran tráfico resulta en toneladas de alertas diarias de CPU IDLE demasiado bajo.
2. Demasiados componentes dependen de la arquitectura del sistema.
3. Alto costo de O&M (Operación y Mantenimiento).

### Objetivos

1. Elegir una puerta de enlace API de alto rendimiento que cumpla con los requisitos de iQIYI.
2. Minimizar el costo de migración.
3. Encontrar una puerta de enlace API con una comunidad activa y un ecosistema saludable.
4. Construir una nueva puerta de enlace API para adaptarse a la tendencia de la nube nativa.

### Resultados

1. El rendimiento mejoró **10 veces** en comparación con antes, manejando **millones de QPS diarios**.
2. Se soportaron fácilmente **más de 9,000 proyectos de negocios en línea con API**.
3. Se logró con éxito la recuperación de desastres de datos en **múltiples sitios y niveles en toda China**.

## ¿Qué sucedió detrás de iQIYI?

Cong He, ingeniero senior de I+D de [iQIYI](https://en.wikipedia.org/wiki/IQIYI), compartió una charla en el Apache APISIX Meetup en Shanghái recientemente. Trabaja en el equipo de computación en la nube del departamento de infraestructura IIG y está a cargo del desarrollo de la puerta de enlace y el trabajo de operaciones en iQIYI. Adentrémonos en su charla y en la historia de la puerta de enlace API de iQIYI para comprender mejor Apache APISIX.

Fundada el 22 de abril de 2010 por Baidu, la empresa detrás del motor de búsqueda en línea más grande de China, [**iQIYI**](https://www.iq.com/?lang=en_us) es actualmente uno de los sitios de video en línea más grandes del mundo, con casi 6 mil millones de horas dedicadas a su servicio cada mes y más de 500 millones de usuarios activos mensuales.

iQIYI solía desarrollar su propia puerta de enlace API llamada Skywalker, un desarrollo personalizado basado en Kong. Skywalker necesita manejar un tráfico masivo hoy en día, y **su pico diario del servicio de puerta de enlace podría alcanzar un millón de QPS y miles de rutas de API**. Sin embargo, las desventajas de este producto han comenzado a aparecer gradualmente.

1. El rendimiento de la puerta de enlace ya no satisface los requisitos de iQIYI, y recibe toneladas de alertas diarias de CPU IDLE demasiado bajo debido al tráfico masivo.
2. Hay demasiadas dependencias de componentes en la arquitectura del sistema.
3. El costo de O&M (Operación y Mantenimiento) es demasiado alto.

Después de hacerse cargo de este proyecto este año, Cong comenzó a investigar productos de puerta de enlace similares para resolver los problemas y dificultades mencionados anteriormente y finalmente encontró Apache APISIX.

## ¿Cómo supera Apache APISIX a Kong?

Antes de elegir Apache APISIX, iQIYI ya había comenzado a usar Kong, pero luego lo abandonó.

### ¿Por qué abandonar Kong?

Después de la práctica real con Kong, Cong demuestra por qué su equipo abandonó Kong. A continuación se presentan varias de las desventajas principales de Kong.

1. Las rutas de Kong utilizan consultas de recorrido, que no son rápidas.
2. La base de datos Postgres de Kong resulta en una implementación inflada, sincronización de baja eficiencia y baja disponibilidad.
3. El código tiene un alto acoplamiento.

### ¿Por qué elegir APISIX?

> "Comparamos el rendimiento entre Apache APISIX y Kong durante la investigación, y sorprendentemente descubrimos que **Apache APISIX era 10 veces mejor que Kong en términos de optimización de rendimiento**. También comparamos Apache APISIX con algunos otros productos principales de puerta de enlace, y **la latencia de respuesta de Apache APISIX siempre es más del 50% menor que la de otros productos**. Además, Apache APISIX puede seguir funcionando de manera estable incluso si el uso de la CPU alcanza más del 70%. ¡APISIX es realmente increíble!" dijo Cong.

Tanto Apache APISIX como Kong se desarrollaron técnicamente basados en OpenResty, lo que trae un costo de migración relativamente bajo. Además, Apache APISIX tiene una excelente adaptabilidad que permite su fácil implementación en muchos entornos diferentes, incluidas plataformas de computación en la nube.

> "Mientras tanto, también descubrimos que Apache APISIX es un proyecto de código abierto altamente activo que resuelve problemas muy rápidamente. Su marco de nube nativa también se alinea con los planes de seguimiento de nuestra empresa. Por lo tanto, elegimos Apache APISIX como nuestra puerta de enlace API".

## Innovación en la arquitectura de la puerta de enlace API de iQIYI después de usar APISIX

Después de elegir la gran puerta de enlace API, iQIYI comenzó a establecer su nueva arquitectura de puerta de enlace API, que se muestra a continuación, incluyendo el nombre de dominio, la puerta de enlace, las instancias de servicio y la alarma de monitoreo.

![Diagrama de la arquitectura de la puerta de enlace API de iQIYI](https://static.api7.ai/2022/12/02/6389647220deb.jpeg)

DPVS es un proyecto de código abierto desarrollado basado en LVS por iQIYI. La alarma de monitoreo Hubble también es un desarrollo personalizado basado en un proyecto de código abierto, y se realizaron algunas optimizaciones en el rendimiento y la alta usabilidad de Consul.

### Logro 1: Mejoró los planos de datos y control para la gestión de clústeres y servicios

El plano de datos está principalmente orientado a los usuarios frontales, y toda la arquitectura desde LB hasta la puerta de enlace tiene implementaciones multi-sitio y multi-enlace para la recuperación de desastres, de modo que **los usuarios puedan acceder al centro de datos más cercano**.

Para el plano de control, existe una plataforma de microservicios para **gestionar múltiples clústeres y servicios**. La plataforma de microservicios permite a los usuarios experimentar un servicio integral sin necesidad de enviar tickets, **ahorrando una cantidad significativa de tiempo**. En el backend, el controlador de la puerta de enlace controla principalmente la configuración de todas las API, como la creación de API y los complementos, mientras que el controlador de servicios **maneja el registro, la cancelación y la verificación de salud**.

![microservice-gateway.webp](https://static.api7.ai/2022/11/21/637b4c61c02c0.webp)

### Logro 2: Añadió más características: control de seguridad, limitación de tasa y monitoreo

iQIYI implementó algunas funcionalidades básicas en la arquitectura de API como limitación de tasa, autenticación, alarma, monitoreo, etc., después de ajustarse a [Apache APISIX](https://github.com/apache/apisix).

La primera parte es sobre HTTPS. Para el control de seguridad, iQIYI no almacena ningún certificado o clave en los servidores de la puerta de enlace, sino en un servidor remoto dedicado. Sin embargo, era difícil de realizar mientras se usaba Kong; en su lugar, iQIYI usó el prefijo NGINX para hacer la descarga de HTTPS. Después de migrar a Apache APISIX, iQIYI implementó con éxito esta característica en Apache APISIX, lo que **ahorra un nivel más de transferencia en el enlace**.

En términos de [limitación de tasa](https://apisix.apache.org/docs/apisix/plugins/limit-count/), además de las funcionalidades básicas de limitación de tasa, **también se implementó la limitación de tasa precisa y la limitación de tasa por granularidad de usuario**. Para la autenticación, **se proporcionaron servicios especializados para la autenticación de pasaporte**. Además, iQIYI puede acceder a la nube de seguridad WAF de la empresa para filtrar la industria subterránea.

**La funcionalidad de alarma de monitoreo se logra utilizando el complemento incorporado de Apache APISIX - [Prometheus](https://apisix.apache.org/docs/apisix/next/plugins/prometheus/)**, y los datos de indicadores se enviarán directamente al sistema de monitoreo de la empresa. Apache APISIX también soporta a iQIYI con **servicios de registro y análisis de trazas**.

### Logro 3: Estableció un proceso dinámico de actualización de descubrimiento de servicios

Con respecto al descubrimiento de servicios mencionado anteriormente, principalmente registra servicios en clústeres de Consul a través del centro de servicios y luego utiliza el descubrimiento de servicios DNS para actualizarlos dinámicamente. QAE en el gráfico es una plataforma de microservicios utilizada internamente en nuestra empresa. **Usemos un ejemplo para demostrar brevemente el proceso de actualización de instancias.**

Al actualizar las instancias, primero cerraremos los nodos correspondientes de Consul y enviaremos solicitudes de actualización de caché DNS a la puerta de enlace a través del controlador de la puerta de enlace API. Cuando la caché se haya actualizado con éxito, el controlador enviará solicitudes de vuelta a la plataforma QAE para detener todos los nodos de aplicación backend asociados para evitar reenviar tráfico a cualquier nodo fuera de línea.

![Proceso dinámico de actualización de descubrimiento de servicios de iQIYI](https://static.api7.ai/2022/12/02/63897fa31ff83.jpeg)

### Logro 4: Mejoró la capacidad de rutas direccionales

La puerta de enlace tiene implementaciones multi-sitio, y se construyó un conjunto completo de enlaces de respaldo multi-sitio con anticipación. Además de eso, Cong también sugiere que los usuarios tengan implementaciones de acceso más cercano multi-sitio para su servicio backend. Por lo tanto, los usuarios podrían crear un servicio API en la plataforma de puerta de enlace Skywalker, y el controlador implementaría rutas API en todos los clústeres de puerta de enlace DC. Mientras tanto, el CNAME predeterminado del dominio del servicio se enrutará a un nombre de dominio de puerta de enlace unificado.

**Apache APISIX podría proporcionar directamente servicio con implementaciones multi-sitio de acceso más cercano y capacidad de conmutación por error para la recuperación de desastres y soporta la resolución de rutas personalizadas definidas por los usuarios.** Además, los usuarios podrían personalizar la configuración de la resolución de rutas a través del nombre de dominio UUID si necesitan conmutación por error, implementación azul-verde y lanzamiento canario. Adicionalmente, **Apache APISIX también soporta la programación personalizada de la recuperación del servicio backend**.

![Diagrama de rutas direccionales de iQIYI](https://static.api7.ai/2022/12/02/63898546bd508.jpeg)

### Logro 5: Mejoró la tolerancia a desastres multi-sitio y multi-nivel

Para manejar situaciones como grandes volúmenes de tráfico, toneladas de clústeres y una amplia audiencia de clientes, iQIYI requiere acceso al servicio más cercano y recuperación de desastres a nivel operativo.

**Además de las copias de seguridad multi-sitio y multi-enlace para la recuperación de desastres, iQIYI aún necesita considerar los problemas sobre situaciones multi-nivel y multi-nodo. APISIX ayuda con esto.** Cuanto más cerca estén los clientes de los nodos caídos, mayores serán los impactos en el negocio y el tráfico.

1. Si el nodo de servicio backend más lejano cae, iQIYI podría lograr el corte de un solo nodo o la conmutación por error del DC caído a través del centro de servicios y el mecanismo de verificación de salud de la puerta de enlace. Por lo tanto, el impacto se limitaría a servicios específicos, sin afectar a los usuarios.
2. Si la puerta de enlace cae, entonces iQIYI podría usar el mecanismo de verificación de salud de L4 DPVS para cortar los nodos de puerta de enlace fallidos, y el impacto es relativamente pequeño, sin afectar a los usuarios.
3. Si las medidas de corte de circuito anteriores no pueden reparar el nodo caído, entonces iQIYI podría lograr la conmutación por error automática en DNS a través de la prueba de usabilidad multi-nodo de granularidad de nombre de dominio en la extranet. Sin embargo, este método es relativamente lento y podría afectar a muchos otros servicios, y los usuarios podrían ser conscientes de esto.

## Plan futuro de iQIYI

En la integración con APISIX, iQIYI está tratando de optimizar algunos problemas para adaptarse mejor a su negocio.

1. Considerando los posibles cuellos de botella de algunos componentes dependientes, como etcd, el monitor Prometheus y el servicio de registro, **iQIYI planea usar un método de implementación híbrido. Es decir: compartir información dentro de grandes clústeres y mantener pequeños clústeres independientes.** Por ejemplo, los servicios vitales se implementarán con los pequeños clústeres.

2. Se llevarán a cabo más **reducciones y optimizaciones correspondientes para las métricas de monitoreo de Prometheus**, especialmente para el descubrimiento de servicios DNS.

> Cong dijo: "Esperamos que Apache APISIX pueda soportar más características y mantener una excelente eficiencia de rendimiento y estabilidad en futuros desarrollos y actualizaciones".

## ¿Buscas soporte de APISIX?

¿Quieres acelerar tu desarrollo con confianza como iQIYI? Para maximizar el soporte de APISIX, necesitas API7. ¡Proporcionamos soporte en profundidad para APISIX y soluciones de gestión de API basadas en tus necesidades!

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


El equipo técnico de iQIYI compara APISIX con Kong, y actualiza e integra la infraestructura de iQIYI para construir con éxito una nueva puerta de enlace API (API gateway).

iQIYI desbloquea la innovación en API Gateway con Apache APISIX

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

Apache APISIX vs Kong:
93x Faster & 200% QPS

APISIX vs Kong Performance Report

Looking for the best API Gateway?

Go for Apache APISIX

Community-Driven

Open-Source Project

Ultimate Performance,

High Availability, Stability

Developer Friendly

Apache APISIX vs Kong

Case Studies

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

iQIYI desbloquea la innovación en API Gateway con Apache APISIX

API Gateway para Web3: Cómo APISIX potencia Hyperchain

¿Listo para gestionar tus APIs?

Apache APISIX vs Kong:.css-j8kk69{background-image:var(--chakra-colors-gradient-600);color:transparent;-webkit-background-clip:text;background-clip:text;}93x Faster & 200% QPS

APISIX vs Kong Performance Report

Looking for the best API Gateway?

Go for Apache APISIX

Community-Driven

Open-Source Project

Ultimate Performance,

High Availability, Stability

Developer Friendly

Apache APISIX vs Kong

Case Studies

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

iQIYI desbloquea la innovación en API Gateway con Apache APISIX

API Gateway para Web3: Cómo APISIX potencia Hyperchain

¿Listo para gestionar tus APIs?

Apache APISIX vs Kong:
93x Faster & 200% QPS