Zilla Gateway conecta Apache Kafka e Agentes de IA via Configuração Única

Qualquer pessoa que tentou enviar eventos do Apache Kafka diretamente para clientes frontend ou mobile conhece essa dor. Browsers não conseguem trabalhar com o protocolo binário do Kafka. Você acaba escrevendo adaptadores microservices infinitos, subindo bridges WebSocket, ou montando gambiarras com Server-Sent Events. A situação fica ainda mais complicada quando aparece por perto IoT com o protocolo MQTT, e o negócio exige conectar agentes de IA via o MCP (Model Context Protocol) a essa infraestrutura também.

Em vez de um monte de servidores proxy personalizados, os desenvolvedores do time Aklivity propuseram um único gateway chamado Zilla.

O que o Zilla Pode Fazer

Essencialmente, o Zilla combina dois papéis. O primeiro papel é familiar: é um gateway orientado a eventos (Event Gateway). Ele aceita requisições recebidas via HTTP, WebSocket, gRPC ou SSE e as traduz diretamente para topics do Kafka ou brokers MQTT sem escrever código server-side.

O segundo papel apareceu com a atualização para a versão 2.0. O Zilla aprendeu a trabalhar como um MCP Gateway para modelos de linguagem grandes e agentes autônomos. Se seu assistente de IA precisa de ferramentas de diferentes fontes (APIs REST internas, topics do Kafka, servidores MCP externos), o Zilla as agrega em um único endpoint gerenciado.

Toda a mágica é configurada de forma declarativa através de um único arquivo zilla.yaml. Você descreve bindings, regras de roteamento, validação de schema e políticas de segurança, então executa o binário ou container.

Quatro Recursos Principais do Projeto

Encaminhamento Direto de REST e WebSocket para Topics do Kafka

Você não precisa mais escrever um backend em Go ou Java apenas para aceitar um HTTP POST e colocar o payload em um topic. O Zilla pega o corpo da requisição, valida contra o schema, e escreve no Kafka.

A leitura funciona de forma similar: o frontend abre uma conexão SSE ou WebSocket, e o gateway faz stream de mensagens das partições diretamente para o código do cliente com suporte a cache.

Federação de Ferramentas para Agentes de IA

Em vez de conectar um LLM a cinco servidores MCP diferentes com chaves e formatos separados, você aponta o agente para o endereço do gateway:

http://localhost:7114/mcp

O Zilla agrupa automaticamente os toolkits disponíveis através de namespaces intuitivos:

github__create_pr
payments__refund
kafka__produce_message

O agente vê um catálogo unificado de funções, e o próprio gateway decide para onde enviar a chamada: para a API REST do sistema de pagamento, para o GitHub, ou para uma fila de mensagens.

Controle de Contexto e Carregamento Preguiçoso de Ferramentas

Quando você tem dezenas de ferramentas, a janela de contexto do modelo rapidamente se enche com descrições de schema. O Zilla divide as ferramentas em "quentes" (eager) e "frias". O agente primeiro recebe uma lista básica de capacidades, e as especificações detalhadas são puxadas apenas quando realmente necessárias. Isso economiza tokens e reduz a latência de resposta.

Guards e Validação de Dados Embutidos

O gateway valida estruturas de dados de entrada e saída contra schemas JSON Schema, Avro e Protobuf. Se o modelo gerar uma chamada incorreta ou o cliente enviar JSON malformado, a requisição é bloqueada no nível do gateway antes de alcançar o circuito interno.

Por Trás dos Panos

O gateway é escrito em Java, mas a arquitetura difere significativamente de aplicações enterprise clássicas. Os desenvolvedores visaram reduzir overhead de memória e latência, então aplicaram várias otimizações de baixo nível:

1. Geração de estruturas leves (flyweights) para trabalhar com buffers binários sem alocações desnecessárias no heap.
2. Vinculação de uma conexão a um único worker por toda a vida da sessão, o que elimina sincronização cara de threads.
3. Troca de frames entre streams através de bindings via memória compartilhada com suporte a back-pressure.
4. Uma camada de cache para Kafka que busca um registro do broker uma vez e o distribui para milhares de assinantes.

Graças a isso, o Zilla praticamente não adiciona latência de rede ao fazer proxy de streams.

Início Rápido

A forma mais fácil de experimentar o gateway é através do Docker Compose.

Se você precisa de REST sobre Kafka:

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

Após a inicialização, verificamos o envio de mensagens:

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

curl http://localhost:7114/items

Se você está experimentando com agentes de IA e o protocolo MCP:

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

O gateway vai subir um único ponto de entrada na porta 7114 com suporte a Streamable HTTP e expor métricas na porta 7190.

Nuances e Limitações

Ao conhecer o projeto, há algumas coisas para ter em mente.

O Zilla tem seu próprio modelo de configuração. Os arquivos zilla.yaml acabam sendo bem detalhados: você precisa entender profundamente os conceitos de vaults, bindings, routes e pipelines. Se você está acostumado com configs simples do Nginx, a sintaxe aqui vai levar tempo para aprender.

O segundo ponto diz respeito ao licenciamento. A versão base é distribuída sob a Aklivity Community License. É gratuita para qualquer workload interno e uso em produção, mas proíbe vender o Zilla como um serviço independente. Recursos avançados como armazenamento de estado distribuído baseado em Redis/Hazelcast ou autorização OAuth estendida foram movidos para a versão comercial Zilla Plus.

Vale a Pena Experimentar

O Zilla aborda dois pontos problemáticos de integração de uma vez. Ele elimina a escrita de código boilerplate em torno do Kafka e traz ordem ao zoológico de ferramentas para agentes de IA.

O projeto é especialmente útil se:

• Você está construindo um sistema orientado a eventos e quer entregar dados para clientes sobre protocolos web sem camadas extras.
• Você está desenvolvendo agentes de IA e está cansado de administrar servidores MCP espalhados e chaves de API.
• Sua infraestrutura tem MQTT e Kafka coexistindo, requerendo um único ponto de entrada e monitoramento.

Você pode começar com exemplos prontos no repositório: há cenários claros para a maioria das tarefas típicas.