服务网格在做什么
服务网格把服务间通信的治理能力（mTLS 加密、重试与超时、熔断、流量切分、遥测采集）从业务代码里下沉到数据面代理，由控制面统一下发策略。好处是异构语言的服务获得一致的治理行为，业务侧不用为每个语言各写一套 SDK；代价是多了一层代理带来的延迟与资源开销，以及控制面本身需要运维。引入时机通常是服务数量、语言异构度与治理诉求都达到一定规模之后。
基本信息
| 数据面 | 边车或节点代理执行策略与遥测采集 |
|---|---|
| 控制面 | 下发路由、安全与可观测配置 |
| 适用 | 服务规模与治理诉求达到一定程度后再引入 |
| 开销口径 | 每跳延迟增量与代理自身的 CPU、内存占用要单独计入容量模型 |
典型使用场景
- 统一 mTLS：服务间通信全链路加密与身份校验，无需每个应用自建证书流程
- 灰度发布：按请求头或比例切流，配合指标观察再扩大范围
- 统一可观测：各语言的调用指标与追踪数据格式一致，便于统一看板
- 故障隔离：统一配置熔断与超时策略，避免各服务实现不一
- 多集群与多环境路由：通过控制面统一下发路由规则
引入步骤
- 评估适用：服务数量、语言异构度与治理诉求是否匹配
- 小范围试用：先接非核心服务，量化延迟与资源开销
- 策略梳理：重试、超时与熔断在网格侧显式配置，避免与应用叠加
- 安全启用：开启 mTLS 并演练证书轮换
- 运维纳入：控制面升级与代理版本管理列入常规工作
边界与回退
| 范围边界 | 网格治理东西向流量，南北向入口策略保持独立 |
|---|---|
| 回退路径 | 保留快速摘除边车或直连应急通道的预案 |
| 重试归属 | 网格与应用只能有一层负责重试，否则重试次数成倍放大 |
重试配置要点（网格侧）
重试配置要点（网格侧）
retries:
attempts: 2 # 含首次，重试 1 次
perTryTimeout: 1s # 单次尝试超时
retryOn: connect-failure,reset # 只对幂等且可重试的场景开启
# 关键：应用侧要对同样场景关闭自己的重试
# 否则 2 × 2 = 4 倍的请求量打到下游，故障期间被放大网格不能替代应用层设计：重试与熔断语义仍需与业务幂等、超时预算协同配置，网格只负责按配置执行。
网格层与应用层重试叠加会成倍放大下游压力：上线前必须梳理两层各自的重试策略，明确只有一层对特定错误类型负责重试。