AI 时代我们还需要 Service Mesh 与 RPC 么?

我爱免费

作者：微信文章

服务网格（Service Mesh）是昙花一现的风口，还是值得沉淀的底层能力？这几年，它的关注度明显下降了。在实际生产中，很多团队因技术债务、部署复杂度望而却步，而 AI 和大语言模型（LLM）的兴起，又把“高并发”与“低延迟”的诉求重新拉回舞台中央。这让我们不得不再次问自己：Service Mesh，还有存在的意义吗？它是否已经过时？又该如何在这个日新月异的技术浪潮中找到自己的位置？

这篇文章尝试跳出技术细节，回到工程理性和架构演进的视角，重新审视 Service Mesh 的价值轨迹。

在微服务的世界里，Service Mesh（服务网格）是一个前几年很火的概念。以 Istio 和 Envoy 为代表的 Sidecar（边车）模式，通过将服务治理能力从业务代码中优雅地剥离，为我们带来了便利。

对于那些对性能延迟和资源消耗有着严苛要求的场景，前几年一个名为 "Proxyless"（无代理）的新范式正走向台前。它究竟是什么？它与我们熟悉的 Sidecar 模式有何不同？它背后的核心协议 xDS 真的有创新吗？像 Dubbo-Go 这样的经典 RPC 框架又是如何拥抱这一变化的？
一、经典 Service Mesh：通用、透明的代价

在聊 Proxyless 模式之前，我们必须先理解它的“前辈”——基于 Sidecar 架构的服务网格。

你可以把每个微服务应用类比成一个部门，而 Sidecar（比如 Envoy）就像给每个部门配备了一位“全能秘书”。这个秘书不会参与核心业务，但他负责处理所有的对外沟通、安保和行政事务，比如：

流量管理：决定请求应该由谁处理（路由）、如何分配（负载均衡）；

安全保障：校验请求身份（认证）、保障传输加密；

可观测性：记录请求的指标、日志和调用链路（Tracing）。

最大的好处是什么？对业务无侵入。应用开发者可以专注写业务，完全不需要处理服务治理的复杂逻辑。这一切都交给控制平面（比如 Istio）去完成，它像“总指挥部”一样，统一给各个 Sidecar 下发治理规则。



但天下没有免费的午餐。Sidecar 带来的便利背后，也存在显而易见的成本：

性能开销：每一次服务通信，都需要经过 Sidecar，增加了网络跳转和处理延迟；

资源消耗：每个服务实例都要部署一个 Sidecar，当服务数量成百上千时，这些“秘书”本身也会占用大量 CPU 和内存资源；

部署复杂度：引入 Mesh 后，部署链路变长、运维难度提升，新手上手门槛变高。

这些问题在规模化场景中尤为突出，也促使社区开始思考：有没有可能不要 Sidecar，但保留服务网格的核心能力？
二、Proxyless 的兴起：当性能与资源成为核心诉求

为了缓解 Sidecar 带来的资源与性能负担，社区逐渐探索出一种新的架构范式：Proxyless（无代理）模式。

它的核心理念其实非常简单：

我们不再为每个服务部署一个代理，而是把服务治理的能力内嵌进应用框架的 SDK 中。

打个比方：原来每个部门都有一个秘书处理行政事务（流量、安全、监控），现在，我们把这份“秘书手册”直接交给部门员工，让他们自己根据规则行动。

在这个架构中，像 Dubbo-Go、gRPC 这样的微服务框架，已经具备了和控制面（比如 Istio）直接对接的能力。它们不再依赖 Sidecar，直接从控制平面获取路由、配置等治理信息，实现了“点对点”的高效通信。


📌 关键讨论 1：Proxyless 是不是更“侵入”？

这是一个非常实际的问题，而且答案是：是的，但换了个层面。

模式	对应用代码的侵入性	对部署/运维的侵入性
Sidecar 模式	零侵入：业务代码无需改动	有侵入：部署复杂，需要注入代理
Proxyless 模式	有侵入：依赖特定 SDK，升级需重新编译	低侵入：部署更简单，不需单独代理

简言之：

如果你追求部署简洁，Proxyless 是理想选择；

如果你不希望改动业务代码，Sidecar 更合适。

这也是两种架构之间最核心的权衡。
三、xDS：云原生网络的“通用语”

无论你选择 Sidecar 还是 Proxyless，本质上它们都需要解决一个共同问题：

如何从控制平面获取服务治理的动态配置？

这就需要一个“通用语言”，用于控制平面和数据平面之间的信息传递。而这门语言，就是 xDS 协议。
🔍 什么是 xDS？

xDS（x Discovery Service）是一套 API 协议，由 Envoy 项目最早提出，用来实现服务治理的动态配置和热更新。

其中的 “x” 表示多种服务发现和配置能力，包括：

LDS（Listener Discovery Service）：监听器发现；

RDS（Route Discovery Service）：路由配置；

CDS（Cluster Discovery Service）：服务集群信息；

EDS（Endpoint Discovery Service）：后端服务节点列表。

无论你是一个 Envoy 代理，还是一个嵌入了 xDS SDK 的 Proxyless 应用框架（如 Dubbo-Go），只要理解这套协议，就可以统一从控制面获取完整的服务治理能力。

📌 关键讨论 2：xDS 和传统配置中心有何不同？

很多人会疑问：xDS 是不是就是“配置中心 Plus”？和 Nacos、Apollo 这类配置中心有什么区别？

我们不妨来看一张对比表：

维度	传统配置中心（如 Nacos）	xDS 协议体系
通信模式	拉模型（Polling/长轮询）	推模型（gRPC流式推送）
配置结构	非结构化（KV、JSON）	高度结构化（LDS/RDS 等）
关注点	应用层配置（业务参数）	网络层配置（路由、拓扑）
动态性	毫秒/秒级响应即可	需实时响应拓扑变更
使用范围	应用框架自定义集成	Mesh 和 RPC 框架统一支持

简而言之：

传统配置中心解决的是“应用如何读取配置”；
而 xDS 解决的是“如何对大规模网络流量进行统一编程”。

它的实时性、标准化程度、场景适配能力，远超传统配置系统，是真正支撑起现代服务治理体系的“控制语”。
四、Dubbo-Go 的选择：拥抱 Proxyless

有了 xDS 协议这把“钥匙”，我们终于可以理解 Dubbo-Go 在 Proxyless 模式下的真实运作方式。

在传统架构中，Dubbo 等 RPC 框架需要依赖 Zookeeper、Nacos 等服务注册中心：服务启动时主动“注册自己”，消费端再去“拉取服务列表”。

但在 Proxyless 架构下，这一模式发生了根本变化：

服务注册不再是应用的责任，而是由底层基础设施（如 Kubernetes + Istio）自动完成。

🧩 新范式：从“主动注册”到“被动订阅”

Dubbo-Go 作为服务消费者，不再关心服务在哪里、实例有多少。而是通过内置的 xDS SDK，自动订阅控制平面的服务信息变化，并实时更新本地缓存的服务列表。

这一过程包含三个关键转变：

服务注册：由 Kubernetes 接管（通过 pod label + Service 自动发现）；

服务发现：由控制平面通过 xDS 推送给 Dubbo-Go；

服务路由与负载均衡：由框架自身的调用链逻辑处理。

这样一来，整个服务治理链条就彻底从 Sidecar 中剥离，回归到了框架本身。

现在，我们将所有概念融合，清晰地展示出 Dubbo-Go 在这个体系中的具体位置和作用。对于大多数开发者来说，可以通过下面这张图来理解其核心工作流：


📌 关键讨论 3：还需要 Zookeeper 吗？
Zookeeper、Nacos 等传统注册中心，在 Kubernetes 场景下的职责已经被控制面和 xDS 所替代。应用层的“服务注册”逻辑完全可以剥离，系统变得更轻量，也更符合云原生的运维方式。

下面的序列图清晰地展示了这一新模式：


这是从传统微服务转向服务网格最常见的困惑之一。在云原生（Kubernetes）环境中，服务注册的模式发生了根本性的改变。

还需要 Zookeeper 吗？不再需要 Zookeeper/Nacos 等传统注册中心，应用本身也不再需要主动注册。

核心转变是：服务注册与发现的责任从‘应用框架’上移到了‘基础设施（Kubernetes + Istio）’。Dubbo-Go 的角色从“主动注册”转变成了“被动发现、主动订阅”。

下面这张更为精细的图表，揭示了 Dubbo-Go 框架内部“服务调用逻辑”和“xDS SDK”模块是如何协同工作的。



这个过程完美地展示了框架如何通过内部模块的精密协作，将复杂的网络通信和治理细节对业务开发者完全屏蔽。在 Dubbo-Go 的实践中，xDS SDK 的引入不仅实现了服务治理功能的“内嵌”，也让整个框架在 AI 时代的新场景中具备了更高的灵活性和可组合性。
五、AI 时代：Service Mesh 的退烧与重塑

我们必须承认，Service Mesh 的热度确实已经“退烧”了。它不再是技术大会的宠儿，也逐渐淡出不少团队的技术选型清单。

这并不是技术的失败，而是它从“期望膨胀”走向“理性回归”的自然过程。
🚧 高门槛：从“想用”到“用得起”

Service Mesh 的问题从来不是能力不强，而是：

部署太重：一个完整的 Mesh 系统往往包括 Istio、Envoy、Pilot、Mixer 等多个组件，复杂度陡增；

成本太高：Sidecar 带来的资源消耗，对小团队或中等流量场景不够友好；

价值兑现慢：只有当服务数量足够多、调用链足够复杂，Mesh 的优势才真正显现。

这让很多中小团队望而却步，也让一些尝鲜者在“部署→踩坑→放弃”中打了退堂鼓。
🔄 重新思考：AI 应用的微服务特性

当大家的注意力转向大语言模型（LLM）和 AI 应用时，很多人以为：

“AI 推理负载是单点任务，对 Service Mesh 没啥需求。”

但现实是：生产级 AI 应用（尤其是 RAG 架构）其实非常微服务化。比如，一次看似简单的问答请求，其背后可能依赖如下组件：

API 网关

检索编排服务

文本向量化模块

向量数据库（如 Faiss、Milvus）

Prompt 构造器

LLM 模型服务

审查与过滤模块

缓存层（如 KVCache）

这已经不是单点模型调用，而是一条复杂的“AI 推理流水线”。
💡 再看 Service Mesh 的价值

AI 应用一旦形成“服务化调用链”，就会重新暴露出老问题：

为什么我的响应变慢了？（→ 可观测性）

哪个模块掉了链子？（→ 可靠性）

能不能只让测试流量走新 Prompt？（→ 灰度路由）

多个模型服务怎么安全通信？（→ mTLS、认证授权）

这些场景，正是 Service Mesh 所擅长的。而它的“第二春”，也许正藏在这批复杂度激增的 AI 应用背后。
六、如何跟上时代？融合与演进

AI 时代的快速演进，确实给架构层带来了挑战。但历史告诉我们，真正坚固的技术不会被轻易取代，而是会进化与融合。

Service Mesh 想要在这个新时代焕发活力，需要做出以下几个方向的变革：

---

1️⃣ AI 即服务网格（Mesh-AI）

未来的 Mesh，不再只是流量管理工具，它本身也可以融合 AI 能力：

异常诊断助手：借助 LLM，自动分析调用链、日志，判断瓶颈和故障根因；

策略生成助手：通过自然语言生成访问控制策略、路由规则等；

治理优化建议：通过学习流量模式、服务 SLA，智能推荐更优配置。

这将大幅降低使用门槛，让非 Mesh 专家也能高效运维。

---

2️⃣ 面向 AI 负载的优化

AI 推理服务对网络的要求极为苛刻，Mesh 架构也需要“感知”并适配这些特性：

Proxyless 模式的复兴：在低延迟场景下，不经过 Sidecar 是最优解；

GPU/NPU 感知路由：根据节点算力动态路由请求；

精细化成本控制：Mesh 可作为预算守门员，对模型调用频率、带宽做限流与配额控制。

---

3️⃣ 从 Sidecar 到多样治理形态

未来，Mesh 不会只存在一种形态。

对于大企业，Sidecar 提供了最高的治理抽象和隔离性；

对于高性能业务，Proxyless 是更轻、更快的替代；

对于边缘和嵌入式设备，还会有混合模式出现。

服务网格的价值，不在于形式，而在于是否能统一服务治理体验。

---

✍️ 结语：Mesh 的价值，不是“红”而是“稳”

技术的发展，不是不断换“风口”的游戏，而是“稳中求变”的艺术。

Service Mesh 曾经站在浪潮之巅，如今虽热度下降，但在真正需要治理、安全、观测的复杂系统中，它依旧是不可替代的底座。

而 AI 时代的到来，不是它的终点，反而可能是新旅程的起点。

“稳定，是一切智能系统的基础。”
Service Mesh，依然值得我们信任。

Service Mesh 的故事应该没有结束，它需要在真正适用的复杂场景中沉淀下来，证明自身的价值。随着AI 时代的到来，为其开辟了一片更广阔、也更需要它的新大陆。
dubbogo 社区


欢迎加入 dubbogo 社区 钉钉群: 23331795 。