Zilla Gateway łączy Apache Kafka z agentami AI za pomocą jednej konfiguracji

Każdy, kto próbował przesyłać zdarzenia z Apache Kafka bezpośrednio do frontendu lub klientów mobilnych, zna ten ból. Przeglądarki nie mogą pracować z binarnym protokołem Kafki. Kończysz na pisaniu niezliczonych adapterów mikroserwisów, uruchamianiu mostów WebSocket lub składaniu obejść z Server-Sent Events. Sytuacja staje się jeszcze bardziej skomplikowana, gdy w pobliżu pojawia się IoT z protokołem MQTT, a biznes wymaga podłączenia agentów AI przez MCP (Model Context Protocol) do tej infrastruktury.

Zamiast stosu niestandardowych serwerów proxy, deweloperzy z zespołu Aklivity zaproponowali jedną bramę o nazwie Zilla.

Co potrafi Zilla

Zasadniczo Zilla łączy dwie role. Pierwsza rola jest znajoma: to brama sterowana zdarzeniami (Event Gateway). Przyjmuje przychodzące żądania przez HTTP, WebSocket, gRPC lub SSE i tłumaczy je bezpośrednio na tematy Kafki lub brokerów MQTT bez pisania kodu po stronie serwera.

Druga rola pojawiła się wraz z aktualizacją do wersji 2.0. Zilla nauczyła się pracować jako brama MCP dla dużych modeli językowych i autonomicznych agentów. Jeśli Twój asystent AI potrzebuje narzędzi z różnych źródeł (wewnętrzne REST API, tematy Kafki, zewnętrzne serwery MCP), Zilla agreguje je w jeden zarządzany punkt końcowy.

Cała magia jest konfigurowana deklaratywnie przez jeden plik zilla.yaml. Opisujesz powiązania, reguły routingu, walidację schematów i zasady bezpieczeństwa, a następnie uruchamiasz binarkę lub kontener.

Cztery kluczowe funkcje projektu

Bezpośrednie przekazywanie REST i WebSocket do tematów Kafki

Nie musisz już pisać backendu w Go czy Javie tylko po to, aby przyjąć HTTP POST i umieścić payload w temacie. Zilla pobiera ciało żądania, waliduje je względem schematu i zapisuje do Kafki.

Odczyt działa podobnie: frontend otwiera połączenie SSE lub WebSocket, a brama strumieniuje wiadomości z partycji bezpośrednio do kodu klienta z obsługą cache'owania.

Federacja narzędzi dla agentów AI

Zamiast podłączać LLM do pięciu różnych serwerów MCP z osobnymi kluczami i formatami, wskazujesz agentowi adres bramy:

http://localhost:7114/mcp

Zilla automatycznie grupuje dostępne zestawy narzędzi przez intuicyjne przestrzenie nazw:

github__create_pr
payments__refund
kafka__produce_message

Agent widzi ujednolicony katalog funkcji, a brama sama decyduje, gdzie wysłać wywołanie: do systemu płatności REST API, do GitHuba czy do kolejki wiadomości.

Kontrola kontekstu i leniwe ładowanie narzędzi

Gdy masz dziesiątki narzędzi, okno kontekstowe modelu szybko wypełnia się opisami schematów. Zilla dzieli narzędzia na „gorące" (chętne) i „zimne". Agent najpierw otrzymuje podstawową listę możliwości, a szczegółowe specyfikacje są pobierane dopiero wtedy, gdy są faktycznie potrzebne. Oszczędza to tokeny i zmniejsza opóźnienia odpowiedzi.

Wbudowane straże i walidacja danych

Brama waliduje przychodzące i wychodzące struktury danych względem schematów JSON Schema, Avro i Protobuf. Jeśli model wygeneruje nieprawidłowe wywołanie lub klient wyśle źle sformatowany JSON, żądanie jest blokowane na poziomie bramy przed dotarciem do wewnętrznego obwodu.

Pod maską

Brama jest napisana w Javie, ale architektura znacząco różni się od klasycznych aplikacji enterprise. Deweloperzy dążyli do zmniejszenia narzutu pamięci i opóźnień, więc zastosowali kilka niskopoziomowych optymalizacji:

1. Generowanie lekkich struktur (flyweights) do pracy z buforami binarnymi bez niepotrzebnych alokacji na stercie.
2. Przywiązanie połączenia do pojedynczego workera na cały czas życia sesji, co eliminuje kosztowną synchronizację wątków.
3. Wymiana ramek między strumieniami przez powiązania poprzez współdzieloną pamięć z obsługą back-pressure.
4. Warstwa cache'owania dla Kafki, która pobiera rekord z brokera raz i dystrybuuje go do tysięcy subskrybentów.

Dzięki temu Zilla praktycznie nie dodaje opóźnień sieciowych podczas proxyfikacji strumieni.

Szybki start

Najłatwiejszy sposób na wypróbowanie bramy to Docker Compose.

Jeśli potrzebujesz REST przez Kafkę:

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

Po uruchomieniu weryfikujemy wysyłanie wiadomości:

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

curl http://localhost:7114/items

Jeśli eksperymentujesz z agentami AI i protokołem MCP:

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

Brama uruchomi jeden punkt wejścia na porcie 7114 z obsługą Streamable HTTP i udostępni metryki na porcie 7190.

Niuansy i ograniczenia

Przy zapoznawaniu się z projektem należy pamiętać o kilku kwestiach.

Zilla ma własny model konfiguracji. Pliki zilla.yaml są dość szczegółowe: musisz zrozumieć koncepcje vaultów, powiązań, tras i pipeline'ów. Jeśli jesteś przyzwyczajony do prostych konfiguracji Nginx, składnia tutaj wymaga czasu na naukę.

Drugą kwestią jest licencjonowanie. Wersja bazowa jest dystrybuowana na licencji Aklivity Community License. Jest darmowa dla dowolnych wewnętrznych obciążeń i użytku produkcyjnego, ale zabrania sprzedaży Zilla jako samodzielnej usługi. Zaawansowane funkcje, takie jak rozproszona pamięć stanu oparta na Redis/Hazelcast czy rozszerzona autoryzacja OAuth, zostały przeniesione do komercyjnej wersji Zilla Plus.

Czy warto wypróbować

Zilla rozwiązuje jednocześnie dwa problemy integracyjne. Eliminuje pisanie kodu szablonowego wokół Kafki i wprowadza porządek do zoo narzędzi dla agentów AI.

Projekt jest szczególnie przydatny, jeśli:

• Budujesz system sterowany zdarzeniami i chcesz dostarczać dane klientom przez protokoły webowe bez dodatkowych warstw.
• Rozwijasz agentów AI i masz dość zarządzania rozproszonymi serwerami MCP i kluczami API.
• Twoja infrastruktura ma współistniejące MQTT i Kafkę, wymagające jednego punktu wejścia i monitoringu.

Możesz zacząć od gotowych przykładów w repozytorium: są tam jasne scenariusze dla większości typowych zadań.