Zilla：一个网关，三种用法——LLM、MCP、Kafka 事件流

图：Zilla 网关标识（来自项目仓库 assets 目录）

一、一个具体的场景

你手上同时有三件看起来无关的事：

1. 服务 A 用 OpenAI SDK 调 GPT，服务 B 用 Anthropic SDK 调 Claude
2. 十几个 MCP Server 散落各处，Agent 接入要一个个配，权限也没人管
3. Kafka 主题里的实时数据，要暴露给前端 WebSocket 客户端

三件事通常意味着三套中间件、三份运维知识、三堆 YAML。

Aklivity 的 Zilla 提出一个主张：它们本质上是同一件事的不同用法。

二、它是什么

官方描述："A lightweight, streaming-native, multi-protocol gateway for AI, APIs, and real-time data."

关键在这句话："LLM access, MCP tool connectivity, and event streaming are different uses of the same gateway architecture, not three separately deployed gateways."

Zilla 把「协议原生的绑定」组合进一个轻量、无状态的运行时，用声明式的 zilla.yaml 配置。三大能力：

1. LLM 网关——把 OpenAI / Anthropic / Gemini SDK 的 endpoint 指向 Zilla，按模型路由，翻译 chat 与 tool-call 工作流，流式响应，可配置的 prompt 与 response guardrails，导出 token 与延迟指标，模型不可达时可配置 fallback
2. MCP 网关——聚合已有 MCP Server，把 HTTP/OpenAPI 服务转成工具，把 Kafka 能力直接通过 MCP 暴露（不用为这些后端另写包装服务），对外呈现单一带命名空间的 MCP endpoint，按调用方授权可发现与可调用的范围，默认工具列表保持精简、按需发现
3. Kafka 网关——把 Kafka 支撑的 REST API 与实时流暴露给 HTTP、SSE、WebSocket、gRPC、MQTT 客户端，代理原生 Kafka 流量，在网关侧做协议感知的认证、授权、schema 校验与数据策略

三、一个类比：万能插座的转换头

想象一个万能转换插座面板：同一块面板上，HDMI 口转 HDMI、VGA 口转 VGA、USB-C 口转 USB-A——但底层是同一套电路、同一套认证机制、同一套计量。

Zilla 就是这个面板：协议不同的插头插进来，出去都是标准形状。而重要的是，面板背后只有一套「认证 + 授权 + 审计 + 计量」的机制，不是每个插头各配一套。

对 Agent 场景来说，这个类比更贴切的部分是 MCP 网关那一句「单一带命名空间的 MCP endpoint」——Agent 只需要知道一个地址，工具的发现与授权由网关按调用方裁剪。

四、核心功能与工程细节

LLM 网关的实操细节

演示里有个特别诚实的说明：演示采用 BYOK（自带密钥）凭证，调用方需传入对应供应商的有效 Key。「翻译 API 并不会让 A 家的 Key 在 B 家有效。」同时网关托管凭证也能配置。

Guardrail 演示依赖 Presidio 与 embedding 服务；模型 fallback 可在部署不可达时接管。

可观测性方面提供 Grafana 面板（token 用量、请求数、延迟、首 token 时间），也暴露原始 Prometheus 指标（llm_ 前缀，端口 7190）。

Zilla Plus 是商业扩展，额外提供 Amazon Bedrock 支持（包括从既有 SDK 访问 Bedrock 上的 Claude）。

MCP 网关

示例监听 http://localhost:7114/mcp（MCP Streamable HTTP），组合了 MCP Server 聚合、HTTP/OpenAPI 转工具、Kafka 转工具三类来源。受保护的 toolkits 需要 JWT scope。

Kafka 网关

REST CRUD 背后由 Kafka topic 支撑，可直接在 Kafka UI 里查看记录。

仓库结构

Maven 多模块：runtime/（运行时）、probes/（协议探针）、specs/（协议规范）、manager/、cloud/、incubator/、examples/（可运行的 docker-compose 示例）、config/、conf/、build/。双许可文件并存（LICENSE-Apache 与 LICENSE-AklivityCommunity，含 COPYRIGHT 与 NOTICE 模板），另有 MIGRATING.md、CHANGELOG.md、AGENTS.md、CLAUDE.md、.gitflow-changelog 流程配置。

五、上手门槛

三个示例全部用 Docker Compose，克隆即跑：

git clone --depth 1 https://github.com/aklivity/zilla-demos.git
cd zilla-demos/llm.gateway
cp .env.example .env
# 填 OPENAI_API_KEY / ANTHROPIC_API_KEY / GEMINI_API_KEY
docker compose up --build --wait

打开 http://localhost:7860 的演示应用，选 OpenAI SDK、选一个 claude-* 模型、发一句话——Zilla 会路由到 Anthropic，翻译请求与响应，再以 OpenAI 格式返回。ARM64 主机需取消注释 TEI_VERSION=cpu-arm64-1.9。

MCP 示例与 Kafka 示例在仓库 examples/ 目录下，同样 docker compose up --wait。

版本：ZILLA_VERSION=2.6.0。

Web UI：没有传统意义上的管理后台，主交互界面是示例应用与 Grafana 面板；管理面在 manager/ 模块与商业的 Zilla Studio（仓库 assets 中有 zilla-studio@2x.png 截图，指向商业产品）。

硬件要求：轻量无状态运行时，CPU 1-2 核、内存 1-2GB 足够；示例里的 Presidio 与 embedding 服务会额外吃一些内存。不需要 GPU。

六、争议与局限

双许可 + 商业版边界。 核心 Apache-2.0，但仓库同时存在 Aklivity Community 许可文件；Zilla Plus（Bedrock 支持）与 Zilla Studio 是商业产品。开源版能做什么、商业版多做什么，需要逐项核对——这是采用前必须澄清的问题。

Maven / Java 体系较重。 相对 Go 写的同类网关（LiteLLM 之类），Java 多模块 + Maven 构建的学习与迭代成本更高。

示例需分开跑。 README 明确提示「several examples share local ports」，跑下一个示例前要先 docker compose down，新手容易踩。

BYOK 的现实约束。 演示用 BYOK，说明跨供应商调用时密钥不能通用——这限制了网关做「统一凭证池」的想象空间。

概念跨度大。 LLM 网关、MCP 网关、Kafka 网关三种场景放在一起很有想象力，但对只想解决一个具体问题的人来说，学习曲线偏陡。

版本节奏。 .gitflow-changelog 与 MIGRATING.md 说明迁移是常态，升级要读迁移文档。

七、行业意义

Zilla 代表了网关层的一次架构收敛尝试：协议网关的抽象应该足够通用，以至于「AI 网关」和「消息网关」不是两件事。

这个主张在 2026 年越来越站得住脚——AI Agent 需要访问企业工具（MCP）、需要调用模型（LLM）、需要消费实时数据（Kafka/MQTT），而传统做法是每种需求一套中间件。如果一套无状态、声明式配置的运行时能同时满足这三者，运维复杂度会显著下降。

它的技术选择也很有意思：streaming-native（流式优先）不是加分项而是前提——LLM 输出、Kafka 事件、WebSocket 推送本质上都要求流式，一个「先缓冲后返回」的网关在这三个场景里都不合格。协议感知的认证与授权在网关侧完成（而不是后端），也是典型的边缘网关思路。

社区位置也不错：25 位贡献者、Apache-2.0 核心、丰富的 examples 与 docs.aklivity.io 文档、有 Slack 社区与 Artifact Hub 收录，2021 年立项至今已是成熟项目。

对团队的现实价值：一次部署同时解决「模型接入」「Agent 工具接入」「实时数据接入」三件事，且三者共享同一套安全与可观测机制；对架构师：它提供了一个值得研究的「网关抽象应该长什么样」的具体样本。