Zilla Gateway verbindet Apache Kafka und KI-Agenten über eine einzige Konfiguration

Jeder, der versucht hat, Events direkt von Apache Kafka an Frontend- oder Mobile-Clients zu senden, kennt dieses Problem. Browser können mit Kafkas binärem Protokoll nicht arbeiten. Man endet damit, endlose Microservice-Adapter zu schreiben, WebSocket-Bridges hochzufahren oder mit Server-Sent Events behelfsmäßige Lösungen zusammenzubasteln. Die Situation wird noch komplizierter, wenn IoT mit dem MQTT-Protokoll hinzukommt und das Unternehmen verlangt, KI-Agenten über das MCP (Model Context Protocol) an diese Infrastruktur anzubinden.

Statt einer Reihe von benutzerdefinierten Proxy-Servern haben die Entwickler vom Aklivity-Team ein einzelnes Gateway namens Zilla vorgeschlagen.

Was Zilla kann

Im Wesentlichen kombiniert Zilla zwei Rollen. Die erste Rolle ist bekannt: Es ist ein Event-Driven Gateway (Event Gateway). Es nimmt eingehende Anfragen über HTTP, WebSocket, gRPC oder SSE entgegen und übersetzt diese direkt in Kafka-Topics oder MQTT-Broker, ohne serverseitigen Code zu schreiben.

Die zweite Rolle kam mit dem Update auf Version 2.0 hinzu. Zilla lernte, als MCP Gateway für große Sprachmodelle und autonome Agenten zu arbeiten. Wenn Ihr KI-Assistent Tools aus verschiedenen Quellen benötigt (interne REST-APIs, Kafka-Topics, externe MCP-Server), aggregiert Zilla diese zu einem einzigen verwalteten Endpunkt.

Die gesamte Magie wird deklarativ über eine einzige zilla.yaml-Datei konfiguriert. Sie beschreiben Bindings, Routing-Regeln, Schema-Validierung und Sicherheitsrichtlinien, dann führen Sie das Binary oder den Container aus.

Vier Hauptfunktionen des Projekts

Direkte REST- und WebSocket-Weiterleitung zu Kafka-Topics

Sie müssen keinen Backend in Go oder Java schreiben, nur um einen HTTP POST entgegenzunehmen und die Payload in ein Topic zu schreiben. Zilla nimmt den Request-Body, validiert ihn gegen das Schema und schreibt ihn in Kafka.

Das Lesen funktioniert ähnlich: Das Frontend öffnet eine SSE-Verbindung oder ein WebSocket, und das Gateway streamt Nachrichten aus Partitionen direkt an den Client-Code mit Caching-Unterstützung.

Tool-Föderation für KI-Agenten

Statt einen LLM mit fünf verschiedenen MCP-Servern mit separaten Keys und Formaten zu verbinden, zeigen Sie dem Agenten auf die Gateway-Adresse:

http://localhost:7114/mcp

Zilla gruppiert automatisch verfügbare Toolkits durch intuitive Namespaces:

github__create_pr
payments__refund
kafka__produce_message

Der Agent sieht einen einheitlichen Katalog von Funktionen, und das Gateway entscheidet selbst, wohin der Aufruf gesendet wird: an die REST-API des Zahlungssystems, zu GitHub oder an eine Message-Queue.

Kontextkontrolle und verzögertes Laden von Tools

Wenn Sie Dutzende von Tools haben, füllt sich das Kontextfenster des Modells schnell mit Schema-Beschreibungen. Zilla teilt Tools in „heiße" (eager) und „kalte" (cold) ein. Der Agent erhält zunächst eine grundlegende Liste der Fähigkeiten, und detaillierte Spezifikationen werden nur bei tatsächlichem Bedarf geladen. Dies spart Tokens und reduziert die Antwortlatenz.

Integrierte Guards und Datenvalidierung

Das Gateway validiert eingehende und ausgehende Datenstrukturen gegen JSON-Schema-, Avro- und Protobuf-Schemata. Wenn das Modell einen fehlerhaften Aufruf generiert oder der Client fehlerhaftes JSON sendet, wird die Anfrage auf Gateway-Ebene blockiert, bevor sie den internen Schaltkreis erreicht.

Unter der Haube

Das Gateway ist in Java geschrieben, aber die Architektur unterscheidet sich erheblich von klassischen Enterprise-Anwendungen. Die Entwickler strebten eine Reduzierung des Speicheroverheads und der Latenz an, daher haben sie mehrere Low-Level-Optimierungen angewendet:

1. Generierung von leichtgewichtigen Strukturen (Flyweights) für die Arbeit mit binären Buffern ohne unnötige Heap-Allokationen.
2. Bindung einer Verbindung an einen einzelnen Worker für die gesamte Sitzungsdauer, was teure Thread-Synchronisation eliminiert.
3. Frame-Austausch zwischen Streams über Bindings durch Shared Memory mit Back-Pressure-Unterstützung.
4. Eine Caching-Schicht für Kafka, die einen Record einmal vom Broker abruft und an Tausende von Abonnenten verteilt.

Dadurch fügt Zilla beim Proxen von Streams praktisch keine Netzwerklatenz hinzu.

Schnellstart

Der einfachste Weg, das Gateway auszuprobieren, ist über Docker Compose.

Wenn Sie REST über Kafka benötigen:

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

Nach dem Start verifizieren wir das Senden von Nachrichten:

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

curl http://localhost:7114/items

Wenn Sie mit KI-Agenten und dem MCP-Protokoll experimentieren:

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

Das Gateway startet einen einzelnen Entry-Point auf Port 7114 mit Streamable-HTTP-Unterstützung und exponiert Metriken auf Port 7190.

Nuancen und Einschränkungen

Bei der Bekanntschaft mit dem Projekt gibt es einige Dinge zu beachten.

Zilla hat sein eigenes Konfigurationsmodell. Die zilla.yaml-Dateien erweisen sich als ziemlich detailliert: Sie müssen die Konzepte von Vaults, Bindings, Routes und Pipelines im Detail verstehen. Wenn Sie einfache Nginx-Konfigurationen gewohnt sind, wird die Syntax hier Zeit zum Lernen erfordern.

Der zweite Punkt betrifft die Lizenzierung. Die Basisversion wird unter der Aklivity Community License vertrieben. Sie ist kostenlos für beliebige interne Workloads und Produktionsnutzung, verbietet jedoch den Verkauf von Zilla als eigenständigen Service. Erweiterte Funktionen wie verteilte Zustandsspeicherung basierend auf Redis/Hazelcast oder erweiterte OAuth-Autorisierung sind in die kommerzielle Version Zilla Plus verschoben.

Lohnt es sich, es zu versuchen

Zilla adressiert zwei Integrations-Schmerzpunkte gleichzeitig. Es eliminiert das Schreiben von Boilerplate-Code rund um Kafka und bringt Ordnung in den Zoo von Tools für KI-Agenten.

Das Projekt ist besonders nützlich, wenn:

• Sie ein Event-Driven-System aufbauen und Daten über Web-Protokolle an Clients liefern möchten, ohne zusätzliche Schichten.
• Sie KI-Agenten entwickeln und es leid sind, verstreute MCP-Server und API-Keys zu verwalten.
• Ihre Infrastruktur MQTT und Kafka koexistieren hat, die einen einzelnen Entry-Point und Monitoring erfordern.

Sie können mit fertigen Beispielen im Repository beginnen: Es gibt klare Szenarien für die meisten typischen Aufgaben.