GitHub user AlexStocks edited a comment on the discussion: [提案] Pixiu 在 AI 时代的演进应当聚焦 Dubbo 原生差异化，而非沦为又一个通用 AI 网关
## 深入研究两份方案后的现实检验 我花了几天时间，用实际的代码库、竞争格局以及真实 Dubbo 用户的生产实践来验证这两份方案。以下是我的发现——有些可能不太好听。 ### 房间里的大象：Pixiu 的 MCP Server 是 HTTP→MCP，而非 Dubbo→MCP 我仔细查看了 `pkg/filter/mcp/mcpserver/` 目录。`handlers.go` 中的 `buildBackendRequest` 只处理 `inPath`、`inQuery`、`inBody`——纯粹的 HTTP 参数映射。MCP filter 中完全没有 Dubbo 协议代码。Dubbo proxy filter（`dubboproxy/filter/proxy/proxyfilter.go`）位于完全独立的代码路径中，两者从未连接。 所以所谓"Dubbo-native MCP"的故事，实际上是"HTTP gateway + 一个恰好放在 Dubbo 仓库里的 MCP shell"。任何带有 MCP 插件的 API gateway 都能做到同样的事情。Kong、Higress 和 Envoy 几个月前就已经发布了这个功能。 这不是在批评工程质量——MCP 实现本身是扎实的（约1800行代码，SSE、OAuth、Nacos 动态配置、完善的 session 管理）。但称其为"Dubbo-native"有些牵强。 ### 真实用户的选择 这部分更让人难受。我查看了 Dubbo 用户实际为 AI gateway 需求部署了什么： - **携程** —— Dubbo 重度用户，AI gateway 选择了 Higress。他们的工程总监在2025年中国可信云大会上做了相关演讲。 - **森马** —— 阿里云 AI Gateway（Higress 企业版）+ Nacos 3.0，效率提升30%。 - **蚂蚁集团 SOFA** —— 基于 Higress 发布了 SOFA Higress。 - **政采云** —— 用 Higress 替换了 Kong、APISIX 和 Spring Cloud Gateway。他们的路线图中明确提到通过 Higress 实现"http to dubbo"。 甚至在阿里巴巴内部，当 HSF（≈Dubbo）服务需要 MCP 暴露时，使用的是 Higress 做协议卸载——而不是 Pixiu。 Dubbo 官方文档甚至有一页标题就是"如何通过 Higress Gateway 代理 Dubbo 服务"。社区已经在告诉用户使用 Higress。 ### 时机问题确实存在 MCP Gateway 市场整合正在快速进行： - **Higress**：进入 CNCF Sandbox，MCPMarket 全球 Top 100，每2-3周发布新功能 - **Kong AI Gateway 3.14**：Agent Gateway GA（LLM + MCP + A2A 统一控制平面） - **APISIX 3.12**：完整的 AI 插件套件 - **Spring AI Alibaba MCP Gateway**：零代码 Dubbo 服务 → MCP，已生产就绪 而 Pixiu 停留在547 stars，没有 MCP 生产案例。ISG 2025 报告显示31%的 AI 用例已经进入生产阶段。市场不是"即将爆发"——而是已经爆发，赢家已经选好了座位。 ### Dubbo Java 早已解决的问题（6196行代码） Dubbo Java 在2025年10月合并了 `dubbo-plugin/dubbo-mcp` —— 一个框架级的 MCP 实现，包含 `@McpTool`/`@McpToolParam` 注解、SSE transport，以及从 Triple OpenAPI 自动生成 schema。6196行代码，54个文件，由核心团队审核并合并。 这是正确的方向：在框架层面将 Dubbo 服务暴露为 MCP tools，而不是通过一个独立的 gateway。dubbo-go 应该移植这个设计，而不是在 gateway 层面与之竞争。 ### filter chain 的阻碍 我还研究了将 Pixiu 变成真正 AI Gateway 需要什么。filter chain（`pkg/common/extension/filter/filter_chain.go`）使用同步的请求-响应模型。`OnDecode()` 和 `OnEncode()` 是阻塞调用。AI 工作负载需要 streaming、背压和长连接——当前架构都不支持。 将 filter chain 异步化是一个破坏性变更，会影响所有15+个现有 filters。估计需要约5.75人月，风险很高。这是"AI Gateway"愿景的硬阻碍。 ### Triple 协议自身的问题 Triple 的 streaming 实现（`triple_protocol/handler_stream.go`）缺少流量控制、背压和心跳机制。在 AI 工作负载特征下（长会话、大负载、streaming 输出），这会造成真实风险：goroutine 泄漏、慢消费者下的 OOM、客户端断开后的陈旧连接。 无论 AI 方向如何，这些都需要修复——它们影响所有 Triple 用户。 ### 我认为 dubbo-go 应该做什么 **别再试图成为另一个 AI gateway。做 Java 做不到的事。** 1. **将 dubbo-mcp 移植到 Go** —— Java 团队已经证明这在框架层面是可行的。dubbo-go 应该有自己的 `@McpTool` 等价物，而不是委托给一个独立的 gateway 项目。 2. **让 Triple 成为最好的 MCP transport** —— Triple 基于 HTTP/2，这意味着任何 gateway 都已经可以代理它。与其构建一个 gateway，不如让 Triple 在 MCP 方面如此优秀，以至于 Higress/Kong/Envoy 用户在其后端使用 Triple 时获得最佳体验。这意味着：修复 streaming（流量控制、背压、心跳），添加原生 MCP Streamable HTTP 支持，以及从服务定义自动生成 tool schema。 3. **构建桥梁，而非 gateway** —— 帮助 Higress 用户零摩擦地连接 Dubbo 服务。一个 `dubbo-bridge` 适配器，让 Dubbo 服务可被任何 MCP gateway 发现和调用。让 Higress 做 gateway——Dubbo 应该做最好的后端。 4. **将 Nacos 标准化为 MCP Registry** —— 这是 Dubbo 生态真正有影响力的地方。Spring AI Alibaba 已经在使用 Nacos 做 MCP 服务发现。推动这成为标准。 ### 我认为 Pixiu 应该成为什么 Pixiu 的 MCP Server 代码写得确实很好。但它解决的问题 Higress 已经解决了，目标用户群已经选择了 Higress。 选项： - **降级为 examples/demo** —— 保留代码作为参考实现，展示如何在 Go 中构建 MCP server，但不再将其定位为战略产品 - **将有用的部分合并到 dubbo-go** —— MCP 协议处理、OAuth 和 session 管理代码可以提取为可复用的 Go library，供 dubbo-go 框架级 MCP 内部使用 - **不要归档** —— 那样会发出错误信号。只需对范围保持诚实 ### 残酷的现实 "Dubbo-native AI Gateway"的叙事在方案中听起来很有说服力，但经不起现实的检验。用户不关心"Dubbo-native"——他们关心的是"为现有服务提供零成本的 AI 集成"。Higress + Spring AI Alibaba + Nacos 已经提供了这个能力，并有携程、森马等的生产验证。 dubbo-go 在 AI 时代的真正价值不是构建另一个 gateway。而是成为任何 gateway 都能与之对话的，最快、最可靠、最 MCP 友好的 RPC 框架。这是一个可防守的定位，能发挥现有优势。 Java 端已经想通了这一点（dubbo-mcp）。Go 端应该遵循同样的逻辑，适配 Go 的云原生优势。 GitHub link: https://github.com/apache/dubbo-go-pixiu/discussions/990#discussioncomment-17431792 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
