Apache APISIX 3.0: 11 Aspectos Destacados de la Puerta de Enlace API de Código Abierto

¡La versión 3.0 de la puerta de enlace de API de código abierto Apache APISIX está por llegar! Hemos seleccionado 11 características esenciales para dar un breve resumen.

La puerta de enlace de API ha sido un componente esencial durante mucho tiempo. Se ha comprometido a proporcionar diversas funciones como limitación de tasa, autenticación (por ejemplo, Usar Keycloak para proteger APIs) y observabilidad a nivel empresarial.

Puerta de enlace de API Apache APISIX

Apache APISIX nació para ayudar a las empresas a resolver nuevos problemas en entornos nativos de la nube y microservicios. Por ejemplo, proporciona escalado automático del tráfico empresarial a través de la característica completamente dinámica y una modificación única para lograr de manera más conveniente la gestión de clústeres.

Por lo tanto, en el diseño arquitectónico de APISIX, el plano de datos y el plano de control están separados para lograr una gestión completamente dinámica y de clúster, lo cual se logra principalmente mediante componentes de etcd.

APISIX almacena y gestiona configuraciones relacionadas con enrutamiento y complementos en etcd. Como se muestra en la figura anterior, las configuraciones de la API de administración (Plano de control) se almacenan en etcd, mientras que el plano de datos a la izquierda principalmente monitorea los cambios de etcd. El plano de datos puede observar rápidamente los cambios sin necesidad de modificar archivos de configuración.

Pero resolver estos problemas no es suficiente. Como un middleware que recibe solicitudes tanto del upstream como del downstream, la puerta de enlace de API juega un papel crucial en la arquitectura empresarial como la entrada de tráfico y la conexión entre las capas de servicio. El papel de la puerta de enlace de API difiere de las bases de datos que solo reciben solicitudes del nivel empresarial del usuario.

Además de los requisitos a nivel empresarial, las puertas de enlace de API también tienen requisitos de personalización e integración. Entonces, cómo hacer que el desarrollo personalizado sea más fácil para los desarrolladores al usar APISIX es otro punto de dolor significativo que APISIX resuelve, reduciendo el umbral para que los desarrolladores codifiquen.

En APISIX, los complementos se desarrollan principalmente a través de Lua, y se utiliza LuaJIT (un compilador Just-In-Time para Lua) para garantizar que el rendimiento del código compilado sea lo suficientemente bueno.

Si no estás familiarizado con Lua, puedes usar Plugin Runner, desarrollando complementos de APISIX utilizando los lenguajes de programación que conoces. También hemos integrado Wasm en APISIX, y puedes utilizar Wasm para compilar bytecode Wasm y ejecutarlo en APISIX. Como resultado, los usuarios pueden usar Lua, Go, Python, Wasm, etc., para crear complementos personalizados en APISIX.

Gracias a la arquitectura y la ventaja de rendimiento de APISIX, el crecimiento global de usuarios de APISIX ha superado con creces las expectativas en los tres años desde su creación. Por ejemplo, grandes empresas tecnológicas como WPS, Sina Weibo e iQiyi son usuarios empresariales que manejan decenas de miles de millones de solicitudes de API diariamente. Además, instituciones de investigación científica como la NASA y la Plataforma de Fábrica Europea están utilizando APISIX.

11 Nuevos Aspectos Destacados de APISIX 3.0

APISIX propuso un nuevo Plan de Ruta 3.0 a principios de 2022. En la versión 3.0, sus iteraciones y actualizaciones se centrarán en la usabilidad y el ecosistema.

APISIX 3.0 se lanzó oficialmente a finales de octubre de 2022. ¡Echemos un vistazo a los emocionantes nuevos aspectos destacados!

1. Soporte Completo de ARM64

ARM64 se ha convertido en una selección de arquitectura de servidor muy popular para los fabricantes de la nube. Desde AWS Graviton, GCP Tau T2A hasta Huawei Kunpeng y otros productos, podemos ver que varios fabricantes de la nube han comenzado a lanzar servidores basados en la arquitectura Arm. El siguiente gráfico muestra el rendimiento de las pruebas de estrés de APISIX en servidores populares basados en Arm:

Según los datos actuales, el rendimiento de los servidores basados en Arm es ligeramente mejor que el rendimiento de los servidores x86. Para adaptarse a la tendencia tecnológica de la época, APISIX también realizó pruebas de regresión CI completas en ARM64 para garantizar que los usuarios puedan seguir ejecutando varias funciones sin problemas cuando ejecutan APISIX en la arquitectura Arm.

2. Plano de IA

Apache APISIX agrega un plano de IA en la versión 3.0, mejorando el rendimiento en un 30% (medido por QPS bajo pruebas de estrés). El plano de IA optimizaría dinámicamente la configuración del plano de datos, utilizando datos completos como las configuraciones de los usuarios en rutas y complementos, así como métricas de registro. Por ejemplo, los siguientes tres escenarios pueden ser optimizados automáticamente por el plano de IA:

1. Cuando el requisito de coincidencia es simple (por ejemplo, solo contiene uri o host), se habilita la caché para acelerar el proceso de coincidencia de rutas.
2. Si no hay complementos, solo se ejecutaría el código relacionado con el upstream.
3. Si solo hay un nodo upstream y no se habilita ninguna otra opción de configuración, el upstream se configuraría de manera ligera.

El plano de IA trae nuevas posibilidades al procesamiento de tráfico. En el futuro, un calentamiento automático de servicios upstream y la detección de amenazas de seguridad podrían procesarse a través del plano de IA.

3. Adición de Cliente gRPC

En la versión 3.0, Apache APISIX admitirá un nuevo módulo core.grpc. Sin embargo, si estás familiarizado con NGINX y OpenResty, sabrás que su soporte para gRPC es bastante limitado, solo proporcionando características básicas como proxy inverso o balanceo de carga.

APISIX ya ha implementado la transcodificación entre los protocolos gRPC y HTTP en la versión actual 2.x. En la versión 3.0, Apache APISIX agregará un nuevo cliente gRPC para permitir a los desarrolladores llamar directamente a servicios gRPC de terceros sin introducir componentes adicionales o requerir que los proveedores de servicios utilicen diferentes interfaces HTTP, lo que simplifica mucho el proceso.

4. Rediseño de la API de Administración

Al usar APISIX hoy, puedes encontrar que el cuerpo de respuesta de APISIX está mezclado con muchos datos sin significado, como algunos valores de retorno de etcd que se pasan directamente al cliente sin ningún ajuste. Además, el diseño arquitectónico del cuerpo de respuesta completo no es ideal, con muchos campos redundantes.

En la versión 3.0 de APISIX, se ha mejorado la estructura del cuerpo de respuesta. Además, el nuevo diseño hace que el formato general de solicitud y el cuerpo de retorno sean más RESTful, lo que facilita a los usuarios el uso de la última versión de la API de administración. Por supuesto, este proceso también te permite establecer qué versión de la API de administración usar a través de parámetros, liberando a los usuarios del miedo a actualizar a versiones incompatibles.

5. Separación del Plano de Datos (DP) y el Plano de Control (CP)

APISIX ha sufrido varias vulnerabilidades relacionadas con la seguridad en los últimos dos años. La causa principal de la mayoría de las vulnerabilidades es que el DP y el CP se implementan juntos en el modo de implementación predeterminado. Por lo tanto, una vez que existe una vulnerabilidad de seguridad en el plano de datos, un atacante puede invadir directamente el CP a través del DP, afectando a todos los demás DPs.

Por lo tanto, en la versión 3.0, se admite la configuración del modo de implementación, y el modo de implementación predeterminado es traditional, donde el DP y el CP se implementan juntos. Por supuesto, el nuevo modo de implementación recomienda que establezcas el atributo en data_plane o control_plane para separarlos.

Cuando están separados, no solo se pueden resolver los riesgos de seguridad mencionados anteriormente, sino que las iteraciones de funciones en el DP y el CP también son más manejables sin afectarse mutuamente.

6. Mejora del Soporte de Descubrimiento de Servicios

En la versión actual, APISIX ha admitido la integración de muchos componentes de descubrimiento de servicios, como Apache ZooKeeper, Consul, Nacos, y más. Pero en este momento, estas integraciones se realizan todas en el plano de datos. Una vez que tienes muchos nodos en el DP, ejercerá mucha presión sobre los siguientes componentes de descubrimiento de servicios. Al mismo tiempo, en el entorno de producción real de los usuarios, quieren una integración simple como Consul KV o integración de DNS y una integración completa de funciones como controles de salud.

Por lo tanto, en APISIX 3.0, agregamos una capa de abstracción al agregar un subproyecto APISIX-SEED para lograr el soporte de descubrimiento de servicios a nivel del plano de control y reducir la presión sobre el componente de descubrimiento de servicios.

7. Adición del Marco xRPC

El proxy TCP es compatible en la versión actual de APISIX, pero hay momentos en que un proxy de protocolo TCP puro no es suficiente. Los usuarios necesitan un proxy para protocolos de aplicación específicos, como Redis Proxy, Kafka Proxy, etc., porque algunas funciones solo se pueden implementar después de que el protocolo se codifica y decodifica.

Por lo tanto, en la versión 3.0, APISIX implementa un marco de extensión de protocolo de capa de transporte llamado xRPC que permite a los desarrolladores personalizar protocolos de aplicación específicos. Basado en xRPC, los desarrolladores pueden codificar y decodificar solicitudes y respuestas a través de códigos Lua y luego realizar inyección de fallos, informes de registro y enrutamiento dinámico basado en la comprensión del contenido del protocolo.

Basado en el marco xRPC, APISIX puede proporcionar implementaciones de proxy para varios protocolos de aplicación principales. Al mismo tiempo, los usuarios también pueden admitir sus propios protocolos de aplicación basados en TCP privados basados en este marco, lo que les permite tener un control de grano fino y de mayor orden similar al proxy de protocolo HTTP. Además, sobre diferentes protocolos, se pueden abstraer algunos factores comunes para implementar características relacionadas con complementos para que otros protocolos puedan compartir estas características.

8. Soporte de Más Observabilidad en Protocolos de Capa de Transporte

APISIX siempre ha invertido mucho en el soporte de observabilidad, admitiendo casi todos los componentes de observabilidad, como Zipkin, Apache SkyWalking, Datadog, y más. También se admiten varios componentes de registro, pero la mayoría se realizan en la capa de aplicación.

Apache APISIX agregará más soporte de observabilidad en la capa de transporte en la versión 3.0. Por ejemplo, se ha agregado soporte para Prometheus y varios registros, lo que permite a los usuarios observar fácilmente los problemas del tráfico de la capa de aplicación y verificar el estado de operación del tráfico de la capa de transporte.

9. Integración de la Especificación OpenAPI

La API es un elemento que involucra todo el ciclo de vida del desarrollo, desde el diseño hasta la codificación, las pruebas y la implementación. En APISIX 3.0, Apache APISIX admitirá la especificación estándar OpenAPI 3.0.

Por lo tanto, si gestionas las APIs en software de diseño y pruebas de API, es muy sencillo gestionar y mantener los datos en APISIX exportándolos e importándolos. Al mismo tiempo, varias APIs en APISIX también pueden enviarse a través de la especificación OpenAPI 3.0 y luego importarse a otros sistemas para su uso.

Además, APISIX 3.0 también admite formatos personalizados relacionados con Postman (Formato de Colección Postman v2), lo que permite la transferencia de datos entre los dos, facilitando así la integración.

10. Soporte Completo para Gateway API y Service Mesh

El soporte para la Gateway API ha comenzado en el Controlador de Ingress de APISIX, y casi todas las configuraciones de Gateway API son compatibles en la última versión 1.5.

En este caso, el Ingress de APISIX se puede configurar utilizando la Gateway API, lo que significa que puedes cambiar entre diferentes planos de datos. Para finales de este año, el Ingress de APISIX tendrá soporte completo para la Gateway API y características adicionales de capa de transporte y aplicación.

A diferencia de la mayoría de las soluciones de malla de servicios, la solución de malla de servicios de APISIX tiene ventajas en el plano de datos (debido al alto rendimiento de APISIX en sí). Por lo tanto, en la selección del plano de control, esperamos que sea compatible con algunas soluciones principales en la comunidad. Finalmente, al usar el protocolo xDS para integrarse con Istio y escribir la configuración obtenida en el centro de configuración xDS de APISIX, las reglas de enrutamiento específicas son generadas por APISIX para completar las solicitudes de enrutamiento correspondientes.

Esta solución no solo hace que toda la malla de servicios sea más ligera, sino que también hace que el desarrollo personalizado y la migración sean más convenientes con la alta escalabilidad de APISIX.

11. Integración con Más Ecosistemas

Además del estándar OpenAPI mencionado anteriormente, se agregarán muchos complementos de ecosistema en la versión 3.0, como OpenFunction, ClickHouse, Elasticsearch, SAML, CAS, etc., para integrar más soporte para autenticación, seguridad y observabilidad.

Uno de los complementos emocionantes, workflow, se utiliza para la programación de tráfico: podemos hacer un procesamiento granular a nivel de control de tráfico.

curl http://127.0.0.1:9180/apisix/admin/routes/1 \
-H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
{
  "uri":"/hello/*",
  "plugins":{
    "workflow":{
      "rules":[
        {
          "case": [
            ["uri", "==", "/hello/rejected"]
          ],
          "actions": [
            [
              "return",
              {"code": 403}
            ]
          ]
        },
        {
          "case": [
            ["uri", "==", "/hello/v2/appid"]
          ],
          "actions": [
            [
              "limit-count",
              {
                "count": 2,
                "time_window": 60,
                "rejected_code": 429
              }
            ]
          ]
        }
      ]
    }
  },
  "upstream": {
    "type": "roundrobin",
    "nodes": {
      "127.0.0.1:1980": 1
    }
  }
}'

Por ejemplo, realizar una acción específica cuando la condición A es verdadera, realizar otra acción cuando la condición B es verdadera, etc. De esta manera, los usuarios pueden programar varios tráficos empresariales de manera más conveniente.

Comienza con Apache APISIX 3.0

¡Ahora puedes ver APISIX 3.0 en la página de lanzamiento de GitHub y en la página de descargas!

APISIX ha crecido mucho desde el principio hasta la versión 3.0. Un proyecto de código abierto no puede juzgarse únicamente por el rendimiento y la funcionalidad, sino desde la perspectiva de los usuarios, desarrolladores y empresas para considerar si pueden usar el producto para resolver sus puntos de dolor actuales de manera rápida y efectiva.

Los aspectos destacados y las nuevas características mencionadas en este artículo se han creado a través de la comunidad de código abierto. Apache APISIX se ha vuelto más vibrante al recibir comentarios de diferentes desarrolladores y usuarios empresariales. Si deseas unirte a la vibra, ¡consulta la comunidad aquí!