GitHub user AlexStocks created a discussion: [Proposal] Pixiu AI evolution should focus on Dubbo-native differentiation
# [Proposal] Pixiu's AI-era evolution should double down on Dubbo-native differentiation, not just become another generic AI gateway Pixiu already positions itself as an `AI / API Gateway` and explicitly talks about `LLM`, `MCP`, and Kubernetes ingress. That means the real question is no longer: > Should Pixiu do AI? The real question is: > If Pixiu continues evolving toward AI, how can it do so in a way that is > **distinctively Dubbo-native**, instead of becoming just another generic AI > gateway? After a 20-round internal battle on this question, my conclusion is: > **Pixiu's unique value is not “it can proxy LLMs/MCP too”. Its unique value > is that it can turn Dubbo-era enterprise service estates and governance > systems into AI-callable, governable, auditable capability networks.** That is the difference between a generic AI gateway story and a Pixiu-specific one. --- ## 1. What is real differentiation, and what is only narrative? ## Real differentiation ### 1.1 Turning Dubbo service networks into AI-callable capability networks This is the strongest unique direction. Pixiu sits on top of a Dubbo ecosystem that already has: - service contracts - method signatures - service groups / versions - routing rules - registry metadata - traffic governance - enterprise microservice assets already running in production If Pixiu can make those services safely callable by AI systems (through MCP/tool exposure, protocol translation, tool schema generation, routing, auth, and observability), that is a meaningful moat. Generic AI gateways usually start from HTTP APIs and JSON payloads. Pixiu can start from **enterprise service estates that already exist**. That is much closer to real enterprise value. --- ### 1.2 Combining AI gateway semantics with Dubbo governance semantics The strongest Pixiu story is not: - “we also support OpenAI-compatible traffic” - “we also support MCP” Those are increasingly table stakes. The stronger story is: - AI calls can inherit Dubbo-style routing, tagging, canary, retry, fallback, isolation, audit, and service governance semantics - tool exposure is not just protocol conversion, but governance-aware capability exposure - AI traffic becomes manageable in the same production discipline as RPC traffic This is where Pixiu can be more than “just another AI reverse proxy”. --- ### 1.3 Reusing enterprise registries and metadata as AI control-plane assets Pixiu already documents dynamic discovery and management patterns around MCP tools / LLM endpoints / registry-backed configuration. This is important because it suggests a path where: - service discovery is not only about endpoints - registry metadata becomes capability metadata - enterprise control planes (such as Nacos-centered environments) can be reused for AI tool / model / gateway management This is especially strong in environments where Dubbo + Nacos + Java/Go services already form the backbone of the platform. --- ### 1.4 Bridging stock enterprise services into MCP / tool ecosystems with low migration cost This is probably the clearest practical moat. Many enterprises do not need “yet another LLM proxy”. They need a way to let AI systems safely call: - existing business APIs - internal HTTP services - Dubbo services - internal platform capabilities If Pixiu becomes the lowest-friction path from: - Dubbo / HTTP / gRPC / Triple services - into MCP / tool-callable capability surfaces then it becomes strategically valuable in a way generic gateways are not. --- ## Mostly table stakes or narrative (not enough by themselves) The following may be useful, but are **not sufficient differentiation** by themselves: - “supports OpenAI-compatible APIs” - “supports MCP protocol” - “supports SSE / streaming” - “supports token metrics” - “supports fallback / retry” - “supports OAuth / JWT” - “supports K8s ingress” - “supports multiple protocols” These are all important, but most modern AI / API gateways can claim some version of them. So if Pixiu's AI direction is described only at that level, it is very easy to get lost in generic AI gateway competition. --- ## 2. What Pixiu should optimize for If Pixiu wants to build real Dubbo-native AI differentiation, I would prioritize these themes. ## P0: Enterprise service capability gateway This should be the center of gravity. Pixiu should aim to become: - the gateway that exposes enterprise service capability safely to AI systems - not only the gateway that forwards AI model requests This means: - service-to-tool exposure - schema-aware tool generation - method-level auth / policy - registry/metadata-driven tool catalog - governance-aware invocation If Pixiu owns this layer, it gains a meaningful moat. --- ## P0: AI governance built on Dubbo governance Pixiu should translate existing Dubbo-style governance into AI-era controls, such as: - which tenant / agent can call which service or tool - which tools are read-only vs mutation-capable - which routes can hit premium models vs cheap models - how to do fallback when one model/provider degrades - how to canary model/tool rollout under production traffic This is stronger than just “model routing”, because it ties AI traffic to enterprise governance discipline. --- ## P1: Registry- and metadata-driven AI routing Pixiu should think beyond “upstream list + static config”. A stronger direction is: - registry-backed LLM / MCP / tool discovery - metadata-driven route selection - routing by capability, cost tier, tenant, region, compliance, safety level, or cache affinity This is where Dubbo-era service-discovery DNA can become AI-era value. --- ## P1: Tool-aware observability and audit Generic AI gateways often observe only model calls. Pixiu should aim to observe: - model request - tool invocation - downstream service invocation - business result path - fallback / retry / degradation path This would let enterprises answer questions like: - why did the agent fail? - which downstream service caused the failure? - which tool path is expensive? - which model/tool combination is unstable? This kind of end-to-end observability is much more compelling than only token counting. --- ## P2: K8s + Dubbo + AI unified control plane This is strategically interesting, but should follow after the above is made clear. If Pixiu can unify: - API traffic - AI traffic - MCP/tool traffic - service discovery and routing - ingress-layer governance under one Kubernetes-friendly control plane, that is a strong platform story. But this only becomes differentiated if it is tied to enterprise service capability governance, not just general ingress features. --- ## 3. What Pixiu should avoid To keep the direction sharp, I would avoid turning core Pixiu into: - a prompt engineering platform - an agent workflow engine - a RAG framework - a memory/session product framework - a vector database integration hub - a provider-specific SDK zoo Those may exist in ecosystem projects, plugins, or adapters. But if they dominate the core roadmap, Pixiu risks losing its strongest identity. A useful rule is: > If a capability primarily helps build AI applications, it probably belongs > above Pixiu. > If a capability primarily helps govern, expose, secure, route, or observe AI > traffic over enterprise services, it probably belongs in Pixiu. --- ## 4. A clearer differentiation statement I think Pixiu's strongest AI-era statement should not be: - “Pixiu is a next-generation AI gateway” That is too broad and too easily copied. A stronger statement would be something like: > **Pixiu is the Dubbo-native AI capability gateway that turns enterprise > services into governable, AI-callable tools and traffic planes.** Or, more simply: > **Pixiu is where Dubbo service governance meets AI tool and model traffic.** That is much more specific, and much harder for generic AI gateways to claim credibly. --- ## 5. My concrete recommendation If the community wants to make Pixiu's AI path more distinctive, I would recommend this order: 1. **Make service-to-tool exposure and governance the flagship story** 2. **Build AI routing on top of registry/metadata/governance, not just provider APIs** 3. **Strengthen end-to-end observability from model call to downstream service/tool result** 4. **Use K8s/Ingress as a multiplier, not as the main differentiation itself** 5. **Keep prompt/agent/RAG frameworks in ecosystem, not in Pixiu core** In short: - not “more AI features” - but “more Dubbo-native AI control-plane value” --- ## 6. Questions for the community 1. Do we agree that Pixiu's AI differentiation should center on **enterprise service capability exposure and governance**, rather than generic model proxying? 2. Which is the stronger flagship direction for Pixiu: - model gateway - tool gateway - unified service capability gateway 3. Which Dubbo-native assets should be prioritized for AI use: - registry metadata - routing / governance rules - service contracts / schemas - observability / tracing 4. Should some AI-facing features remain in plugins / ecosystem projects rather than going into core? If there is interest, this discussion can later be split into smaller RFCs around: - service-to-tool exposure - AI governance policy - metadata/capability routing - observability for AI + downstream services GitHub link: https://github.com/apache/dubbo-go-pixiu/discussions/990 ---- 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]
