>_ DevTrendses

Idioma

Inicio

Lenguajes

Secciones

Frontend Backend Móvil DevOps AI / ML GameDev Blockchain Embebidos Seguridad
Java

Zilla Gateway conecta Apache Kafka y agentes de IA mediante una única configuración

Cualquiera que haya intentado enviar eventos desde Apache Kafka directamente al frontend o a clientes móviles conoce este dolor. Los navegadores no pueden trabajar con el protocolo binario de Kafka. Terminas escribiendo adaptadores de microservicios interminables, levantando puentes WebSocket o improvisando soluciones con Server-Sent Events. La situación se complica aún más cuando aparece el IoT con el protocolo MQTT cerca, y el negocio exige conectar agentes de IA mediante el MCP (Model Context Protocol) a esta infraestructura.

En lugar de un puñado de servidores proxy personalizados, los desarrolladores del equipo de Aklivity propusieron una única gateway llamada Zilla.

Diagrama de arquitectura de Zilla

Qué puede hacer Zilla

Esencialmente, Zilla combina dos roles. El primer rol es familiar: es una gateway orientada a eventos (Event Gateway). Acepta solicitudes entrantes sobre HTTP, WebSocket, gRPC o SSE y las traduce directamente a topics de Kafka o brokers MQTT sin escribir código del lado del servidor.

El segundo rol apareció con la actualización a la versión 2.0. Zilla aprendió a trabajar como una gateway MCP para modelos de lenguaje grandes y agentes autónomos. Si tu asistente de IA necesita herramientas de diferentes fuentes (APIs REST internas, topics de Kafka, servidores MCP externos), Zilla las agrega en un único endpoint gestionado.

Toda la magia se configura de forma declarativa a través de un único archivo zilla.yaml. Describes los bindings, reglas de enrutamiento, validación de esquemas y políticas de seguridad, y luego ejecutas el binario o el contenedor.

Cuatro características clave del proyecto

Reenvío directo de REST y WebSocket a topics de Kafka

Ya no necesitas escribir un backend en Go o Java solo para aceptar un HTTP POST y poner el payload en un topic. Zilla toma el cuerpo de la solicitud, lo valida contra el esquema y lo escribe en Kafka.

La lectura funciona de manera similar: el frontend abre una conexión SSE o WebSocket, y la gateway transmite mensajes desde las particiones directamente al código del cliente con soporte de caché.

Federación de herramientas para agentes de IA

En lugar de conectar un LLM a cinco servidores MCP diferentes con claves y formatos separados, apuntas el agente a la dirección de la gateway:

http://localhost:7114/mcp

Zilla agrupa automáticamente los toolkits disponibles a través de namespaces intuitivos:

github__create_pr
payments__refund
kafka__produce_message

El agente ve un catálogo unificado de funciones, y la gateway decide por sí misma dónde enviar la llamada: al API REST del sistema de pagos, a GitHub o a una cola de mensajes.

Control de contexto y carga diferida de herramientas

Cuando tienes decenas de herramientas, la ventana de contexto del modelo se llena rápidamente con descripciones de esquemas. Zilla divide las herramientas en "calientes" (eager) y "frías". El agente primero recibe una lista básica de capacidades, y las especificaciones detalladas se cargan solo cuando realmente se necesitan. Esto ahorra tokens y reduce la latencia de respuesta.

Guards integrados y validación de datos

La gateway valida las estructuras de datos entrantes y salientes contra esquemas JSON Schema, Avro y Protobuf. Si el modelo genera una llamada incorrecta o el cliente envía JSON malformado, la solicitud se bloquea a nivel de gateway antes de llegar al circuito interno.

Bajo el capó

La gateway está escrita en Java, pero la arquitectura difiere significativamente de las aplicaciones empresariales clásicas. Los desarrolladores buscaron reducir la sobrecarga de memoria y la latencia, por lo que aplicaron varias optimizaciones de bajo nivel:

  1. Generación de estructuras ligeras (flyweights) para trabajar con buffers binarios sin asignaciones de heap innecesarias.
  2. Vinculación de una conexión a un único worker durante toda la vida de la sesión, lo que elimina la sincronización costosa de hilos.
  3. Intercambio de frames entre streams a través de bindings mediante memoria compartida con soporte de back-pressure.
  4. Una capa de caché para Kafka que obtiene un registro del broker una vez y lo distribuye a miles de suscriptores.

Gracias a esto, Zilla prácticamente no añade latencia de red al hacer proxy de streams.

Inicio rápido

La forma más fácil de probar la gateway es a través de Docker Compose.

Si necesitas REST sobre Kafka:

git clone https://github.com/aklivity/zilla.git
cd zilla/examples
docker compose --project-directory http.kafka.crud up -d

Después del inicio, verificamos el envío de mensajes:

curl -X POST http://localhost:7114/items \
  -H 'Content-Type: application/json' \
  -d '{"name": "test-item", "price": 42.50}'

curl http://localhost:7114/items

Si estás experimentando con agentes de IA y el protocolo MCP:

docker compose --project-directory mcp.proxy up -d

La gateway levantará un único punto de entrada en el puerto 7114 con soporte de Streamable HTTP y expondrá métricas en el puerto 7190.

Matices y limitaciones

Al conocer el proyecto, hay un par de cosas que tener en cuenta.

Zilla tiene su propio modelo de configuración. Los archivos zilla.yaml resultan bastante detallados: necesitas entender en profundidad los conceptos de vaults, bindings, routes y pipelines. Si estás acostumbrado a configuraciones simples de Nginx, la sintaxis aquí llevará tiempo aprenderla.

El segundo punto se refiere a las licencias. La versión base se distribuye bajo la Aklivity Community License. Es gratuita para cualquier carga de trabajo interna y uso en producción, pero prohíbe vender Zilla como servicio independiente. Las funciones avanzadas como el almacenamiento de estado distribuido basado en Redis/Hazelcast o la autorización OAuth extendida se mueven a la versión comercial Zilla Plus.

¿Vale la pena probar?

Zilla aborda dos puntos débiles de integración a la vez. Elimina la escritura de código repetitivo alrededor de Kafka y trae orden al zoo de herramientas para agentes de IA.

El proyecto es especialmente útil si:

  • Estás construyendo un sistema orientado a eventos y quieres entregar datos a los clientes a través de protocolos web sin capas adicionales.
  • Estás desarrollando agentes de IA y estás cansado de administrar servidores MCP dispersos y claves de API.
  • Tu infraestructura tiene MQTT y Kafka coexistiendo, requiriendo un único punto de entrada y monitoreo.

Puedes comenzar con ejemplos listos para usar en el repositorio: hay escenarios claros para la mayoría de las tareas típicas.

Proyectos relacionados