Service Mesh配置预检与自动回滚护栏 - 第1节
1.1 什么是 Service Mesh
Service Mesh（服务网格）是云原生架构中用于处理服务间通信的基础设施层。它通过将通信逻辑从业务代码中剥离，以透明代理的形式注入到服务拓扑中，实现对服务调用的流量管理、可观测性与安全策略的统一管控。
核心价值：开发者无需在业务代码中处理熔断、重试、超时、负载均衡等分布式通信问题，这些能力由 Service Mesh 平台统一提供。
| 维度 | 传统微服务 | Service Mesh 模式 |
|---|---|---|
| 通信逻辑位置 | 嵌入业务代码（如 Spring Cloud 注解） | 独立 Sidecar 代理进程 |
| 策略更新方式 | 修改代码 + 重新部署 | 控制面下发配置，热更新 |
| 语言绑定 | 强绑定（Java、Go 等特定 SDK） | 语言无关，基于 HTTP/gRPC 协议 |
| 运维复杂度 | 随服务数量线性增长 | 由控制平面统一管理，规模效应明显 |
1.2 Sidecar 代理模式
Sidecar 是 Service Mesh 的核心部署单元。每个服务实例旁边都会部署一个独立的代理容器（如 Envoy、Linkerd-proxy），该代理负责拦截该服务实例的所有入站和出站流量。
- 流量拦截：通过 iptables 或透明代理机制，将流量劫持到 Sidecar 端口。
- 协议处理：支持 HTTP/1.1、HTTP/2、gRPC、TCP 等协议，自动解析并注入重试、超时、熔断策略。
- 指标采集：生成请求级别延迟、错误率、吞吐量等黄金指标，上报至可观测性后端。
- 安全通信：自动完成 mTLS 握手与证书轮换，实现服务间加密传输。
关键原则：Sidecar 对业务容器完全透明。业务进程感知不到 Sidecar 的存在，Sidecar 也不修改业务代码的二进制或运行时行为。
1.3 数据平面与控制平面分离
Service Mesh 架构将网络功能拆分为两个正交平面，这是其区别于传统 API 网关或客户端负载均衡库的关键设计。
数据平面（Data Plane）
- 组成：所有 Sidecar 代理实例的集合，直接处理业务流量。
- 职责：流量转发、健康检查、负载均衡、熔断、限流、指标采集、访问日志。
- 特点：无状态、高吞吐、低延迟，通常基于 C++（Envoy）或 Rust（Linkerd-proxy）实现。
控制平面（Control Plane）
- 组成：集中式管理组件，如 Istiod（Istio）、控制面代理（Linkerd）。
- 职责：服务发现、证书签发、策略下发、配置分发、遥测聚合。
- 特点：有状态、负责决策，不参与业务数据路径。
| 对比维度 | 数据平面 | 控制平面 |
|---|---|---|
| 流量路径 | 位于请求路径上，处理每个数据包 | 旁路模式，不接触业务流量 |
| 性能要求 | 极高（纳秒级延迟增加） | 中等（秒级配置下发可接受） |
| 扩缩容方式 | 随业务 Pod 自动扩缩 | 独立部署，通常 2~3 副本 |
| 故障影响范围 | 影响当前服务实例的通信 | 影响全局策略下发，但已有连接不受影响 |
| 典型组件 | Envoy、Linkerd-proxy、MOSN | Istiod、Consul Server、Nacos |
常见误区：控制平面故障不会立即中断已有业务流量。Sidecar 代理本地缓存了最新的路由和证书，即使控制平面短暂离线，数据平面仍能基于缓存继续转发。但新 Pod 注册、策略变更等操作会受阻。