Cómo implementar la orquestación de plugins en API Gateway

Ver video

Primero, permítanme presentarme. Soy Ming Wen, cofundador de API7.ai. Soy el VP y miembro del PMC del proyecto de código abierto Apache APISIX. También soy committer de Apache SkyWalking. Además, soy el fundador del Comité de Código Abierto de Qihoo 360, Tencent Cloud TVP y miembro del TOC de la Fundación TARS. Tengo más de 40 patentes de seguridad.

En el tema de hoy, presentaré 4 partes. Primero, una breve introducción a Apache APISIX. ¿Qué es Apache APISIX y cómo puede ayudarnos? La segunda parte es el desarrollo personalizado en la puerta de enlace de API, y la tercera parte es el plugin en Apache APISIX. ¿Cómo podemos generarlo automáticamente? La última parte son algunas reflexiones sobre el futuro de las puertas de enlace de API.

En primer lugar, permítanme presentar brevemente Apache APISIX. En una frase, es una puerta de enlace de API nativa de la nube. Aquí está la dirección del repositorio de Apache APISIX en GitHub.

Apache APISIX es un proyecto muy joven. Se abrió al público en junio del año pasado y se donó al incubador de Apache en octubre. En julio de este año, se graduó del incubador de Apache y se convirtió en un proyecto de primer nivel. Esta es una comunidad de rápido crecimiento, solo tomó nueve meses.

Para los desarrolladores que no están familiarizados con Apache APISIX, pueden simplemente considerarlo como una versión mejorada de NGINX, que cubre todas las funciones de NGINX mientras utiliza Lua. Esto aporta más características dinámicas a NGINX, convirtiéndolo en una puerta de enlace de API muy poderosa. La mayor característica de Apache APISIX es que es completamente dinámico, incluyendo enrutamiento, certificados SSL, plugins, etc. En Apache APISIX, todas las características se configuran dinámicamente a través de la API de administración, sin necesidad de reiniciar el servicio. En Apache APISIX, las necesidades comerciales de los usuarios se realizan utilizando Lua para desarrollar plugins. APISIX tiene más de 40 plugins integrados, incluyendo autenticación, limitación de tasa, limitación de solicitudes, seguridad, registro, observabilidad, etc., que básicamente cubren todas las características que los usuarios pueden encontrar en la empresa.

Entonces, ¿qué puede hacer Apache APISIX por usted? Puede manejar tráfico de capa 4 y capa 7, incluyendo HTTP, HTTPS, TCP, UDP, MQTT, etc.

Dado que Apache APISIX está basado en NGINX, naturalmente puede usar Apache APISIX en lugar de NGINX para manejar el tráfico norte-sur. Al mismo tiempo, Apache APISIX también puede manejar bien el tráfico entre microservicios, por lo que puede usarlo para reemplazar Envoy. También tenemos algunos usuarios que usan Apache APISIX como el controlador de entrada de Kubernetes. Al mismo tiempo, con la ayuda del plugin MQTT de Apache APISIX, podemos usarlo como una puerta de enlace IoT, o usar el plugin IDP para convertir APISIX en una puerta de enlace de confianza cero. Por lo tanto, APISIX se enfoca más en el poder de la puerta de enlace en sí. A través de los plugins, los usuarios pueden convertir APISIX en las diversas puertas de enlace que su negocio requiere.

Esta es la arquitectura técnica de Apache APISIX. Desde aquí podemos ver que APISIX tiene dos partes, la izquierda es el plano de datos y la derecha es el plano de control.

Primero veamos el plano de datos. Después de que la solicitud del usuario es procesada por Apache APISIX, puede pasarse a API privadas, API públicas o API de socios. Dentro de Apache APISIX, los plugins están construidos de manera similar a bloques de Lego. Puede eliminar o agregar un plugin fácilmente sin reiniciar el servicio.

Luego veamos el plano de control. En el plano de control, el administrador escribe las configuraciones en el clúster de etcd a través de la API de administración, y el plano de datos de APISIX observará etcd, de modo que las configuraciones lleguen a todos los planos de datos en milisegundos. Después de que los nodos del plano de datos procesan los datos, reportan algunas métricas y datos de registro a componentes como SkyWalking, Prometheus, etc.

Desde este diagrama de arquitectura, podemos ver que APISIX solo depende de etcd, y no tiene RDS como MySQL y PostgreSQL. Por lo tanto, APISIX está mejor diseñado para alta disponibilidad. Al mismo tiempo, su arquitectura será más simple, conveniente para la implementación y operaciones.

Esta imagen es el panorama de Apache APISIX. Mirándolo desde la izquierda, APISIX admite muchos protocolos de capa 4 y capa 7. No solo admite tráfico de navegadores y aplicaciones móviles, sino que también admite que varios dispositivos IoT informen el tráfico a APISIX.

Apache APISIX también admite muchos centros de descubrimiento de servicios externos, incluyendo etcd y Consul.

Como un software de infraestructura muy importante, la puerta de enlace de API generalmente se coloca en la entrada del tráfico. Por lo tanto, no solo necesita procesar todas las solicitudes del cliente, sino que también necesita conectarse a algunos servicios backend, como SkyWalking, Datadog, Kafka, etc.

En la parte inferior de esta imagen, APISIX no solo admite ejecutarse en hardware físico, sino también en servidores en varias nubes públicas. También admitimos la ejecución en la plataforma ARM.

OK, la Parte 1 es una breve introducción a APISIX, y luego en la Parte 2, presentaré el desarrollo de plugins personalizados en la puerta de enlace de API.

El desarrollo personalizado es un punto muy importante cuando usamos puertas de enlace de código abierto, y tiene un alto nivel de exigencia. La puerta de enlace no es un software que se pueda usar directamente. Esto es diferente de las bases de datos y las colas de mensajes. MQ y las bases de datos se pueden usar directamente después de instalarlas, pero la puerta de enlace no. Esto se debe a que la puerta de enlace requiere más o menos desarrollo personalizado.

Por ejemplo, si su empresa tiene algunos sistemas antiguos, o algunos protocolos especiales, como algunos protocolos en la industria financiera y de seguridad, es necesario realizar alguna transcodificación a nivel de la puerta de enlace.

Por otro lado, aunque APISIX proporciona más de 40 plugins, definitivamente no puede satisfacer todas las necesidades de la empresa, porque cada empresa tiene algunas necesidades únicas. Por lo tanto, a menudo necesitamos hacer algún desarrollo personalizado de los plugins existentes para satisfacer nuestras necesidades. Esto es en realidad un gran problema, porque el desarrollo de plugins aún requiere más habilidades. Para el desarrollo de plugins, diferentes proyectos de código abierto tienen diferentes soluciones.

Primero veamos Kong. Es un proyecto de puerta de enlace de API muy conocido. Tiene 5 años. La pila tecnológica de Kong es básicamente la misma que la de APISIX, y ambas están implementadas basadas en NGINX y Lua. Pero la arquitectura técnica de Kong no es la misma que la de APISIX. Kong está basado en RDS como PostgreSQL y Cassandra. APISIX usa etcd, y la solución de APISIX está más cerca de Kubernetes y la nube nativa.

El punto común de Kong y APISIX es que los desarrolladores necesitan usar Lua para desarrollar plugins. Lua no es un lenguaje de programación popular, y muchos desarrolladores no están familiarizados con él, aunque Lua en sí es simple. Entonces, además de hacer que el plugin sea más simple, ¿qué mejor solución hay?

La solución de Kong es admitir Go para escribir plugins. Este enfoque atraerá a más desarrolladores de Go a escribir plugins para satisfacer las necesidades personalizadas de su propia empresa. Esta es una buena idea, pero por otro lado, Kong está implementado de forma nativa basado en Nginx y Lua, y los plugins escritos en Go en realidad necesitan llamar a otro proceso, lo que tendrá una comunicación entre procesos, lo que tiene problemas de rendimiento.

Veamos el segundo, que también es un proyecto de plano de datos de código abierto muy conocido para procesar tráfico este-oeste, Envoy, que está escrito en C++. Por lo tanto, el plugin de Envoy también está implementado naturalmente en C++. Así que no es fácil comenzar.

Envoy también admite otros lenguajes para el desarrollo. Por ejemplo, Envoy admite el filtro Lua, y el filtro Lua tiene el mismo problema que Kong, es decir, hay pocos desarrolladores familiarizados con Lua. Entonces Envoy también admite WASM, lo que puede atraer a más desarrolladores de otros lenguajes a escribir plugins. Esta solución no es perfecta, y la estabilidad y el rendimiento de WASM aún necesitan tiempo para mejorar.

Las soluciones de Kong y Envoy son las mismas: esperan que más desarrolladores tengan la capacidad de desarrollar plugins, ya sea que usen Go, Lua o WASM. Entonces, volviendo a APISIX, esperamos encontrar una bala de plata.

Entonces, ¿cómo se ve esta bala de plata? Creemos que a nivel de la puerta de enlace, primero se deben resolver los siguientes dos problemas para resolver el problema del desarrollo personalizado.

El primero es que muchos plugins que necesitan ser desarrollados son en realidad simples. ¿Cómo reutilizar los más de 40 plugins de código abierto que ya existen?

El segundo es permitir que el lado de la demanda de la puerta de enlace en la empresa, como los gerentes de producto, los equipos de operaciones y seguridad, implementen sus propias necesidades en la puerta de enlace con el menor costo posible, sería mejor si no necesitan escribir ningún código.

Si podemos resolver estos dos problemas, entonces tenemos la oportunidad de permitir que más personas, no solo desarrolladores, puedan desarrollar la puerta de enlace de API.

En primer lugar, veamos cómo resolver el primer problema, que es la reutilización de los plugins existentes. Los microservicios ya son una tecnología muy popular, entonces, ¿podemos introducir este concepto en los plugins de la puerta de enlace de API?

Podemos hacer que cada plugin solo haga una característica, como un microservicio, que también es lo mismo que el diseño de los procesos en Linux. Por lo tanto, hemos propuesto un concepto llamado micro-plugin.

Cada uno de nuestros plugins solo hace una característica independiente. Luego, necesitamos un diseño similar a la tubería de Linux para conectar estos micro plugins.

Por ejemplo, primero llamo a un plugin de bloqueo de URI. Después de que la llamada termina, juzgo si el URI está realmente bloqueado. Si está bloqueado, entonces continúo llamando al plugin de Kafka.

Usando este método de tubería, estos plugins pueden conectarse. Apache APISIX ahora tiene más de 40 plugins. La permutación de más de 40 plugins tiene posibilidades ilimitadas, suficientes para satisfacer las necesidades del usuario.

Pero el problema ahora es que en todas las puertas de enlace de API que han sido de código abierto, los plugins no comparten contexto y no pueden cooperar entre sí. Entonces necesitamos conectar esos plugins juntos. Solo haciendo esto, podemos resolver el problema de la reutilización de plugins con micro-plugins.

El segundo problema es, después de tener el micro-plugin, ¿cómo podemos reducir el costo de desarrollo del nuevo plugin de la puerta de enlace de API a cero tanto como sea posible para satisfacer las necesidades del usuario? Esperamos que para los no desarrolladores, es decir, aquellos gerentes de producto y seguridad que no tienen antecedentes técnicos y no saben programar, puedan realizar sus necesidades sin desarrollo, porque entienden mejor nuestras necesidades.

Al mismo tiempo, esto reducirá la barrera para el desarrollo de puertas de enlace de API, permitiendo que más y más personas contribuyan a la puerta de enlace de API. Si usamos un eslogan, es "de la creatividad a la creación", no solo podemos escribir nuestras propias ideas en un documento para los desarrolladores, sino también crear directamente un nuevo plugin.

Esto suena como una buena idea, entonces, ¿se puede realizar? De hecho, podemos salir del pensamiento técnico para ver cómo se resuelve en otras industrias.

Por ejemplo, en el motor de procesos de la industria médica, están construidos de manera GUI, porque sus usuarios son médicos. Luego, Lego para niños es lo mismo. Puedes usar un número limitado de bloques para construir un número infinito de formas posibles.

Juntando las ideas de GUI y Lego, entonces podemos ver que en realidad es Scratch, que es cómo los niños aprenden a programar, por lo que la barrera será muy baja.

Basándonos en los dos problemas anteriores que resolvimos, APISIX propuso de manera única un nuevo concepto: la orquestación de plugins. Aquí hay una demostración de la orquestación de plugins, podemos ver este breve video primero.

En este video, primero creamos un plugin de bloqueo de URI, y luego creamos un juicio condicional. Si el bloqueo de URI es verdadero, entonces lo agregamos al plugin de inyección de fallas; si el resultado del bloqueo de URI es falso, lo pasamos al plugin de Kafka para registrar logs.

Luego configuramos cada plugin y la condición de juicio. Finalmente, verifiquemos con curl si este nuevo plugin realmente funciona en el nodo de la puerta de enlace. Sí, funciona.

A continuación, les explicaré cómo se implementa esta orquestación de plugins. Esto también puede ser un problema técnico que les preocupe a todos.

Para implementar la orquestación de plugins, necesitamos seguir tres pasos.

En el paso 1, necesitamos usar DAG para describir este nuevo plugin. Podemos ver que el gráfico con la flecha a la izquierda es en realidad un DAG (gráfico acíclico dirigido), que es lo mismo que el código descrito en el video anterior. Entonces, este es un método de descripción amigable para los humanos. Para la computadora, tenemos que convertirlo en un lenguaje de descripción de una estructura de datos a la derecha. Por ejemplo, el nodo número 1 seguido de 2 4 6 significa el nodo 1, que apunta al segundo, el cuarto y el sexto nodos; el valor del número 3 es nil, lo que significa que no hay otros nodos detrás del nodo número 3, y los demás son similares. De esta manera, convertimos un DAG en una descripción de estructura de datos.

Después de tener esta estructura de datos, luego convertimos esta estructura de datos en una cadena JSON, y luego pasamos esta cadena JSON al servidor. La cadena JSON a la derecha se convierte del plugin que vimos en la demostración.

Después del paso 1, ya tenemos una cadena descrita por JSON, pero ¿cómo convertimos esta cadena en código que pueda ser ejecutado por APISIX?

Sabemos que en APISIX estamos ejecutando código Lua, por lo que necesitamos un compilador, para analizar JSON en un AST (árbol de sintaxis abstracta), y finalmente generar código Lua. En este momento, usamos jsonschema para hacer este paso. A continuación está el repositorio de código abierto.

Después de generar el código Lua, usamos el plano de control de APISIX para escribir el código Lua en etcd a través de la API de administración, y luego el nodo del plano de datos de APISIX obtiene el código Lua a través de la observación de etcd. APISIX tiene la capacidad de ejecutar dinámicamente el código Lua, como el plugin serverless de APISIX.

Por lo tanto, el nuevo plugin generado por la orquestación de plugins, desde DAG hasta la ejecución real del nodo de datos, todo el proceso es completamente dinámico, lo cual es una característica muy importante de APISIX.

Si has llegado hasta aquí, ¿tienes una pregunta, dónde puedo probarlo? No te preocupes, aquí hay un proyecto de código abierto, y también tenemos una demostración en línea.

En la última parte, quiero hablar sobre nuestras reflexiones sobre el futuro de la puerta de enlace de API. La puerta de enlace de API ha existido durante mucho tiempo. Ha habido muchas empresas y proyectos de código abierto haciendo puertas de enlace de API hace más de diez años. Luego, en la era de la nube nativa, la puerta de enlace de API enfrenta cambios en los requisitos del usuario, y se plantean mayores exigencias para las puertas de enlace de API.

Una tendencia es que las puertas de enlace de API tradicionales norte-sur comienzan a procesar tráfico este-oeste de microservicios. Por ejemplo, NGINX ha lanzado NGINX Control y NGINX Unit. Kong y APISIX también actúan como puertas de enlace de API de microservicios.

Al mismo tiempo, el proyecto de malla de servicios este-oeste también intenta actuar como la puerta de enlace de acceso norte-sur. Entonces, para los proyectos de código abierto, todos quieren procesar todo el tráfico.

Los proyectos de código abierto sobre el procesamiento de tráfico están floreciendo, podemos ver el BFE de Baidu y el MOSN de Alibaba. Todos se enfocan en el tráfico.

El segundo es el bajo código. La mejor solución es que el PM pueda implementar características directamente mediante la orquestación de plugins, de modo que los desarrolladores se concentren más en la puerta de enlace en sí.

De esta manera, el negocio y el núcleo de la puerta de enlace de API están desacoplados. Puedes permitir que personas que no entienden la tecnología y el desarrollo de plugins contribuyan con plugins al proyecto de código abierto. Esto es muy importante.

El tercer punto es el tiempo real. Con la popularización de 5G e IoT, y la implementación de Kubernetes en la empresa, se han planteado requisitos muy altos para el efecto en tiempo real de la configuración, el proceso de solicitudes y el análisis de datos en tiempo real. Para la puerta de enlace, si no puedes ser en tiempo real, tener un rendimiento muy alto y una latencia muy baja, entonces no podrá sobrevivir en los próximos tres a cinco años.

Por último, pero no menos importante, es el código abierto. Podemos ver que el software se está comiendo el hardware, y el software de código abierto se está comiendo el software. Al final, todo el software de infraestructura es de código abierto.

Lo mismo ocurre con la puerta de enlace de API. El código abierto permite que las empresas lo usen a un costo más bajo sin preocuparse por el bloqueo del proveedor. Además, la oportunidad comercial del código abierto también traerá más a los desarrolladores de código abierto. Este es un buen modelo para una situación de ganar-ganar.