Zilla Gateway relie Apache Kafka et les agents IA via une configuration unique

Quiconque a tenté de pousser des événements depuis Apache Kafka directement vers le frontend ou les clients mobiles connaît cette galère. Les navigateurs ne peuvent pas travailler avec le protocole binaire de Kafka. Vous vous retrouvez à écrire d'interminables adaptateurs de microservices, à faire tourner des ponts WebSocket, ou à bricoler des solutions de fortune avec des Server-Sent Events. La situation devient encore plus complexe lorsque l'IoT avec le protocole MQTT apparaît à proximité, et que le métier exige de connecter des agents IA via le MCP (Model Context Protocol) à cette infrastructure.

Au lieu d'une multitude de serveurs proxy personnalisés, les développeurs de l'équipe Aklivity ont proposé une passerelle unique appelée Zilla.

Ce que Zilla peut faire

Essentiellement, Zilla combine deux rôles. Le premier rôle est familier : c'est une passerelle événementielle (Event Gateway). Elle accepte les requêtes entrantes via HTTP, WebSocket, gRPC ou SSE et les traduit directement vers les topics Kafka ou les brokers MQTT sans écrire de code côté serveur.

Le deuxième rôle est apparu avec la mise à jour vers la version 2.0. Zilla a appris à fonctionner comme une passerelle MCP pour les grands modèles de langage et les agents autonomes. Si votre assistant IA a besoin d'outils来自 différentes sources (API REST internes, topics Kafka, serveurs MCP externes), Zilla les agrège en un point d'accès géré unique.

Toute la magie est configurée de manière déclarative via un fichier zilla.yaml unique. Vous décrivez les liaisons, les règles de routage, la validation de schéma et les politiques de sécurité, puis vous lancez le binaire ou le conteneur.

Quatre fonctionnalités clés du projet

Redirection directe REST et WebSocket vers les topics Kafka

Vous n'avez plus besoin d'écrire un backend en Go ou Java juste pour accepter un HTTP POST et mettre le payload dans un topic. Zilla prend le corps de la requête, le valide contre le schéma et l'écrit dans Kafka.

La lecture fonctionne de manière similaire : le frontend ouvre une connexion SSE ou WebSocket, et la passerelle diffuse les messages des partitions directement vers le code client avec support du cache.

Fédération d'outils pour les agents IA

Au lieu de connecter un LLM à cinq serveurs MCP différents avec des clés et des formats séparés, vous pointez l'agent vers l'adresse de la passerelle :

http://localhost:7114/mcp

Zilla regroupe automatiquement les toolkits disponibles via des espaces de noms intuitifs :

github__create_pr
payments__refund
kafka__produce_message

L'agent voit un catalogue unifié de fonctions, et la passerelle décide elle-même où envoyer l'appel : vers l'API REST du système de paiement, vers GitHub, ou vers une file de messages.

Contrôle du contexte et chargement paresseux des outils

Lorsque vous avez des dizaines d'outils, la fenêtre de contexte du modèle se remplit rapidement avec les descriptions de schéma. Zilla divise les outils en « chauds » (impatients) et « froids ». L'agent reçoit d'abord une liste basique des capacités, et les spécifications détaillées ne sont extraites que lorsqu'elles sont réellement nécessaires. Cela économise des tokens et réduit la latence des réponses.

Gardes intégrés et validation des données

La passerelle valide les structures de données entrantes et sortantes contre les schémas JSON Schema, Avro et Protobuf. Si le modèle génère un appel incorrect ou si le client envoie du JSON malformé, la requête est bloquée au niveau de la passerelle avant d'atteindre le circuit interne.

Sous le capot

La passerelle est écrite en Java, mais l'architecture diffère significativement des applications d'entreprise classiques. Les développeurs ont cherché à réduire la surcharge mémoire et la latence, ils ont donc appliqué plusieurs optimisations de bas niveau :

1. Génération de structures légères (flyweights) pour travailler avec des buffers binaires sans allocations heap inutiles.
2. Liaison d'une connexion à un seul worker pour toute la durée de la session, ce qui élimine la synchronisation coûteuse des threads.
3. Échange de frames entre flux à travers les liaisons via une mémoire partagée avec support du back-pressure.
4. Une couche de cache pour Kafka qui récupère un enregistrement du broker une fois et le distribue à des milliers d'abonnés.

Grâce à cela, Zilla n'ajoute pratiquement aucune latence réseau lors du proxying des flux.

Démarrage rapide

Le moyen le plus simple d'essayer la passerelle est via Docker Compose.

Si vous avez besoin de REST sur Kafka :

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

Après le démarrage, nous vérifions l'envoi des messages :

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 vous expérimentez avec les agents IA et le protocole MCP :

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

La passerelle va démarrer un point d'entrée unique sur le port 7114 avec le support Streamable HTTP et exposer les métriques sur le port 7.

Nuances et limitations

Lors de la découverte du projet, il y a quelques points à garder à l'esprit.

Zilla a son propre modèle de configuration. Les fichiers zilla.yaml s'avèrent assez détaillés : vous devez comprendre en détail les concepts de vaults, liaisons, routes et pipelines. Si vous êtes habitué aux configs Nginx simples, la syntaxe ici demandera du temps pour être maîtrisée.

Le deuxième point concerne la licence. La version de base est distribuée sous l'Aklivity Community License. Elle est gratuite pour toute charge de travail interne et utilisation en production, mais interdit la vente de Zilla en tant que service autonome. Les fonctionnalités avancées comme le stockage d'état distribué basé sur Redis/Hazelcast ou l'autorisation OAuth étendue sont déplacées vers la version commerciale Zilla Plus.

Cela vaut-il la peine d'essayer

Zilla aborde deux points douloureux de l'intégration à la fois. Il élimine l'écriture de code boilerplate autour de Kafka et apporte de l'ordre au zoo d'outils pour les agents IA.

Le projet est particulièrement utile si :

• Vous construisez un système événementiel et souhaitez livrer des données aux clients via des protocoles web sans couches supplémentaires.
• Vous développez des agents IA et en avez assez d'administrer des serveurs MCP dispersés et des clés API.
• Votre infrastructure a MQTT et Kafka coexistant, nécessitant un point d'entrée unique et une surveillance.

Vous pouvez commencer avec les exemples prêts à l'emploi dans le dépôt : il y a des scénarios clairs pour la plupart des tâches typiques.