服务网格概念：Istio 能做什么（概念级）
微服务治理越做越深，团队会发现很多通用能力（熔断、重试、灰度、可观测、加密）每个服务都在重复实现。服务网格（Service Mesh）的思路是把这些能力从业务代码里抽出来，下沉到基础设施层。Istio 是目前最主流的服务网格实现，本章只讲概念与能力边界。
核心思想：边车代理（Sidecar）
Istio 给每个业务 Pod 注入一个 Envoy 代理容器（sidecar）。业务容器只关心业务，进出流量全部经过 sidecar 转发，治理逻辑在代理层完成：
┌─────────────────────┐
│ Pod │
│ ┌──────┐ ┌─────┐ │
│ │ 业务 │──▶│Envoy│ │──▶ 下游服务
│ │容器 │◀──│sidecar│◀─│
│ └──────┘ └─────┘ │
└─────────────────────┘
对业务代码完全透明：不需要引入 SDK、不需要改代码，流量治理能力“注入式”获得。
数据面与控制面
- 数据面（Data Plane）：所有 sidecar 代理组成，负责实际转发与执行策略。
- 控制面（Control Plane）：Istiod 统一管理，把用户声明的路由/安全/观测策略下发给各 sidecar，并收集遥测数据。
这种“集中下发策略 + 分布执行”的结构，让运维可以用声明式配置治理整个网格，而不是一台台改服务。
Istio 能做什么
- 流量管理：细粒度路由与灰度。按版本、权重、请求头把流量切到不同版本（金丝雀/蓝绿），支持故障注入（人为注入延迟/异常验证韧性）、超时与重试策略，全部 YAML 声明，无需改代码：
apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
name: order-vs
spec:
hosts: ["order-service"]
http:
- match: # 灰度子集：带灰度头的流量
- headers:
x-version: { exact: canary }
route: [{ destination: { host: order-service, subset: v2 } }]
- route:
- destination: { host: order-service, subset: v1 }
apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
name: order-dr
spec:
host: order-service
subsets:
- name: v1
labels: { version: v1 }
- name: v2
labels: { version: v2 }
- 弹性能力：在代理层配置熔断、连接池、重试、超时，替代/补充应用层的 Resilience4j。
- 可观测性：sidecar 自动上报指标、访问日志与分布式追踪数据（配合 Prometheus/Grafana/Jaeger 等），无需埋点即可获得全链路视图。
- 安全：服务间默认双向 TLS（mTLS）加密，配合授权策略做服务级鉴权，替代“内网裸奔”。
与 Spring Cloud 的关系和边界
服务网格与 Spring Cloud 不是二选一，而是分层关系：
| 能力 | Spring Cloud | Istio 服务网格 |
|---|---|---|
| 服务注册发现 | Nacos/Eureka（SDK 内） | 网格内由 sidecar 感知（可不用 SDK 注册） |
| 熔断/重试/超时 | Resilience4j/代码配置 | 代理层策略声明 |
| 路由灰度 | 网关权重/负载均衡 | VirtualService 权重/匹配 |
| 可观测 | Micrometer/日志埋点 | 代理自动上报 |
| 加密 | 代码/网关层 | sidecar mTLS |
要警惕重复治理：若已用服务网格做熔断重试，应用内又开一套，两层叠加会放大超时与重试（双重重试风暴）。迁移期建议明确“哪一层负责哪类策略”。
引入成本
Istio 的能力很诱人，但引入成本真实存在：sidecar 增加资源占用与调用延迟（通常很小）、控制面与升级运维复杂度、排障链路变长（多一跳代理）、团队需要新技能。小规模或早期系统不一定划算，通常建议在“服务数量多、治理规则复杂、多语言混部、需要细粒度灰度与 mTLS”时引入。
小结
服务网格把流量治理从“每个服务的 SDK/代码”下沉为“代理层声明式策略”，Istio 是其中的代表实现，擅长灰度路由、弹性策略、可观测与 mTLS。它解决的是治理范式的规模问题，不是 Spring Cloud 的替代品；是否引入，取决于团队规模与治理复杂度是否已超过 SDK 模式的上限。