GitHub user AlexStocks added a comment to the discussion: [Proposal] Pixiu AI evolution should focus on Dubbo-native differentiation
## A reality check after deep-diving into both proposals I spent a few days stress-testing both proposals against the actual codebase, competitive landscape, and what real Dubbo users are doing in production. Here's what I found — some of it uncomfortable. ### The elephant in the room: Pixiu's MCP Server is HTTP→MCP, not Dubbo→MCP I went through `pkg/filter/mcp/mcpserver/` carefully. The `handlers.go` `buildBackendRequest` only deals with `inPath`, `inQuery`, `inBody` — pure HTTP parameter mapping. There is zero Dubbo protocol code in the MCP filter. The Dubbo proxy filter (`dubboproxy/filter/proxy/proxyfilter.go`) lives in a completely separate code path and the two never connect. So the "Dubbo-native MCP" story is really "HTTP gateway + MCP shell that happens to live in the Dubbo repo." Any API gateway with an MCP plugin can do the same thing. Kong, Higress, and Envoy all shipped this months ago. This isn't a criticism of the engineering — the MCP implementation itself is solid (~1800 lines, SSE, OAuth, Nacos dynamic config, proper session management). But calling it "Dubbo-native" is a stretch. ### What real users are choosing This part hurts more. I looked at what Dubbo users actually deployed for AI gateway needs: - **Ctrip (携程)** — heavy Dubbo user, chose Higress for their AI gateway. Their engineering director presented at the 2025 China Trusted Cloud conference about it. - **Senma (森马)** — Alibaba Cloud AI Gateway (Higress enterprise edition) + Nacos 3.0, 30% efficiency improvement. - **Ant Group SOFA** — released SOFA Higress based on Higress. - **Zhengcaiyun (政采云)** — replaced Kong, APISIX, and Spring Cloud Gateway with Higress. Their roadmap explicitly mentions "http to dubbo" via Higress. Even Alibaba internally, where HSF (≈Dubbo) services need MCP exposure, uses Higress for protocol offloading — not Pixiu. The Dubbo official docs literally have a page titled "How to Proxy Dubbo Services via Higress Gateway." The community is already telling users to use Higress. ### The timing problem is real MCP Gateway market consolidation is happening fast: - **Higress**: entered CNCF Sandbox, MCPMarket global Top 100, shipping features every 2-3 weeks - **Kong AI Gateway 3.14**: Agent Gateway GA (LLM + MCP + A2A unified control plane) - **APISIX 3.12**: full AI plugin suite - **Spring AI Alibaba MCP Gateway**: zero-code Dubbo service → MCP, already production-ready Meanwhile Pixiu sits at 547 stars with no MCP production cases. The ISG 2025 report shows 31% of AI use cases are already in production. The market isn't "about to explode" — it already exploded, and the winners picked their seats. ### What Dubbo Java already solved (6196 lines ago) Dubbo Java merged `dubbo-plugin/dubbo-mcp` in October 2025 — a framework-level MCP implementation with `@McpTool`/`@McpToolParam` annotations, SSE transport, and auto schema generation from Triple OpenAPI. 6196 lines, 54 files, reviewed and merged by the core team. This is the right approach: expose Dubbo services as MCP tools at the framework level, not through a separate gateway. dubbo-go should port this design, not compete with it at the gateway level. ### The filter chain blocker I also looked at what it would take to turn Pixiu into a real AI Gateway. The filter chain (`pkg/common/extension/filter/filter_chain.go`) uses a synchronous request-response model. `OnDecode()` and `OnEncode()` are blocking calls. AI workloads need streaming, backpressure, and long-lived connections — none of which the current architecture supports. Async-ifying the filter chain would be a breaking change affecting all 15+ existing filters. Estimated at ~5.75 person-months with high risk. This is a hard blocker for the "AI Gateway" vision. ### Triple protocol has its own issues The Triple streaming implementation (`triple_protocol/handler_stream.go`) is missing flow control, backpressure, and heartbeat mechanisms. Under AI workload characteristics (long sessions, large payloads, streaming output), this creates real risks: goroutine leaks, OOM under slow consumers, and stale connections after client disconnects. These need to be fixed regardless of AI direction — they affect all Triple users. ### What I think dubbo-go should actually do **Stop trying to be another AI gateway. Do what Java can't.** 1. **Port dubbo-mcp to Go** — the Java team already proved this works at the framework level. dubbo-go should have its own `@McpTool` equivalent, not delegate to a separate gateway project. 2. **Make Triple the best MCP transport** — Triple is HTTP/2-based, which means any gateway can already proxy it. Instead of building a gateway, make Triple so good at MCP that Higress/Kong/Envoy users get the best experience when their backend speaks Triple. This means: fix streaming (flow control, backpressure, heartbeat), add native MCP Streamable HTTP support, and auto-generate tool schemas from service definitions. 3. **Build the bridge, not the gateway** — help Higress users connect to Dubbo services with zero friction. A `dubbo-bridge` adapter that makes Dubbo services discoverable and callable through any MCP gateway. Let Higress be the gateway — Dubbo should be the best backend. 4. **Standardize Nacos as MCP Registry** — this is where Dubbo ecosystem actually has influence. Spring AI Alibaba already uses Nacos for MCP service discovery. Push this to become the standard. ### What I think Pixiu should become Pixiu's MCP Server code is genuinely well-written. But it solves a problem that Higress already solved, for a user base that already chose Higress. Options: - **Demote to examples/demo** — keep the code as a reference implementation showing how to build an MCP server in Go, but stop positioning it as a strategic product - **Merge useful bits into dubbo-go** — the MCP protocol handling, OAuth, and session management code could be extracted as a reusable Go library that dubbo-go's framework-level MCP uses internally - **Don't archive** — that sends the wrong signal. Just be honest about scope ### The hard truth The "Dubbo-native AI Gateway" narrative sounds compelling in a proposal, but it doesn't survive contact with reality. Users don't care about "Dubbo-native" — they care about "zero-effort AI integration for my existing services." Higress + Spring AI Alibaba + Nacos already deliver that, with production validation from Ctrip, Senma, and others. dubbo-go's real AI-era value isn't building another gateway. It's being the fastest, most reliable, most MCP-friendly RPC framework that any gateway can talk to. That's a defensible position that plays to existing strengths. The Java side already figured this out (dubbo-mcp). The Go side should follow the same logic, adapted for Go's cloud-native strengths. 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]
