服务网格
→ 返回 云原生
Service Mesh 解决微服务间（东西向）流量的治理问题，将服务通信的控制逻辑从业务代码中剥离。
为什么需要 Service Mesh
微服务增多后，每个服务都要自己实现：
- 超时 / 重试 / 熔断
- 负载均衡
- mTLS 加密
- 链路追踪
- 灰度发布
Service Mesh 将这些能力下沉到基础设施层，业务代码无感知。
Sidecar 模式
┌──────────────────────┐
│ Pod │
│ │
│ ┌────────────────┐ │
│ │ app-container │ │
│ └────────────────┘ │
│ ▲ │ │
│ 入流量│ │出流量 │
│ │ ▼ │
│ ┌────────────────┐ │
│ │ Envoy Sidecar │ │
│ └────────────────┘ │
│ ▲ │ │
└─────────┼──┼─────────┘
│ │
所有流量经过 Sidecar
每个 Pod 自动注入一个 Envoy 代理，所有进出流量均由 Envoy 处理，业务容器无需修改。
Istio 架构
┌────────────────────────────────────────────┐
│ Control Plane │
│ │
│ ┌──────────────────────────────────────┐ │
│ │ istiod │ │
│ │ │ │
│ │ Pilot（流量管理配置下发） │ │
│ │ Citadel（证书管理 / mTLS） │ │
│ │ Galley（配置验证） │ │
│ └──────────────────────────────────────┘ │
└───────────────────┬────────────────────────┘
│ xDS 协议下发配置
▼
┌────────────────────────────────────────────┐
│ Data Plane │
│ │
│ Pod A Pod B │
│ [app][envoy] ──────► [envoy][app] │
│ │
└────────────────────────────────────────────┘
istiod 统一管理三个功能：
- Pilot：将 VirtualService / DestinationRule 等配置转换为 Envoy 配置并下发
- Citadel：为每个服务颁发证书，实现 mTLS
- Galley：校验 Istio 配置正确性
核心能力
流量管理
VirtualService：定义路由规则
# 90% 流量到 v1，10% 到 v2（金丝雀发布）
http:
- route:
- destination:
host: order-service
subset: v1
weight: 90
- destination:
host: order-service
subset: v2
weight: 10DestinationRule：定义负载均衡策略、熔断阈值
trafficPolicy:
loadBalancer:
simple: LEAST_CONN
outlierDetection:
consecutive5xxErrors: 5
interval: 10s
baseEjectionTime: 30s熔断
服务 A → 服务 B
↑
Envoy Sidecar 检测到：
连续 5xx > 阈值 或 延迟过高
│
熔断器打开
│
快速失败（不等待超时）
│
30s 后半开探测
重试 / 超时
retries:
attempts: 3
perTryTimeout: 2s
retryOn: "5xx,reset,connect-failure"
timeout: 10smTLS（双向 TLS）
服务 A 服务 B
│ │
│ ← 证书由 Citadel 颁发 →│
│ │
└──── 双向 TLS 加密 ──────┘
所有服务间通信自动加密，Zero Trust 网络的基础。
流量镜像
将生产流量复制一份发送到测试服务，不影响主链路：
请求 → 主服务（返回响应）
│
└── 镜像 → 影子服务（忽略响应）
主流 Service Mesh 对比
| 方案 | 数据面 | 特点 |
|---|---|---|
| Istio | Envoy | 功能最全，复杂度高 |
| Linkerd | Linkerd2-proxy（Rust） | 轻量，性能好，简单 |
| Consul Connect | Envoy | Hashicorp 生态 |
| Cilium | eBPF | 内核级，无 Sidecar，性能最强 |
| AWS App Mesh | Envoy | AWS 托管 |
eBPF 无 Sidecar 方案
传统 Sidecar 的问题：每个 Pod 多一个 Envoy 容器，增加资源消耗和延迟。
Cilium 基于 eBPF 在内核层拦截流量，无需 Sidecar：
Pod A ──► eBPF Hook（内核层）──► Pod B
（流量策略在内核执行）
代表未来 Service Mesh 的发展方向。