Шлюз Zilla связывает Apache Kafka и AI-агентов через один конфиг

Каждый, кто пробовал отдавать события из Apache Kafka напрямую во фронтенд или мобильные клиенты, знает эту боль. Браузеры не умеют работать с бинарным протоколом Кафки. Приходится писать бесконечные микросервисы-адаптеры, поднимать WebSocket-мосты или городить костыли с Server-Sent Events. Ситуация усложняется, когда рядом появляется IoT с протоколом MQTT, а бизнес требует подключить к этой инфраструктуре еще и AI-агентов через протокол MCP (Model Context Protocol).

Вместо пачки самописных прокси-серверов разработчики из команды Aklivity предложили единый шлюз Zilla.

Схема архитектуры Zilla

Что умеет Zilla

По своей сути Zilla объединяет две роли. Первая роль привычна: это событийно-ориентированный шлюз (Event Gateway). Он принимает входящие запросы по HTTP, WebSocket, gRPC или SSE и транслирует их напрямую в топики Kafka или брокеры MQTT без написания серверного кода.

Вторая роль появилась с обновлением до версии 2.0. Zilla научилась работать как MCP Gateway для больших языковых моделей и автономных агентов. Если вашему AI-ассистенту нужны инструменты из разных источников (внутренние REST API, топики Kafka, внешние MCP-серверы), Zilla собирает их в один управляемый эндпоинт.

Вся магия настраивается декларативно через один файл zilla.yaml. Вы описываете биндинги, правила маршрутизации, валидацию схем и политики безопасности, после чего запускаете бинарник или контейнер.

Четыре главные возможности проекта

Прямой проброс REST и WebSocket в топики Kafka

Вам больше не нужно писать бэкенд на Go или Java только для того, чтобы принять HTTP POST и положить payload в топик. Zilla берет тело запроса, валидирует его по схеме и записывает в Kafka.

Аналогично работает чтение: фронтенд открывает SSE-соединение или WebSocket, а шлюз стримит сообщения из партиций прямо в клиентский код с поддержкой кэширования.

Федерация инструментов для AI-агентов

Вместо того чтобы подключать LLM к пяти разным MCP-серверам с отдельными ключами и форматами, вы направляете агента на адрес шлюза:

http://localhost:7114/mcp

Zilla автоматически группирует доступные тулкиты через понятные пространства имен:

github__create_pr
payments__refund
kafka__produce_message

Агент видит единый каталог функций, а шлюз сам решает, куда отправить вызов: в REST API платежки, в GitHub или в очередь сообщений.

Контроль контекста и ленивая загрузка тулов

Когда у вас десятки инструментов, окно контекста модели быстро забивается описаниями схем. Zilla разделяет тулы на «горячие» (eager) и «холодные» (cold). Агент сначала получает базовый список возможностей, а детальные спецификации подтягивает только при реальной необходимости. Это экономит токены и снижает задержку ответов.

Встроенные гарды и валидация данных

Шлюз проверяет входящие и исходящие структуры данных по схемам JSON Schema, Avro и Protobuf. Если модель сгенерировала некорректный вызов или клиент прислал битый JSON, запрос отсекается на уровне шлюза до попадания во внутренний контур.

Что под капотом

Шлюз написан на Java, но архитектура сильно отличается от классических enterprise-приложений. Разработчики стремились снизить оверхед по памяти и задержкам, поэтому применили несколько низкоуровневых оптимизаций:

Генерация легковесных структур (flyweights) для работы с бинарными буферами без лишних аллокаций в куче (heap).
Привязка соединения к одному воркеру на все время жизни сессии, что исключает дорогую межпоточную синхронизацию.
Обмен кадрами потоков между биндингами через общую память с поддержкой back-pressure.
Кэширующий слой для Kafka, который забирает запись из брокера один раз и раздает ее тысячам подписчиков.

Благодаря этому Zilla практически не добавляет сетевых задержек при проксировании стримов.

Быстрый старт

Проще всего пощупать шлюз в работе через Docker Compose.

Если вам нужен REST поверх Kafka:

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

После старта проверяем отправку сообщения:

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

curl http://localhost:7114/items

Если же вы экспериментируете с AI-агентами и протоколом MCP:

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

Шлюз поднимет единую точку входа на порту 7114 с поддержкой Streamable HTTP и отдаст метрики на порту 7190.

Нюансы и ограничения

При знакомстве с проектом стоит учитывать пару моментов.

У Zilla своя собственная модель конфигурации. Файлы zilla.yaml получаются весьма подробными: нужно в деталях понимать концепции vaults, bindings, routes и pipelines. Если вы привыкли к простым конфигам Nginx, здешний синтаксис потребует времени на освоение.

Второй момент касается лицензирования. Базовая версия распространяется под Aklivity Community License. Она бесплатна для любых внутренних нагрузок и продакшена, но запрещает продавать Zilla как отдельный сервис. Продвинутые фичи вроде распределенного хранилища состояний на базе Redis/Hazelcast или расширенной авторизации OAuth вынесены в коммерческую версию Zilla Plus.

Стоит ли пробовать

Zilla закрывает сразу две неприятные проблемы интеграции. Она избавляет от написания шаблонного кода вокруг Kafka и наводит порядок в зоопарке инструментов для AI-агентов.

Проект особенно пригодится, если:

Вы строите событийно-ориентированную систему и хотите отдавать данные клиентам по веб-протоколам без лишних прослоек.
Вы разрабатываете AI-агентов и устали администрировать разрозненные MCP-серверы и API-ключи.
В вашей инфраструктуре сосуществуют MQTT и Kafka, требуя единой точки входа и мониторинга.

Начать можно с готовых примеров в репозитории: там есть понятные сценарии под большинство типовых задач.