2. Service Mesh 基础回顾：Sidecar 代理模式、Istio/Envoy 架构、数据面与控制面交互
2.1 Sidecar 代理模式：从侵入式到非侵入式
在传统微服务架构中，服务治理能力（如熔断、限流、服务发现、TLS 终止）通常以 SDK 或框架库的形式嵌入业务进程。这种侵入式模式带来三个核心痛点：
- 语言绑定：SDK 通常只支持特定语言（Java、Go），多语言异构团队被迫重复实现治理逻辑。
- 升级成本高：治理库版本升级需要业务应用重新编译、测试、发布，周期长且风险高。
- 关注点耦合：业务代码与基础设施逻辑混在一起，可读性和可维护性下降。
Service Mesh 通过 Sidecar 代理模式 将治理能力从业务进程中剥离，以独立进程（Sidecar）的形式附加到每个服务 Pod 中。Sidecar 拦截所有进出 Pod 的流量，透明地执行路由、负载均衡、健康检查、TLS 握手、指标采集等操作，业务容器完全无感知。
关键原则：Sidecar 对业务容器是透明的。业务代码只关心业务逻辑，网络通信由 Sidecar 接管。这是实现“非侵入式”治理的基础。
2.2 Istio / Envoy 架构分层
Istio 是目前最主流的 Service Mesh 实现，其架构严格遵循 数据面（Data Plane） 与 控制面（Control Plane） 分离的设计。数据面由 Envoy 代理组成，控制面由 Istiod（Pilot、Citadel、Galley 的整合组件）构成。
2.3 数据面核心：Envoy 代理
Envoy 是 Istio 默认的数据面代理，以 C++ 编写，具备高性能和低资源消耗特性。在 Sidecar 模式下，Envoy 承担以下职责：
| 功能模块 | 说明 | 对容量评估的影响 |
|---|---|---|
| L4/L7 流量拦截 | 通过 iptables 规则将入站/出站流量重定向到 Envoy 监听端口 | 增加网络路径跳数，引入额外延迟（通常 < 1ms） |
| 路由与负载均衡 | 基于 VirtualService/DestinationRule 执行流量路由、权重分发、熔断 | 路由规则数量影响 Envoy 内存占用和匹配性能 |
| mTLS 终止 | 自动为服务间通信启用双向 TLS 加密 | TLS 握手消耗 CPU，长连接复用可缓解开销 |
| 指标与访问日志 | 生成 TCP/HTTP 指标（请求数、延迟、错误码）并上报 | 指标基数（维度组合）影响 Envoy 内存和上报带宽 |
| 健康检查与故障注入 | 主动/被动健康检查，支持延迟/中断故障注入 | 健康检查频率增加控制面与数据面交互 |
容量评估要点：Envoy 的 CPU 消耗主要来自 TLS 加解密和 HTTP 头部解析；内存消耗主要来自连接池、路由表、指标基数。在集群升级前，需要重点评估 Envoy 的 连接数 和 监听器/路由规则数量 是否在预期范围内。
2.4 控制面与数据面交互：xDS 协议
Istio 控制面（Istiod）与数据面（Envoy）之间通过 xDS 协议族 进行配置下发。xDS 是 Envoy 动态配置发现协议的统称，包含以下核心子协议：
- LDS（Listener Discovery Service）：下发监听器配置，定义 Envoy 在哪些端口监听流量。
- RDS（Route Discovery Service）：下发路由规则，定义流量如何匹配和转发。
- CDS（Cluster Discovery Service）：下发集群配置，定义上游服务端点集合。
- EDS（Endpoint Discovery Service）：下发端点列表，定义具体的 Pod IP 和端口。
- SDS（Secret Discovery Service）：下发 TLS 证书和密钥，用于 mTLS 通信。
2.5 交互模式的关键特征
控制面与数据面的交互模式直接影响集群升级时的容量评估策略：
| 特征 | 描述 | 升级影响 |
|---|---|---|
| 最终一致性 | 控制面下发配置后，Envoy 异步应用，不保证强同步 | 升级期间可能出现短暂路由不一致，需设计优雅排空 |
| 增量推送 | Istiod 仅推送变更部分（Delta xDS），而非全量配置 | 减少升级时控制面负载峰值，但需验证增量逻辑正确性 |
| 双向流 | Envoy 与 Istiod 之间维持长连接 gRPC 流 | 升级 Istiod 会导致连接重建，Envoy 需重新请求全量配置 |
| 配置版本化 | 每次配置变更携带版本号，Envoy 通过 ACK/NACK 确认 | 版本不匹配可能导致 Envoy 拒绝配置，影响流量转发 |
升级风险提示：在控制面升级过程中，Envoy 与旧版 Istiod 断开连接后，会立即向新版 Istiod 发起全量 xDS 请求。如果集群规模较大（数千个 Sidecar），同时重建 gRPC 流和全量配置拉取可能导致控制面 CPU/内存瞬时飙升，甚至触发 OOM。这是容量评估必须覆盖的关键场景。
2.6 小结：容量评估的输入基础
理解 Service Mesh 的基础架构后，我们可以提炼出与容量评估直接相关的几个核心输入：
- Sidecar 数量：决定控制面需要管理的代理实例总数，直接影响 xDS 推送的并发度。
- 监听器与路由规则数量：决定 Envoy 配置的复杂度，影响内存占用和配置下发延迟。
- 服务间通信吞吐量：决定 Envoy 的 CPU 消耗（TLS 加解密、头部解析）和连接数。
- 指标基数：决定 Envoy 和 Prometheus 的内存消耗，高基数指标是容量瓶颈的常见来源。
- 控制面连接数：决定 Istiod 的 gRPC 流管理开销，升级时需评估连接重建风暴。