Apache APISIX unifica la gestión completa del tráfico con Service Mesh

Con el rápido crecimiento de Cloud Native, Service Mesh también está comenzando a ganar popularidad. Actualmente, existen muchas soluciones conocidas de Service Mesh, y cada producto tiene sus propias ventajas. Por lo tanto, las decisiones sobre las soluciones de Service Mesh varían según la persona, dependiendo de la industria o el contexto empresarial.

Situación Actual y Puntos Críticos de Service Mesh

La aparición de Service Mesh está fuertemente relacionada con la evolución actual de la arquitectura empresarial. Con la creciente tendencia de Cloud Native, la mayoría de las empresas comenzaron a transformarse hacia microservicios, donde observamos que las aplicaciones comenzaron a volverse cada vez más pequeñas, y cada aplicación tenía algunas funcionalidades comunes en su interior. Esto nos llevó a pensar: "¿Existe una tecnología que pueda resolver estos escenarios comunes?" Así surgió Sidecar.

Con Sidecar, algunas funciones como el registro y descubrimiento de servicios, la gestión de tráfico, la observabilidad y la seguridad pueden delegarse a él, permitiendo que los servicios empresariales se concentren en desarrollar la lógica de negocio.

Sin embargo, la aparición de Sidecar ha hecho que las personas se den cuenta gradualmente de algunos de sus puntos críticos en la práctica, como:

• Existen tantas soluciones que es difícil migrar una vez elegida. Hoy en día, hay numerosas soluciones de Service Mesh, y las características y capacidades varían de una solución a otra. Una vez que se elige una de estas soluciones, se utiliza sin posibilidad de reemplazo. Sin embargo, si descubrimos que la solución no cumple con los nuevos requisitos cuando el negocio se expande, los costos de migración son enormes.
• Alto costo de integración con la infraestructura. La implementación de Service Mesh en la práctica a menudo requiere integración con infraestructuras, como arquitecturas de microservicios anteriores, MQ o componentes de infraestructura de bases de datos. Algunos problemas heredados o deuda técnica histórica también pueden crear resistencia en el proceso de integración.
• Pérdida de rendimiento y consumo adicional de recursos. Actualmente, sin importar qué solución de Service Mesh elijas, habrá alguna pérdida de rendimiento. Además, debido a Sidecar, se necesitan recursos adicionales para configurarlo en el negocio.
• Dificultad severa para escalar. Algunas soluciones de Service Mesh no son escalables en términos de protocolos o características con los métodos de configuración existentes, y no son personalizables mediante la conexión y desconexión de componentes.

Por lo tanto, ante la situación empresarial y los puntos críticos, comenzamos a pensar si podría existir una solución ideal de Service Mesh que pudiera resolver estos problemas.

¿Cómo se ve un Service Mesh ideal?

En los escenarios empresariales, nuestros requisitos para Service Mesh son, como se muestra arriba, es decir, hay múltiples dimensiones de requisitos en la dirección de recursos, rendimiento, gestión de tráfico y escalabilidad. Por supuesto, además de estos, también habrá algunos requisitos más detallados en otras dimensiones. Por ejemplo:

• Primero, a nivel de experiencia de uso, es necesario lograr un menor costo de inicio, ya que puede haber más operaciones de mantenimiento para aplicar Service Mesh que desarrolladores. Por lo tanto, el costo de inicio es uno de los factores que las personas consideran al elegir una solución.
• En segundo lugar, a nivel técnico, la configuración del plano de control debe ser fácil de iniciar. Al mismo tiempo, los permisos relevantes deben controlarse de manera estricta y segura, y la configuración debe estar más cerca del nivel público.
• En el lado de los datos, es mejor admitir múltiples protocolos o incluso protocolos personalizados de forma nativa, porque es necesario considerar los problemas causados por la migración de algunos sistemas históricos. Debido a la presencia de Sidecar, también es necesario considerar que su consumo de recursos sea manejable para que los costos puedan controlarse de manera efectiva. También se requiere escalabilidad para la personalización.
• Finalmente, dentro de todo el ecosistema del producto, tanto la comunidad como las reparaciones del producto deben coincidir con la velocidad de "respuesta oportuna".

Dado que tenemos requisitos y objetivos tan claros, el siguiente paso es implementar y construir una solución cercana a lo ideal.

Solución de Service Mesh basada en APISIX

Apache APISIX es una puerta de enlace API nativa de la nube dinámica, en tiempo real y de alto rendimiento que proporciona funciones avanzadas de gestión de tráfico, como equilibrio de carga, upstream dinámico, lanzamiento canario, interrupción de circuito, autenticación, observabilidad y más.

Cientos de empresas en todo el mundo ya utilizan Apache APISIX para manejar tráfico crítico para el negocio, cubriendo sectores como finanzas, Internet, manufactura, retail, telecomunicaciones, etc., como NASA, European Factory Platform, China Airlines, China Mobile, Tencent, Huawei, Weibo, Netease, Ke Holdings Inc., 360, Taikang, Nayuki Holdings Limited, etc. Por lo tanto, la solución de Service Mesh basada en APISIX tendrá una gran demanda no solo a nivel de uso, sino también al enfrentarse a diferentes sectores industriales.

La arquitectura de la solución actual de Service Mesh se basa en Istio como el plano de control y APISIX como el plano de datos.

Primero, elegimos Istio como el plano de control porque es la solución de Service Mesh más popular en la actualidad, y tiene una comunidad activa, lo que hace que casi todos los proveedores de nube principales admitan Istio, y también representa en cierta medida la demanda y dirección actual del mercado. Por lo tanto, en términos de la elección del plano de control, no desarrollamos un módulo propio. En su lugar, elegimos adoptar Istio, que es más adecuado y tiene una mayor tasa de aceptación.

El plano de datos es donde Apache APISIX puede aprovechar su ventaja. Como una puerta de enlace API nativa de la nube, ¿qué acciones ha tomado APISIX como el plano de datos de Istio en esta solución de Service Mesh?

Las personas familiarizadas con APISIX saben que APISIX utiliza etcd para el almacenamiento de datos. Pero si usamos APISIX como Sidecar, ¿de dónde proviene su configuración? Esta es la pregunta que debemos considerar. Si colocamos el componente etcd dentro de Sidecar, descubriremos que el consumo de recursos es muy alto y no lo suficientemente flexible.

Por lo tanto, en este proceso, primero agregamos un centro de configuración llamado xDS a APISIX para eliminar la necesidad de etcd, y luego introdujimos Amesh, como se muestra arriba, un programa Go compilado en una biblioteca de enlace dinámico que se carga cuando se inicia APISIX. Utiliza el protocolo xDS para interactuar con Istio. Luego, escribe la configuración obtenida en el centro de configuración xDS de APISIX, que genera reglas de enrutamiento específicas y finalmente utiliza APISIX para enrutar las solicitudes correspondientes.

Después de la configuración de la arquitectura anterior, se pueden lograr los siguientes resultados:

• Amesh y APISIX mantienen el mismo ciclo de vida y pueden activarse y desactivarse juntos.
• Gracias al soporte nativo de APISIX para xDS Discovery, los datos se convierten entre sí mediante el protocolo xDS, lo que resulta en un nivel de consumo de recursos controlado.
• Se puede utilizar CRD para extender rápidamente y de manera sencilla toda la solución, especialmente para características que aún no son compatibles con Istio. Por ejemplo, la configuración más rica de plugins en APISIX se realiza mediante CRD; al usar el controlador junto con Istio, se maximiza la escalabilidad de la solución de Service Mesh de Istio y APISIX.

Rendimiento Específico de la Solución

Mejora Significativa en el Rendimiento

Los datos siempre son la forma más intuitiva y efectiva de presentar un producto tecnológico. Utilizamos APISIX y Envoy como el plano de datos en la solución de Service Mesh, realizamos pruebas de estrés en varios escenarios con un volumen de hasta 5,000 rutas y finalmente presentamos la siguiente comparación de datos.

El escenario de prueba es "Coincidir la ruta número 3000 de 5000 rutas". Debido a la gran cantidad de escenarios de prueba, solo se describen a continuación las rutas que coinciden con la parte media, y también hay escenarios que coinciden con las rutas iniciales y finales. (Hay demasiados datos para mostrar, por lo que los siguientes datos son el resultado de la prueba con un volumen de 3000 rutas).

Como se puede ver en los datos anteriores, APISIX muestra una mejora de rendimiento de 5 veces en el nivel de QPS para la misma presión y la misma configuración de máquina. Además, en el nivel de latencia de solicitud, APISIX es más bajo que Envoy por un orden de magnitud, con APISIX en el rango de microsegundos y Envoy en el rango de milisegundos. Por supuesto, también se puede ver que en esta medición, el consumo de CPU de APISIX es solo del 50% cuando Envoy ya está funcionando a plena capacidad.

Reducción del Uso de Recursos

Cuando se inyecta Sidecar en la solución de Service Mesh, generalmente se consumen recursos adicionales. La solución basada en API puede reducir el consumo de recursos en un 60%. ¿Por qué es esto posible?

Primero, la configuración se distribuye según la demanda. Istio incluye algunas políticas de gestión de recursos de Sidecar según la demanda, como la segregación por espacio de nombres, pero este proceso impone una carga mental adicional y dificultades de gestión en las operaciones del usuario.

En segundo lugar, está la facilidad de comprensión de la configuración. Cuando configuras una ruta en Envoy, la información de enrutamiento que se muestra mediante Dump indica que ya hay miles en Envoy, mientras que en realidad no hay tantas, lo que tiene muchas implicaciones, como afectar la velocidad de inicio y hacer que algunas configuraciones sean voluminosas, aumentando así el uso de recursos.

Con APISIX, puedes evitar todos estos problemas. La configuración de APISIX es sencilla y clara, reduciendo los datos almacenados en la memoria y, combinado con su alto rendimiento, reduce el consumo de recursos de la CPU. El consumo de recursos de toda la solución se reduce en aproximadamente un 60%.

Bajo Costo de Aprendizaje y Alta Capacidad de Personalización

En primer lugar, como un proyecto de código abierto activo de la Apache Software Foundation, APISIX proporciona una gran cantidad de documentación y recursos de aprendizaje en la comunidad, lo que reduce el costo de aprendizaje para aquellos que desean comenzar con APISIX.

En segundo lugar, el código fuente de APISIX está basado en Lua, que es relativamente fácil de leer y entender, ya que es un lenguaje de scripting ligero, por lo que es más claro ver el código fuente de APISIX.

Finalmente, el desarrollo secundario basado en APISIX es muy fácil. Cuando deseas personalizar plugins para tu negocio, no solo se admite el lenguaje Lua nativo, sino que también puedes usar el Plugin Runner de APISIX para implementar desarrollo secundario en lenguajes más familiares como Python, Java, Go e incluso Wasm.

El poder ecológico de APISIX también se debe a la fuerte extensibilidad del producto.

APISIX en sí ofrece una amplia gama de plugins para seguridad, registro, observabilidad y más. Estos plugins se pueden utilizar al máximo cuando APISIX se usa como un componente tradicional de puerta de enlace. Sin embargo, cuando APISIX se usa junto con Istio en el plano de control para crear una malla de servicios, muchos recursos no están definidos en el plano de control de Istio. Entonces, ¿qué se puede hacer en este caso?

Ahí es donde entran los CRD personalizados. Por ejemplo, si queremos hacer un plugin de inyección de fallos, este plugin ya está disponible en APISIX, por lo que solo necesitamos configurar algunos parámetros adicionales aquí. Por supuesto, aquí solo es un ejemplo del plugin de inyección de fallos. También hay plugins de autenticación de identidad segura, limitación de tasa y otros plugins comunes en APISIX que se pueden acceder de esta manera para lograr un control granular.

El beneficio más inmediato de usar CRD de esta manera es que hace que la extensión sea más nativa, utilizando configuración declarativa para que sea más fácil de aceptar para los usuarios, sin invadir la configuración original de Istio para una compatibilidad perfecta. Otro beneficio es que los costos de migración son más bajos para los usuarios que ya utilizan soluciones de Istio.

En resumen, la solución de Service Mesh basada en APISIX es más fácil de usar y expandible para desarrolladores o usuarios, y tiene un excelente rendimiento y un rico soporte ecológico. Gracias a la capacidad del producto APISIX, también tiene un buen soporte a nivel de plugins y múltiples protocolos. Esperamos traerles la próxima versión de Service Mesh basada en APISIX a finales de este año. ¡Esperamos con ansias su llegada!

Perspectivas Futuras para la Solución de Service Mesh basada en APISIX

En retrospectiva, la solución de Service Mesh basada en APISIX ya está trabajando hacia los puntos críticos mencionados en el artículo anterior y se está acercando a la solución ideal de Service Mesh.

Con la solución de Service Mesh basada en APISIX, puedes ver que el tráfico ingresa desde el exterior a través de APISIX Ingress y se procesa a través de APISIX en el medio. En este proceso, APISIX Ingress maneja el tráfico norte-sur, y Amesh + Istio maneja el tráfico este-oeste.

Una arquitectura de implementación como esta puede aportar algún valor a nivel empresarial, como ahorro de costos y una pila tecnológica unificada, donde puedes replicar rápidamente capacidades comunes que se utilizaban dentro de las puertas de enlace tradicionales en Service Mesh. Esto permite una gestión unificada a nivel empresarial, controlando costos y reutilizando altamente la experiencia en la puerta de enlace, Ingress y Service Mesh.

En iteraciones posteriores, la solución de Service Mesh basada en APISIX continuará profundizándose, logrando direcciones planificadas como:

• Construir implementaciones de capacidades xRPC en conjunto con la funcionalidad de APISIX.
• Realizar soporte nativo de múltiples protocolos heterogéneos.
• Cubrir todo tipo de escenarios y configuraciones, incluyendo Istio, para reducir significativamente los costos de migración de los usuarios.

En conclusión, entre las tendencias tecnológicas actuales, Service Mesh está destinado a ser una tendencia popular en el futuro. Aunque varias soluciones aún no son perfectas, la situación general es una espiral ascendente. Por supuesto, Service Mesh basado en APISIX también se está moviendo hacia la solución ideal de Service Mesh que todos tienen en mente.