Exploraciones técnicas de la puerta de enlace API de código abierto Apache APISIX

Antecedentes

Apache APISIX es una puerta de enlace API de código abierto dinámica, en tiempo real y de alto rendimiento que ofrece funciones avanzadas de gestión de tráfico, como balanceo de carga, enrutamiento dinámico, lanzamiento canario, cortocircuito, autenticación de identidad y observabilidad.

Como puerta de enlace API, Apache APISIX puede ayudar a las empresas a procesar el tráfico de API y microservicios de manera rápida y segura en escenarios como puertas de enlace, Kubernetes Ingress y mallas de servicio. Además, puede manejar el tráfico norte-sur (del cliente al servidor) y el tráfico este-oeste (entre microservicios empresariales).

Lanzado como código abierto el 6 de junio de 2019, APISIX fue donado a la Apache Software Foundation en octubre de 2019 y rápidamente se convirtió en un proyecto de nivel superior de la Apache Software Foundation en cuestión de meses.

¿Por qué APISIX ha tenido un auge tan rápido? ¿Qué tipo de exploraciones técnicas mágicas ha realizado APISIX? ¿Por qué cada vez más desarrolladores y empresas están dispuestos a usar APISIX? Vamos a descubrirlo.

Características principales de Apache APISIX

Libre de dependencias de bases de datos

Antes de que surgiera el proyecto APISIX, existían muchas puertas de enlace API comerciales o proyectos de código abierto. El problema potencial de esos competidores es que la mayoría de estos productos almacenan sus datos de API, información de configuración, configuración de certificados y rutas en una base de datos relacional.

Las ventajas aparentes de almacenar en una base de datos relacional son que facilita a los usuarios realizar consultas flexibles con sentencias SQL y realizar copias de seguridad y mantenimiento posterior.

Sin embargo, cada moneda tiene dos caras. Como middleware básico, la puerta de enlace API manejará todo el tráfico del cliente, lo que aumenta los requisitos de disponibilidad. Si tu puerta de enlace API depende de una base de datos relacional, la puerta de enlace se verá afectada si ocurre un error en la base de datos, como un fallo o pérdida de datos. En este caso, se refuerza la limitación de la disponibilidad general del sistema.

Por lo tanto, los diseñadores de APISIX intentaron por todos los medios evitar tales problemas desde el aspecto de la arquitectura subyacente.

La arquitectura de APISIX se divide principalmente en dos partes. La primera parte, llamada plano de datos, es el componente que maneja las solicitudes y el tráfico de los clientes. Admite autenticación, descarga de certificados, análisis de registros y observabilidad. El plano de datos no almacena datos, lo que lo convierte en una estructura sin estado.

La segunda parte se llama plano de control. APISIX no utiliza almacenamiento de configuración tradicional como MySQL, sino etcd en el plano de control.

Las ventajas de hacerlo son:

1. Mayor alineación con la arquitectura nativa de la nube de los productos.
2. Más adecuado para los tipos de datos almacenados por la puerta de enlace API.
3. Mejor reflejo de las características de alta disponibilidad.
4. Notificaciones de cambios en milisegundos.

Al usar etcd, el plano de datos solo necesita monitorear los cambios en etcd. Si se consulta la base de datos, puede tomar de 5 a 10 segundos obtener la última configuración. Sin embargo, si se monitorean los cambios de configuración en etcd, se puede obtener retroalimentación en milisegundos para lograr un efecto en tiempo real.

Por lo tanto, usar etcd en lugar de una base de datos relacional hace que APISIX sea más compatible con el entorno nativo de la nube en la capa subyacente y refuerza sus ventajas de alta disponibilidad.

Plugins para múltiples lenguajes de programación

Las puertas de enlace API son algo diferentes de las bases de datos y otros middleware. En comparación con estos últimos, las puertas de enlace se utilizan con mayor frecuencia en desarrollos personalizados e integración de sistemas.

Aunque APISIX ha lanzado muchos plugins oficiales, aún es difícil cubrir todos los escenarios de uso para diferentes usuarios. Por lo tanto, en el uso real, es necesario desarrollar algunos plugins personalizados para el negocio, más o menos. APISIX también integra más protocolos o sistemas a través de la puerta de enlace y finalmente logra una gestión unificada en la capa de la puerta de enlace.

Al principio, APISIX solo admitía el desarrollo de plugins en el lenguaje Lua. La ventaja es que los plugins desarrollados pueden tener un alto rendimiento gracias a la optimización subyacente del lenguaje de programación nativo. Sin embargo, hay una desventaja evidente: aprender Lua, un nuevo lenguaje, requiere tiempo y costos de aprendizaje.

Esencialmente, APISIX resuelve los problemas de dos maneras.

La primera forma es admitir más lenguajes de programación principales, como Java, Python, Go, etc., a través del Runner Plugin. Si eres un ingeniero de backend, deberías conocer al menos uno de estos lenguajes; entonces, puedes utilizar fácilmente el protocolo RPC y desarrollar un plugin de APISIX utilizando el lenguaje con el que estás familiarizado.

Por un lado, es beneficioso para reducir los costos de desarrollo y mejorar la eficiencia del desarrollo. Sin embargo, por otro lado, hay cierta latencia a nivel de rendimiento. Entonces surge la pregunta: ¿habría una solución que pueda lograr el rendimiento nativo de Lua y, al mismo tiempo, tener en cuenta los lenguajes de alto nivel?

Aquí viene el segundo método, mostrado en la parte izquierda de la imagen anterior. WebAssembly se utilizó inicialmente como una tecnología en el frontend o el navegador y gradualmente ofrece sus ventajas en el lado del servidor.

Al integrar WebAssembly en APISIX, los usuarios pueden usarlo para compilar a bytecode WebAssembly que se ejecuta en APISIX. El efecto final es desarrollar de manera eficiente un plugin de APISIX que sea tanto de alto rendimiento como escrito en lenguajes de programación de alto nivel.

Por lo tanto, en la versión actual de APISIX, los usuarios pueden usar Lua, Go, Python, Wasm y otros métodos para personalizar el código basado en APISIX. Este diseño reduce el umbral para los desarrolladores y proporciona más posibilidades para las funciones de APISIX.

Recarga en caliente de plugins

APISIX tiene dos avances significativos en comparación con NGINX: APISIX admite la gestión de clústeres y la recarga dinámica.

Si has usado NGINX, sabrás que todas las configuraciones de NGINX se escriben en el archivo de configuración nginx.conf. Para realizar el control del clúster, es necesario modificar el archivo nginx.conf en cada servidor. No hay un plano de control centralizado en todo el proceso. Cada NGINX es una combinación del plano de datos y el plano de control. El costo de gestión será excepcionalmente alto si los usuarios tienen docenas o cientos de servidores NGINX.

En el escenario mencionado anteriormente, cada servidor NGINX necesita reiniciarse para funcionar después de modificar el archivo nginx.conf. Por ejemplo, para actualizaciones de certificados o cambios en los upstream, primero debes modificar el archivo de configuración y luego reiniciar el servidor para que surta efecto. Este método es apenas aceptable si tu solicitud no es particularmente grande. Sin embargo, a medida que las API y los microservicios aparecen cada vez más, el impacto en el cliente será enorme si el servidor necesita reiniciarse por cada modificación.

• Actualizaciones en caliente y plugins en caliente: ¡Actualiza continuamente sus configuraciones y plugins sin reinicios!
• Reescritura de proxy: Admite la reescritura del host, URI, esquema, método y encabezados de la solicitud antes de enviarla al upstream.
• Reescritura de respuesta: Establece un código de estado, cuerpo y encabezado personalizados en la respuesta al cliente.
• Balanceo de carga dinámico: Balanceo de carga round-robin con peso.
• Balanceo de carga basado en hash: Balanceo de carga con sesiones de hash consistentes.
• Chequeos de salud: Habilita chequeos de salud en el nodo upstream y filtra automáticamente los nodos no saludables durante el balanceo de carga para garantizar la estabilidad del sistema.
• Cortocircuito: Seguimiento inteligente de servicios upstream no saludables.
• Espejo de proxy: Proporciona la capacidad de reflejar las solicitudes del cliente.
• División de tráfico: Permite a los usuarios dirigir porcentajes de tráfico de manera incremental entre varios upstreams.

La imagen anterior enumera los componentes donde APISIX implementa actualmente la recarga en caliente. Podemos ver que el código entra en vigor en tiempo real desde el upstream hasta el certificado e incluso el plugin. Algunos miembros de la comunidad pueden entender por qué el upstream y los certificados son dinámicos, ya que los datos cambian con frecuencia. Sin embargo, se preguntarían por qué la modificación del plugin necesita ser dinámica, ya que consideran que modificar el plugin es poco frecuente, lo que parece innecesario que sea altamente activo.

Como diseñadores subyacentes de APISIX, esperamos que sea completamente dinámico, lo que trae una ventaja significativa al aumentar más posibilidades para las empresas. Por ejemplo, los usuarios pueden solucionar problemas de código mientras modifican el plugin de depuración sin cambiar ningún código del plugin. En tales circunstancias, el usuario puede reproducir el problema en cualquier momento y registrarlo sin reiniciar. El plugin con función de depuración combinado con el mecanismo de recarga en caliente será muy flexible, ayudando a los desarrolladores a ahorrar tiempo y esfuerzo en la solución de problemas.

Orquestación dinámica de plugins

Además de la recarga en caliente, APISIX admite la orquestación dinámica en tiempo real entre plugins. La orquestación dinámica también trae infinitas posibilidades para la operación de los plugins.

¿Qué es la orquestación de plugins? Cuando planteamos varios requisitos, esperamos convertir una solicitud en un plugin, como jugar con LEGO. Podemos construir una variedad infinita de formas posibles a través de un estándar unificado como el ajuste de formas y la intersección, que es una de las alegrías de LEGO. Para los plugins de APISIX, cada plugin cumple un caso de uso independiente. No podemos dejar de preguntarnos si es posible permitir a los usuarios personalizar sus necesidades con plugins como si estuvieran jugando con LEGO.

Por ejemplo, si hay 100 plugins en APISIX, los usuarios solo pueden ver las funciones de estos 100 plugins en lugar de su flexibilidad subyacente. Por lo tanto, al desarrollar middleware, debemos considerar lo que el producto puede ser y cómo dotar de más posibilidades cuando las personas lo usan.

APISIX actualmente tiene casi 100 plugins, pero tiene muchas más de 100 posibilidades. En consecuencia, después de desarrollar su capacidad en la disposición de plugins, la combinación se convierte en 100 * 99 * 98 * 97 * 96 * ..., cercano a infinito.

Por ejemplo, un código de error generalmente ocurre después de limitar la tasa de un usuario. Puedes intentar conectar un plugin de registro o un plugin de informes de errores para la grabación posterior de actividades. La imagen a continuación muestra el modelo de orquestación de plugins de APISIX.

Esta característica tiene un beneficio oculto: un conjunto completo de pruebas cubre el código de cada plugin. Cuando el usuario organiza el plugin, no necesita escribir ningún código. El diseño sería extremadamente amigable para gerentes de producto, ingenieros de seguridad e ingenieros de operaciones y mantenimiento que no necesitan pasar largas horas en capacitación y aprendizaje. En cambio, pueden crear un nuevo plugin de APISIX simplemente arrastrando plugins para ajustar algunas configuraciones. Además, la calidad del código del nuevo plugin es tan alta como el código oficial del APISIX de código abierto.

Puerta de enlace para tráfico en todas direcciones

Los ingenieros del lado del servidor que realizan algún desarrollo relacionado con puertas de enlace podrían estar familiarizados con dos conceptos básicos: Tráfico Norte-Sur, que se refiere al tráfico desde clientes, navegadores o dispositivos IoT (Internet de las cosas) al servidor, y Tráfico Este-Oeste, que se refiere a las llamadas mutuas entre sistemas y microservicios dentro de las empresas.

Los componentes son diferentes al tratar el tráfico norte-sur y este-oeste. Por ejemplo, el tráfico norte-sur puede pasar por un balanceador de carga, ir a la puerta de enlace API y luego entrar en una puerta de enlace de servicio. Es por eso que existen componentes como NGINX, APISIX y Spring Cloud Gateway. Al tratar el tráfico este-oeste con una malla de servicio, puedes usar componentes como Envoy, que parecen muchos, pero puedes encontrar sus similitudes si te enfocas en sus funciones. La mayoría son plugins para enrutamiento, upstream dinámico y autenticación segura de identidad. En este caso, ¿podemos unificar los componentes que manejan el tráfico norte-sur y este-oeste? La forma ideal es que cuando una solicitud de un cliente ingresa al servidor, todo sea manejado por APISIX. No importa si es norte-sur o este-oeste, todo el tráfico y los datos se controlan a través del plano de control. Es completamente alcanzable con la tecnología actual de APISIX.

Algunos de nuestros usuarios ya confirman que este modo puede reducir significativamente los costos de operación y mantenimiento del usuario. Al mismo tiempo, puede reducir la complejidad, mejorando así la velocidad de respuesta de todo el sistema. Además, tales comentarios positivos dan una dirección más clara para las iteraciones posteriores de APISIX, permitiendo que APISIX intente más funciones y roles a nivel de puerta de enlace de tráfico completo.

Soporte para múltiples componentes de descubrimiento de servicios

La puerta de enlace es un componente fundamental pero vital. Procesa todas las solicitudes de los clientes e integra varios sistemas y proyectos de código abierto, lo cual es más importante.

Otro componente esencial: el descubrimiento de servicios y el registro se utilizarán en la integración con otros elementos. Los usuarios colocarán varios servicios en partes separadas, como Eureka y Nacos. En consecuencia, es común que coexistan múltiples componentes de descubrimiento de servicios en sistemas de TI a gran escala y de larga duración.

En esta situación, todo el tráfico de entrada y salida se convierte en puertas de enlace. Casi todas las puertas de enlace admiten solo un descubrimiento de servicios. Debes especificar un componente de descubrimiento de servicios Nacos separado en la ruta A y otro componente Consul en la ruta B. En consecuencia, debes implementar múltiples puertas de enlace para que coincidan con puertas de enlace específicas para diferentes componentes de descubrimiento de servicios.

Actualmente, APISIX no solo admite el descubrimiento de servicios en el plano de datos, sino que también admite gradualmente los componentes de registro y descubrimiento de servicios en el plano de control. Es una solución altamente eficiente para algunos servicios empresariales a gran escala y de larga duración. Puedes conectarte fácilmente a varios componentes de descubrimiento y registro de servicios implementando solo una puerta de enlace API.

Exploración de escenarios multi-nube y nube híbrida

Si los usuarios implementan la puerta de enlace en un entorno de producción equipado con arquitectura nativa de la nube, la multi-nube y la nube híbrida deben ser un escenario técnico a largo plazo. Por otro lado, si APISIX se configura con todas las funciones, rendimiento, plugins y múltiples descubrimientos de servicios, el problema inevitablemente surge de cómo hacer que los usuarios funcionen mejor en un entorno de producción. Los escenarios de multi-nube y nube híbrida traen más desafíos a APISIX. Por lo tanto, se deben considerar más detalles como los siguientes.

1. Tanto el upstream como el downstream admiten mTLS

Anteriormente no reconocíamos que la función de admitir mTLS en el upstream era una prioridad alta. Sin embargo, una vez que se encuentra en un escenario de nube cruzada, el upstream puede ser un servicio en otra nube o incluso convertirse en otro servicio SaaS. Por lo tanto, es necesario admitir mTLS en el upstream para mejorar la seguridad de los datos.

2. Separación completa de la arquitectura del plano de control y el plano de datos

Varias vulnerabilidades de seguridad de APISIX se expusieron en el último año, la mayoría de las cuales provienen de la implementación híbrida de sus planos de control y datos. En otras palabras, los planos de control y datos están en el mismo servicio después de que se inicia el servicio APISIX. Entonces, una vez que un hacker invade un plano de datos específico a través de una brecha de seguridad, también puede acceder al plano de control para controlar todos los datos, causando consecuencias desastrosas.

3. Fortalecimiento de la gestión de seguridad

La puerta de enlace generalmente almacena algunos datos sensibles. Por ejemplo, algunos usuarios pueden almacenar el certificado SSL o la información crítica para conectarse a etcd en la puerta de enlace. En tales circunstancias, una vez que etcd o el plano de datos se ve comprometido, puede causar una fuga grave de datos. Por lo tanto, al almacenar información esencial, es necesario considerar el uso de un componente dedicado a almacenar claves como Vault para proteger los datos sensibles.

4. Integración de más estándares de la nube

Pretendemos asegurar que los usuarios puedan ejecutarse sin problemas en varias plataformas en la nube sin configurar nada en escenarios de multi-nube. No significa que los usuarios necesiten configurar plugins personalizados, sino que APISIX integra directamente estándares, API u otros servicios de varias nubes. Este modo puede ayudar a los usuarios a adaptarse de antemano y garantizar comodidad y facilidad de uso posterior.

Partidarios de Apache APISIX

A lo largo de la historia del desarrollo de APISIX, se han realizado muchas innovaciones técnicas. Los crecientes contribuyentes de la comunidad trabajan mano a mano desde la fase de construcción del código para convertir APISIX en una puerta de enlace API integrada. Hoy en día, APISIX mantiene una iteración rápida, gracias a los esfuerzos de sus partidarios.

La iteración y actualización de un producto de código abierto deben atribuirse a los contribuyentes y usuarios.

Cuando APISIX fue donado a la Apache Software Foundation hace tres años, era un proyecto inmaduro con solo 20 contribuyentes. Afortunadamente, APISIX ha atraído a más usuarios, contribuyentes y empresas en todo el mundo debido a su rápido desarrollo. Por ejemplo, nuestros clientes incluyen empresas como Tencent, WPS, Sina Weibo e iQiyi, manejando decenas de miles de millones de llamadas API diarias. Además, muchos usuarios internacionales de diversas industrias, como NASA, European Factory Platform, Swisscom, etc., están en nuestra lista de clientes.

Tomemos WPS como ejemplo. Es una empresa de software de oficina SaaS en China, que proporciona software como Microsoft Office 365. Ya sea que trabajes con varias personas en teléfonos móviles, navegadores o dispositivos terminales, docenas o cientos de usuarios pueden editar el mismo documento y ver las modificaciones simultáneamente. La función se realiza a través de varias llamadas de la API.

La mayoría de los gigantes manejan decenas de miles de millones de llamadas API, con un pico de QPS que supera el millón. Tal escala de uso también permite que APISIX obtenga retroalimentación de usuarios reales en circunstancias a gran escala. Gracias al apoyo de estos usuarios empresariales, APISIX se ha desarrollado rápidamente en un proyecto de código abierto maduro.

Además, muchos usuarios también comparten sus experiencias o iteraciones de funciones de código al usar APISIX en la comunidad, contribuyendo a un beneficio mutuo y una situación de ganar-ganar para ambas partes. Se demuestra que los usuarios consideran APISIX como un buen producto y más como un proyecto de código abierto valioso. Solo después de ganar la confianza de los desarrolladores podemos tener la oportunidad de convertirnos en un proyecto de código abierto valioso.

Los contribuyentes adaptan la experiencia y la retroalimentación para crear muchas características del producto; los usuarios pueden utilizar estas características para aportar valor a las empresas. Surge un círculo virtuoso, que es la esencia del código abierto. Siempre buscamos este tipo de verdad en lugar de perseguir ciegamente burbujas de numerosos seguidores.

Vista previa de APISIX 3.0

Hasta ahora, hemos hablado mucho sobre lo que APISIX ha hecho en el pasado y ahora. El proceso de desarrollo de APISIX se puede dividir en varias etapas.

APISIX 1.0 fue para construir su marco, fortalecer la arquitectura subyacente y presentar algunas funciones esenciales de la puerta de enlace API. Exploramos más profundamente en la versión 2.0, haciendo que la capa inferior sea más flexible y la arquitectura más madura.

Para un proyecto de código abierto maduro, el signo de su madurez no se centra en su gran función, sino en brindar una mejor experiencia para los usuarios y desarrolladores.

En la etapa actual, APISIX ha realizado muchas exploraciones e innovaciones técnicas, pero no ha considerado completamente las experiencias de los usuarios. El problema muestra una calidad de documentación inestable y una falta de videos tutoriales. Por lo tanto, muchos usuarios están perdidos cuando entran en contacto con APISIX por primera vez. No saben cómo usarlo o aplicar ciertas funciones a diferentes casos de uso, y no están seguros de qué valor único puede aportar APISIX a las empresas.

Por lo tanto, en la próxima versión APISIX 3.0, intentaremos resolver problemas similares y reconstruir muchas fallas que no son amigables para la experiencia del desarrollador. Por ejemplo, rediseñaremos la API para eliminar la dependencia de valores de retorno específicos de etcd y renovaremos la documentación oficial para que sea más amigable con descripciones sencillas. En el aspecto del nivel de función, el plano de control y el plano de datos también se separarán para mejorar la seguridad; admitirá más protocolos de capa 4 y protocolos RPC para que los usuarios puedan obtener rápidamente el tráfico desde todas las direcciones de la puerta de enlace.

Después de implementar las funciones anteriores, APISIX 3.0 se volverá más seguro, confiable y fácil de usar. Siempre prestamos atención a las excelentes operaciones y la experiencia del usuario. Esperamos que APISIX pueda manejar solicitudes de todas las API y microservicios en todo el mundo y ayudar a las empresas a gestionar el tráfico de API y microservicios de manera más eficiente.

Se espera que APISIX lance una nueva versión, 3.0, a finales de 2022. Esperamos que continúes siguiendo las tendencias de la última versión de APISIX y participes activamente en la contribución del proyecto Apache APISIX.

El futuro de APISIX

El desarrollo y la sustitución de la tecnología del lado del servidor son muy rápidos, ya que muchas tecnologías y marcos populares hace cinco años están desapareciendo. La razón no es que los ingenieros prefieran cosas nuevas, sino que estas tecnologías no pueden satisfacer las necesidades reales de los ingenieros y las empresas. Su destino está sellado: ser expulsados. La realidad crucial nos dice que la tecnología debe servir a los negocios y productos, y no puede sobrevivir sin coincidir con las necesidades actuales del mercado.

"No construyas un castillo sobre un pantano". Este dicho siempre recuerda a los desarrolladores de Apache APISIX que deben basarse en necesidades y escenarios reales para guiar su desarrollo y evolución. De lo contrario, el producto será abandonado gradualmente por los ingenieros.

¿Cómo podemos mantener la tecnología de Apache APISIX a la vanguardia de la industria? Es la pregunta crucial de si Apache APISIX puede seguir atrayendo a desarrolladores y usuarios empresariales en el futuro. La respuesta es simple: únete a empresas e ingenieros de rápido crecimiento, crece juntos y apóyate mutuamente. Esto hace que Apache APISIX siempre esté a la vanguardia de la tecnología. Solo así APISIX tendrá el potencial de convertirse en un proyecto de código abierto perenne de clase mundial.

El futuro de APISIX es apoyar mejor los escenarios Serverless, mejorar la malla de servicio, construir plataformas de ciclo de vida completo de API y mejorar la experiencia del usuario en la nube pública. Estos no están planeados por unos pocos desarrolladores internos, sino por miles de desarrolladores en la industria. ¡Únete a nosotros para experimentar el encanto del código abierto!