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

September 7, 2021

Case Study

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

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

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.

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

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

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.

Tags: