xRPC Will Be Released, Get More Details About APISIX Ecosystem
API7.ai
January 21, 2021
A medida que los escenarios y requisitos empresariales se vuelven más complejos y diversos, están surgiendo cada vez más estándares y protocolos. Apache APISIX, como un proyecto de código abierto de primer nivel de la Fundación Apache, ha participado activamente y ha promovido la expansión de aspectos relacionados con su ecosistema.
En este artículo, les presentaremos ejemplos del próximo marco xRPC de Apache APISIX y los complementos multilingües desde dos perspectivas: proxy multiprotocolo y soporte multilingüe.
Proxy Multiprotocolo
En Apache APISIX, cada solicitud corresponde a un objeto Route. Actualmente, existen dos escenarios principales de proxy en Apache APISIX.
El primero es el proxy de protocolo HTTP, que actualmente es el proxy de solicitudes más utilizado en APISIX. Basado en el proxy de protocolo HTTP, Apache APISIX ha implementado docenas de capacidades de gestión de tráfico, como control de flujo granular, seguridad y observabilidad.
El segundo es un proxy dinámico y balanceo de carga basado en TCP y UDP, que proporciona las capacidades más básicas de admisión de tráfico y registro de nivel de enlace. Este modelo de proxy puede manejar cualquier solicitud basada en protocolos TCP/UDP, como MySQL, Redis, Mongo o DNS. Sin embargo, dado que es un proxy basado en TCP/UDP sin protocolos de capa de aplicación superior, solo puede obtener información básica sobre el cuaternión, por lo que es un poco más débil en términos de escalabilidad.
¿Por qué xRPC?
Debido a las limitaciones de Stream Route en términos de proxies de protocolo, y nuestro deseo de admitir más protocolos de capa de aplicación en APISIX para servir a más usuarios y escenarios de aplicación, nació el marco xRPC.
El marco xRPC facilita mucho la extensión de capacidades de protocolo, tanto para protocolos de datos específicos como privados, con granularidad precisa y control de nivel 7 similar a los proxies de protocolo HTTP, como observabilidad a nivel de solicitud, control de acceso avanzado y políticas de proxy.
¿Qué es xRPC?
xRPC literalmente significa que X es una representación abstracta de un recurso de protocolo. Y RPC es lo que consideramos como el despacho de todos los recursos que pasan por la puerta de enlace como un proceso, es decir, es un marco de extensión de protocolo. Por lo tanto, en términos de posicionamiento, xRPC es un marco base en lugar de una implementación de un protocolo específico.
Como se puede ver en la arquitectura anterior, xRPC es un marco basado en extensiones de APISIX Core. Sobre este marco, los usuarios pueden implementar diferentes protocolos de capa de aplicación, como Redis, MySQL, Mongo y Postgres. Sobre los diferentes protocolos, se pueden abstraer algunos factores comunes e implementar capacidades relacionadas con complementos para que diferentes protocolos puedan compartir estas capacidades.
Por lo tanto, el papel principal de xRPC se puede resumir como: proporcionar acceso a protocolos de capa de aplicación estandarizados, admitir el intercambio de capacidades entre protocolos y permitir a los usuarios obtener la capacidad de extender protocolos personalizados.
Ejemplos de Escenarios de Aplicación
Con el marco de protocolo xRPC en su lugar, ¿qué escenarios puede abordar? Aquí hay algunos ejemplos.
- Ejemplo 1: Redis no admite TLS en versiones anteriores. Si hay múltiples versiones de Redis en nuestro sistema, y no podemos actualizar Redis en producción por algunas razones, pero necesitamos agregar capacidad TLS. En este caso, podemos usar el Protocolo Redis basado en xPRC para resolver la situación anterior.
- Ejemplo 2: Cuando queremos limitar la frecuencia de ciertas IPs o llamantes y queremos visualizar la frecuencia de cada fuente de llamada, lo cual Redis no admite. Esto se resuelve perfectamente usando el Protocolo Redis, que es extendido por xRPC.
- Ejemplo 3: Si deseas usar MySQL para habilitar temporalmente la función de consulta lenta, solo necesitas acceder al Protocolo MySQL y configurar la política relevante en APISIX, lo que te ahorra el paso tedioso de iniciar sesión en la instancia máquina por máquina.
Por supuesto, hay muchos escenarios de aplicación similares, y esperamos que después del lanzamiento de la función, puedas experimentar y practicar más en la aplicación real. El proceso de invocación de xPRC se muestra en el siguiente diagrama.
Una vez que los servicios upstream son asumidos por Apache APISIX, los diferentes servicios de aplicación upstream pueden gestionarse de manera unificada. Funciones como registro, monitoreo, seguridad y solución de problemas pueden lograrse a través de un conjunto estandarizado de políticas.
Fases de Implementación Planificadas
El diseño actual del marco xRPC de Apache APISIX se divide inicialmente en 5 fases.
- Fase 1: Lectura de datos y decodificación de protocolo.
- Fase 2: Fase de acceso. Proporciona la función de acceso a complementos, que puede realizar escenarios de demanda de seguridad, control de flujo y acceso.
- Fase 3: Reenvío de datos de proxy y balanceo de carga. Proporciona soporte de acceso para políticas y algoritmos de balanceo de carga personalizados.
- Fase 4: Envío de datos y codificación de protocolo.
- Fase 5: Fase de registro. Proporciona acceso a complementos para realizar escenarios de registro y logging.
Ecosistema Multilingüe
Para satisfacer la base de lenguajes de computación cada vez más rica y grande, crear soporte de código para entornos multilingües se ha convertido en el primer umbral para enfrentar el desarrollo tecnológico futuro. Apache APISIX también ha realizado muchas exploraciones y prácticas en el camino del desarrollo multilingüe.
Por ejemplo, recientemente ha implementado soporte para WebAssembly. Para detalles y características, consulta el artículo "Apache APISIX Abraza el Ecosistema WASM". Por supuesto, el soporte para WASM en Apache APISIX sigue siendo experimental, y continuaremos mejorando el soporte para WASM en el futuro. Si estás interesado en este proyecto, no dudes en contribuir al proyecto wasm-nginx-module.
Mientras tanto, Apache APISIX ya admite múltiples lenguajes de desarrollo a través del "xPluginRunner Multilanguage Plugin Runtime" antes de implementar el soporte para WASM. Es decir, al desarrollar complementos de APISIX, los usuarios pueden escribir y extender complementos de APISIX no solo con código Lua, que es compatible de forma nativa con APISIX, sino también con sus propios lenguajes familiares, como Go, Java y Python.
xPluginRunner
La implementación de xPluginRunner se muestra en la figura anterior. Todo el proceso de comunicación es "antes" y "después" de la ejecución de los complementos integrados, APISIX iniciará solicitudes RPC locales al entorno de ejecución de complementos de cada lenguaje. En el runner de complementos, se implementa el cálculo y el procesamiento de políticas dentro de cada complemento, y finalmente se responde a APISIX para la toma de decisiones posteriores basadas en el resultado de la respuesta.
El xPluginRunner sirve como un puente para la comunicación con Apache APISIX, y principalmente implementa el análisis de protocolos de datos privados y la encapsulación y desencapsulación de mensajes RPC.
Actualmente, la solución xPluginRunner de Apache APISIX está en una etapa relativamente estable, y sabemos por los comentarios de la comunidad que algunas empresas han comenzado a probarla en entornos de producción. Si estás interesado en este proyecto, también eres bienvenido a participar en varios proyectos de complementos de lenguajes de desarrollo.
Finalmente, te mostraremos cómo desarrollar complementos de APISIX basados en Java Plugin Runner con un ejemplo simple de Java.
Ejemplo de Java Plugin Runner
En primer lugar, al desarrollar el complemento, necesitamos implementar la Interfaz de PluginFilter. El método name en la Interfaz se utiliza principalmente para identificar y extraer el nombre del complemento, y el método filter se utiliza para filtrar la solicitud (es decir, ejecutar la lógica principal del complemento).
Un punto adicional a tener en cuenta es que los parámetros request y response que aparecen en el código anterior tienen lógica fija en el Runner (todos los Runners aplican):
- Si deseas que la solicitud continúe siendo reenviada y solo hacer algunas configuraciones de políticas (como reescribir los parámetros de la solicitud, encabezados, etc.), simplemente puedes manipular el objeto
request. - Si deseas terminar la solicitud, puedes hacerlo con el objeto
response(por ejemplo, establecer el cuerpo de la respuesta, encabezados de respuesta, códigos de estado, etc.).
APISIX terminará la solicitud actual tan pronto como detecte que el objeto response en el Runner ha sido manipulado.
Una vez que el desarrollo del complemento esté completado, es hora de practicar la aplicación en APISIX.
Primero, compila Runner y los complementos en el proyecto en paquetes jar y configura la ruta absoluta de los paquetes jar en el archivo de configuración principal de APISIX de la siguiente manera.
Finalmente, reinicia Apache APISIX y estarás listo para las sesiones de configuración de enrutamiento y complementos y validación de solicitudes.
Resumen
Este artículo te trae el próximo lanzamiento del marco xRPC para Apache APISIX y detalles relacionados, así como una demostración detallada de Apache APISIX en el soporte de desarrollo multilingüe.
El artículo también muestra los detalles del soporte de desarrollo multilingüe de Apache APISIX. Muestra los esfuerzos orientados al ecosistema de Apache APISIX desde ambas perspectivas: proxy multiprotocolo y soporte multilingüe.
No dudes en iniciar una discusión en GitHub Discussions o comunicarte a través de la lista de correo.