服务网格是什么
数据面/控制面；service-mesh 节点。
30 分钟
服务网格是什么
微服务拆开后，服务间调用量暴涨：发现、路由、重试、鉴权、可观测 若全写进业务代码，每个团队重复造轮子。Spring Cloud 用 Java 库解决一部分；服务网格（Service Mesh） 把这类能力下沉到 独立基础设施层，业务进程几乎无感知。
学习目标
- 区分 数据面 与 控制面
- 说清 Sidecar 代理在调用链中的位置
- 对照路线图 service-mesh 节点，理解本 track 在微服务路径中的位置
问题从哪来
假设 user-service 调 course-service：
| 需求 | 传统做法 | 痛点 |
|---|---|---|
| 超时 / 重试 | Feign + Resilience4j | 每个服务重复配置 |
| mTLS | 应用内嵌证书逻辑 | 语言栈不一致难统一 |
| 金丝雀 | 改负载均衡或网关规则 | 规则散落多处 |
| 链路追踪 | 各服务引 SDK | 版本升级牵一发动全身 |
网格的思路：把「服务间通信」抽成平台能力，而不是每个 jar 各自实现。
数据面 vs 控制面
控制面（Control Plane） 数据面（Data Plane）
Istiod / Linkerd 控制组件 → 每个 Pod 里的 Sidecar 代理
下发策略、证书、路由规则 拦截进出流量并执行策略
- 数据面：真正转发流量的代理（常见 Envoy），与应用容器同 Pod 部署
- 控制面：集群级「大脑」，把 VirtualService、证书、服务发现结果 推送给 各 Sidecar
业务代码仍发 HTTP/gRPC 到「本机 localhost:15001」之类地址，Sidecar 透明转发到真实目标。
与 Spring Cloud 的分工
| 层次 | Spring Cloud | Service Mesh |
|---|---|---|
| 注册发现 | Eureka / Nacos | K8s Service + 网格服务发现 |
| 客户端负载均衡 | Ribbon / LoadBalancer | Sidecar 出站负载均衡 |
| 熔断 | Resilience4j | DestinationRule + outlier detection |
| 网关 | Spring Cloud Gateway | Ingress / Gateway API + 网格入口 |
两者 可并存也可迁移：新项目可在 K8s 上逐步把横切逻辑从应用挪到网格。详见 mesh-soa。
常见实现
- Istio — 功能全、生态大，本 track 以它为主示例
- Linkerd — 轻量、Rust 数据面
- — 与 HashiCorp 栈集成