Zilla Gateway 通过单一配置连接 Apache Kafka 和 AI 代理
任何尝试过将事件从 Apache Kafka 直接推送到前端或移动客户端的人都知道这种痛苦。浏览器无法处理 Kafka 的二进制协议。你最终会编写无穷无尽的微服务适配器，启动 WebSocket 网桥，或者用 Server-Sent Events 拼凑临时方案。当附近出现使用 MQTT 协议的物联网设备，而业务又要求通过 MCP（Model Context Protocol）将 AI 代理连接到该基础设施时，情况会变得更加复杂。
Aklivity 团队的开发者没有使用一堆自定义代理服务器，而是提出了一个名为 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 主题
你不再需要为了接收 HTTP POST 请求并将负载放入主题而编写 Go 或 Java 后端。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）和"冷"。代理首先收到一个基本的能力列表，详细规格只在实际需要时才被拉取。这节省了 token 并降低了响应延迟。
内置守卫和数据验证
网关根据 JSON Schema、Avro 和 Protobuf 模式验证传入和传出的数据结构。如果模型生成了错误的调用，或者客户端发送了格式错误的 JSON，请求会在到达内部链路之前被网关层拦截。
底层实现
该网关使用 Java 编写，但架构与经典企业应用程序有很大不同。开发者旨在减少内存开销和延迟，因此应用了几种底层优化：
- 生成用于处理二进制缓冲区的轻量级结构（flyweights），避免不必要的堆分配。
- 将连接绑定到单个 worker 并贯穿整个会话生命周期，从而消除昂贵的线程同步。
- 通过支持背压的共享内存在跨绑定的流之间进行帧交换。
- Kafka 缓存层，从代理获取一次记录后分发给数千个订阅者。
得益于此，Zilla 在代理流时几乎不增加网络延迟。
快速入门
试用网关最简单的方式是通过 Docker Compose。
如果你需要 REST over 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 代理工具的混乱带来了秩序。
如果你属于以下情况，这个项目特别有用：
- 你正在构建事件驱动系统，希望通过 Web 协议将数据传递给客户端，而无需额外的中间层。
- 你正在开发 AI 代理，受够了管理分散的 MCP 服务器和 API 密钥。
- 你的基础设施中 MQTT 和 Kafka 共存，需要一个统一的入口点和监控。
你可以从仓库中的现成示例开始：大多数典型任务都有清晰的场景。
相关项目