¿Por qué Apache APISIX es la mejor puerta de enlace API?

Hoy en día, los teléfonos móviles se utilizan para todo tipo de cosas, y en la AppStore hay disponibles diversas aplicaciones, incluyendo redes sociales, utilidades, juegos, estilo de vida, compras en línea, etc. La creación de estas aplicaciones es inseparable de las APIs. Por lo tanto, las empresas que ofrecen servicios a través de APIs deben elegir una puerta de enlace de API confiable para garantizar la velocidad, estabilidad y seguridad de sus servicios.

En el panorama de puertas de enlace de API de CNCF, hay casi 20 tipos de puertas de enlace de API (sin incluir los servicios de los proveedores de la nube), incluyendo Apache APISIX, Kong, Tyk, etc. Muchas de ellas se autoproclaman como el proyecto de puerta de enlace de API de código abierto más popular, la próxima generación de puertas de enlace de API, pero ¿lo son?

En este artículo, vamos a analizar múltiples puertas de enlace de API en las dimensiones de popularidad entre los desarrolladores, sus licencias de código abierto, su rendimiento y el ecosistema en general. En este análisis, veremos cómo Apache APISIX es la próxima generación de puerta de enlace de API, superando a sus pares en muchos aspectos.

Los ingenieros de software lo conocen bien

Los ingenieros de software son los usuarios y desarrolladores de API y puertas de enlace de API, por lo que la popularidad entre los ingenieros es un indicador directo de la tendencia. A continuación se muestra un gráfico que compara el número total de contribuyentes de GitHub de cuatro puertas de enlace de API: Apache APISIX, Kong, Tyk y Gloo.

Podemos ver en el gráfico que tanto Kong como Tyk comenzaron alrededor de 2015, mientras que Apache APISIX y Gloo comenzaron más tarde, en 2019. Más significativamente, también podemos ver que el más joven, Apache APISIX, tiene la curva más pronunciada entre todos y ha acumulado más de 320 contribuyentes, superando al segundo mejor, Kong, por 57 personas, convirtiéndose en el proyecto de puerta de enlace de API con más contribuyentes.

Además del número total de contribuyentes, el número de contribuyentes activos mensuales indica una mayor importancia. Los contribuyentes activos mensuales de Tyk han sido solo alrededor de 5 y rara vez superan los 10, mientras que Kong y Gloo han fluctuado entre 10 y 20. Mientras tanto, Apache APISIX tiene contribuyentes activos mensuales por encima de 20 de manera estable, y casi 40 en su punto máximo, convirtiéndolo en el proyecto de puerta de enlace de API más activo.

Detrás de los cuatro proyectos de puertas de enlace de API de código abierto, hay cuatro empresas comercializadas correspondientes. Por lo tanto, otro indicador que hace que APISIX se destaque es la relación entre el número de contribuyentes activos mensuales y el número de empleados.

A partir de 2022, Kong y Tyk tienen una relación del 4%, y Gloo tiene una relación del 24%. En contraste, APISIX casi alcanza el 100%. La razón detrás de esto es que desde el principio, cuando la empresa API7.ai inició el proyecto APISIX, ha estado poniendo un esfuerzo continuo en la comunidad de código abierto y ha ganado su reputación entre los desarrolladores.

Licencia de código abierto: el factor más importante al elegir una puerta de enlace de API de código abierto

Desde que MongoDB cambió su licencia de código abierto a SSPL (Server Side Public License) en 2018, las empresas ahora tienen que abrir su propio código cuando MongoDB se utiliza como un servicio gestionado. Como resultado, las empresas deben considerar seriamente la licencia de código abierto de un proyecto al elegirlo.

En la superficie, Apache APISIX, Kong y Gloo utilizan la licencia Apache License Version 2.0, amigable para los negocios, y Tyk utiliza la Mozilla Public License Version 2.0. Sin embargo, al profundizar, Kong, Gloo y Tky están respaldados por proveedores de código abierto comercializados. Pueden cambiar su licencia en cualquier momento, como lo hizo MongoDB, limitando a las nubes públicas u otras empresas de usarlo libremente, y obligándote a pagar para acceder a las nuevas versiones.

Nadie sabe la probabilidad de cambios en la licencia. Este riesgo, sin embargo, es como la espada de Damocles, colgando sobre los usuarios.

En tales circunstancias, elegir un proyecto de código abierto de la Apache Software Foundation (ASF) o de CNCF es la mejor opción, porque no pueden modificar la licencia del proyecto. Apache APISIX es uno de esos proyectos. Es un proyecto de nivel superior de ASF, lo que significa que ninguna empresa comercial tiene control absoluto del proyecto Apache APISIX, todo el código pertenece a ASF y la licencia no se cambiará. Los usuarios empresariales pueden usarlo libremente sin preocuparse por recibir correos electrónicos de abogados y departamentos de cumplimiento.

Rendimiento de Apache APISIX, Kong y Gloo

Una pregunta frecuente en la comunidad: ¿cuál tiene mejor rendimiento, Gloo basado en Envoy o APISIX basado en NGINX? Aunque el rendimiento no es la métrica más crítica, es innegablemente la métrica más directa. La siguiente tabla muestra los puntajes de referencia de Apache APISIX y Gloo. El QPS de Apache APISIX es 4.6 veces el de Gloo, y la latencia de Apache APISIX es solo el 7% de la de Gloo.

La elección de NGINX o Envoy no es el factor principal de la diferencia de rendimiento, sino la optimización subyacente que APISIX hizo en su código fuente. Incluso en comparación con KONG, que también está basado en NGINX, APISIX tiene una gran ventaja de rendimiento. El siguiente gráfico se extrae del informe de GigaOm sobre las pruebas de la edición empresarial de Kong y la edición empresarial de AP7 (Puedes contactarnos para obtener los datos completos).

La latencia de Kong es decenas o incluso cientos de veces mayor que la de API7 (Edición Empresarial creada por los autores de Apache APISIX).

¿Por qué APISIX tiene una ventaja de rendimiento tan grande? No hay secretos frente al código.

Las palabras son baratas, muéstrame el código

Ahora, analicemos Apache APISIX, Kong y Gloo desde un punto de vista técnico. La ventaja de Apache APISIX se basa principalmente en la optimización e innovación del código fuente. Las ventajas de estas tecnologías no necesariamente se reflejan en un simple PoC (Prueba de Concepto), sino en un entorno de producción más complejo.

Antes de la aparición del proyecto APISIX, había muchos productos de puertas de enlace de API comerciales o de código abierto. Estos productos almacenaban datos de API, información de enrutamiento, certificados y datos de configuración en una base de datos relacional. Las ventajas de almacenar estos datos en bases de datos relacionales son muy obvias. Los usuarios pueden usar declaraciones SQL para realizar consultas flexibles, y también es conveniente para los usuarios realizar copias de seguridad y mantenimiento posterior.

Sin embargo, la puerta de enlace es un middleware que maneja todo el tráfico del cliente. El requisito de disponibilidad es extremadamente alto. Si la puerta de enlace de API depende de una base de datos relacional, significa que una vez que la base de datos relacional falle (como un tiempo de inactividad o pérdida de datos), la puerta de enlace de API también se verá afectada, y la disponibilidad de todo el sistema también sufrirá.

Para reducir el daño, APISIX estructuró su arquitectura para evitar la posibilidad de tiempo de inactividad y pérdida de datos. APISIX utilizó etcd para almacenar datos de configuración en lugar de una base de datos relacional, las ventajas de hacerlo son las siguientes:

1. Está más alineado con la arquitectura nativa de la nube
2. Representa mejor el tipo de datos necesarios para la puerta de enlace de API
3. Tendrá una mayor disponibilidad
4. Los cambios pueden notificarse en un nivel de sub-milisegundos

Después de usar etcd para almacenar datos de configuración, los usuarios solo necesitan monitorear las actualizaciones de etcd para los cambios de datos. APISIX podrá obtener la última configuración en milisegundos, logrando un efecto en tiempo real. Sin embargo, si estuviéramos sondeando la base de datos, podría tomar de 5 a 10 segundos obtener la última información de configuración. Por lo tanto, usar etcd como el esquema de almacenamiento no solo hace que APISIX sea más nativo de la nube, sino también de mayor disponibilidad.

Algoritmo de coincidencia de rutas de alto rendimiento

Para procesar una solicitud, la puerta de enlace de API necesita coincidir la expresión objetivo con la información del host, URI, métodos HTTP y otra información de cada solicitud. Por lo tanto, un algoritmo de coincidencia eficiente es crucial. El algoritmo basado en hash tiene un buen rendimiento, pero no puede lograr coincidencias difusas. Las expresiones regulares pueden realizar coincidencias difusas, pero el rendimiento no es tan bueno. La solución de Apache APISIX es usar un árbol, una estructura de datos de búsqueda eficiente que admite coincidencias difusas. Para ser más precisos, Apache APISIX utiliza un árbol radix (árbol de prefijos comprimido), una estructura de datos que solo comprime nodos intermedios con un hijo. Entre todos los productos de puertas de enlace de API conocidos, Apache APISIX es el primero en aplicar el árbol radix en la coincidencia de rutas y admite el escenario donde un prefijo puede coincidir con múltiples rutas. Para los detalles de implementación, ver lua-resty-radixtree.

Al coincidir una solicitud, el algoritmo con el árbol radix lo hará progresivamente, con una complejidad de O(K) (K es la longitud del URI en la ruta, y es independiente del número de APIs). Este algoritmo se adapta muy bien en escenarios donde hay un gran número de rutas, como en nubes públicas o CDN. También no tiene problemas para manejar un gran número de rutas que aumentan rápidamente.

Algoritmo de coincidencia de IP de alto rendimiento

Una dirección IP tiene dos notaciones: notación estándar de IP y notación CIDR, tomando como ejemplo IPv4 de 32 bits:

• Notación estándar de IP: 192.168.1.1
• Notación CIDR: 192.168.1.1/8

La coincidencia de IP y la coincidencia de rutas de Apache APISIX utilizan algoritmos diferentes. Tomando como ejemplo la IP 192.168.1.1, dado que el rango de cada segmento de IP es de 0 a 255, podemos pensar que la dirección IP está compuesta por cuatro números enteros de 16 bits, y la longitud de la IP es fija. Por lo tanto, podemos usar un algoritmo más eficiente para completar la coincidencia.

Suponiendo que hay una biblioteca de IP que contiene 500 registros IPv4, APISIX almacenará en caché los 500 registros IPv4 en la tabla hash y usará la tabla hash para la coincidencia de IP. La complejidad de tiempo es O(1). Otras puertas de enlace de API completan la coincidencia de IP a través de la iteración de listas, y cada solicitud enviada a la puerta de enlace puede iterarse hasta 500 veces. Por lo tanto, el algoritmo de coincidencia de IP de alta precisión de APISIX mejora enormemente la eficiencia de los escenarios que requieren una lista masiva de IP permitidas y denegadas (como WAF).

Refinamiento de rutas

Las puertas de enlace de API coinciden las reglas predefinidas con la información de las solicitudes, como la información del host, URI, parámetros de consulta URI, parámetros de ruta URI, métodos HTTP, encabezados de solicitud, etc. Estas piezas de información son compatibles con la mayoría de las puertas de enlace de API. Sin embargo, Apache APISIX admite más datos además de estos para resolver casos más complejos.

Primero, Apache APISIX admite variables integradas de NGINX, lo que significa que podemos usar docenas de variables integradas de NGINX como parámetros de coincidencia, incluyendo uri, server_name, server_addr, request_uri, remote_port, remote_addr, query_string, host, hostname, arg_name.

Para una lista de variables integradas de NGINX, ver NGINX Variables.

Segundo, Apache APISIX admite expresiones condicionales como reglas de coincidencia, y su estructura es [var, operador, val], ...]], donde:

• Los valores de var pueden ser variables integradas de NGINX.
• operador admite igual, mayor que, menor que, expresiones regulares, contiene, etc.

Suponiendo que la expresión es ["arg_name", "==", "json"], significa si hay un valor de parámetro de name igual a json en los parámetros de consulta URI de la solicitud actual. Apache APISIX implementa esta característica a través de su biblioteca lua-resty-expr. Para detalles, por favor referirse a lua-resty-expr. Esta característica da al usuario mucha flexibilidad y es altamente extensible.

Además, Apache APISIX permite a los usuarios configurar el ttl (tiempo de vida) de las rutas.

$ curl http://127.0.0.1:9080/apisix/admin/routes/2?ttl=60 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -i -d '
{
    "uri": "/aa/index.html",
    "upstream": {
        "type": "roundrobin",
        "nodes": {
            "39.97.63.215:80": 1
        }
    }
}'

El código anterior significa que APISIX eliminará automáticamente la configuración de enrutamiento después de 60 segundos, lo que será necesario para algunos escenarios de verificación temporal, como la liberación canaria. También es muy conveniente para la división de tráfico en línea, una característica que otros productos de puerta de enlace no tienen.

Por último, Apache APISIX admite funciones de filtro personalizadas, uno puede escribir funciones personalizadas de Lua en el parámetro filter_func, por ejemplo:

$ curl http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -i -d '
{
    "uri": "/index.html",
    "hosts": ["foo.com", "*.bar.com"],
    "filter_func": "function(vars)
                    return vars['host'] == 'api7.ai'
                end",
    "upstream": {
        "type": "roundrobin",
        "nodes": {
            "127.0.0.1:1980": 1
        }
    }
}'

El parámetro de entrada de filter_func es vars, y se pueden obtener variables de NGINX desde vars, y luego se puede personalizar la lógica de filtrado.

Soporte para complementos de múltiples lenguajes

Los usuarios a menudo necesitan personalizar algunos de los desarrollos e integraciones del sistema de la puerta de enlace de API para escenarios específicos.

APISIX actualmente admite más de 80 complementos, pero aún es difícil cubrir todos los escenarios de los usuarios. Por lo tanto, la mayoría de las empresas desarrollarán complementos personalizados para negocios específicos, integrarán más protocolos y sistemas a través de la puerta de enlace y lograrán una gestión unificada en la capa de la puerta de enlace.

En versiones anteriores de APISIX, los desarrolladores solo podían usar Lua para desarrollar complementos. Aunque los complementos desarrollados en lenguajes de computación nativos tienen un rendimiento muy alto, aprender Lua, un nuevo lenguaje de desarrollo, requiere tiempo y costos de aprendizaje.

En respuesta a esta situación, APISIX proporciona dos soluciones.

La primera solución es admitir más lenguajes de programación principales (como Java, Python, Go, etc.) a través de Plugin Runner. Usando Plugin Runner, los ingenieros de back-end pueden comunicarse a través de RPC local para desarrollar complementos de APISIX utilizando los lenguajes de programación con los que están familiarizados. La ventaja de esto es reducir los costos de desarrollo y mejorar la eficiencia del desarrollo. La desventaja será las pérdidas de rendimiento. Entonces, ¿hay alguna manera de lograr el rendimiento casi nativo de Lua utilizando lenguajes de alto nivel con los que los desarrolladores están familiarizados?

La segunda solución es usar Wasm para desarrollar complementos, como se muestra en la parte izquierda de la figura anterior. Wasm (WebAssembly) se utilizó por primera vez como una nueva tecnología que se ejecuta en los navegadores, pero ahora también está mostrando gradualmente sus ventajas en el lado del servidor. Incrustamos Wasm en APISIX, y los usuarios pueden usar Wasm para compilar bytecode de Wasm para ejecutar en APISIX. Para hacer uso de Wasm, desarrollamos un complemento de Wasm donde los usuarios pueden desarrollar complementos de APISIX casi nativos utilizando lenguajes de programación de alto nivel.

Como resultado, los usuarios pueden usar Lua, Go, Java, Python, Node.js y Wasm para escribir complementos personalizados en APISIX. Al facilitar el desarrollo, abre las puertas para el desarrollo de complementos de APISIX.

Conclusión

En este artículo, analizamos y comparamos productos de puertas de enlace de API desde múltiples perspectivas, como ingenieros de software, protocolos de código abierto, evaluación de rendimiento, tecnología y ecosistema. Podemos ver que Apache APISIX es superior en muchos aspectos, un pionero en la red de API.

Apache APISIX no solo es una puerta de enlace de API que puede manejar tráfico norte-sur, sino que también tiene productos de código abierto como APISIX Ingress Controller y Service Mesh.

También proporciona productos empresariales y SaaS basados en APISIX.

¡Prueba los productos Apache APISIX y API7 Enterprise hoy mismo!