服务网格与 Istio

服务网格是微服务时代的通信基础设施，它将服务间通信的复杂性（流量管理、安全、可观测性）从应用程序中剥离，下沉为统一的平台层能力。本文深入讲解 Service Mesh 架构原理、Istio 核心设计与实践。

1. 为什么需要服务网格

1.1 微服务通信的痛点

没有服务网格时，每个微服务需要自行处理：

服务 A ────────────────────────────→ 服务 B
         │
         ├── 服务发现（Eureka/Consul）
         ├── 负载均衡（Ribbon）
         ├── 熔断降级（Hystrix）
         ├── 超时重试
         ├── 认证鉴权（JWT 验证）
         ├── TLS 加密
         ├── 分布式追踪（TraceID 传递）
         ├── 指标收集（Latency/QPS/Errors）
         └── 灰度发布（按 Header 路由）

问题：
- 每个语言栈都要重复实现一遍
- 业务代码与基础设施代码耦合
- 升级成本高（需修改所有服务）

1.2 服务网格的解决思路

架构演进：

阶段 1：应用内处理      阶段 2：SDK 库       阶段 3：Sidecar 代理     阶段 4：Proxyless
┌────────┐            ┌────────┐           ┌────────┐             ┌────────┐
│ 业务代码│            │ 业务代码│           │ 业务代码│             │ 业务代码│
│ +网络逻辑│            │ + 轻量SDK│          │        │             │ + gRPC  │
└────────┘            └───┬────┘           └───┬────┘             └────────┘
                          │                    │
                     ┌────▼────┐          ┌───▼────┐
                     │ SDK 库   │          │Sidecar │
                     │(多语言)  │          │(Envoy) │
                     └─────────┘          └───┬────┘
                                               │
                                          ┌────▼─────┐
                                          │  网络调用  │
                                          └──────────┘

服务网格 = Sidecar 代理构成的数据平面 + 控制平面（统一配置管理）

2. Service Mesh 架构

2.1 核心组件

                    控制平面（Control Plane）
                    ┌──────────────────────────┐
                    │                          │
                    │  ┌────────┐  ┌────────┐  │
                    │  │ Pilot  │  │ Citadel│  │
                    │  │(xDS服务)│  │(证书管理)│  │
                    │  └────────┘  └────────┘  │
                    │  ┌────────┐  ┌────────┐  │
                    │  │ Galley │  │istiod  │  │
                    │  │(配置校验)│  │(Istio 1.5+│
                    │  └────────┘  │ 单体)   │  │
                    └──────┬───────┴──────────┘
                           │ xDS API (gRPC)
         ┌─────────────────┼─────────────────┐
         │                 │                 │
    ┌────▼────┐      ┌────▼────┐      ┌────▼────┐
    │ Sidecar │      │ Sidecar │      │ Sidecar │
    │ (Envoy) │      │ (Envoy) │      │ (Envoy) │
    └────┬────┘      └────┬────┘      └────┬────┘
         │   数据平面      │                │
    ┌────▼────────────────▼────────────────▼────┐
    │          应用 Pod（业务容器 + Sidecar）     │
    │  ┌──────────┐      ┌──────────┐          │
    │  │ 服务 A    │  ←──→│ Envoy    │          │
    │  └──────────┘ iptables└──────────┘          │
    └─────────────────────────────────────────────┘

数据平面（Data Plane）：Envoy Sidecar 代理，处理所有进出流量
控制平面（Control Plane）：istiod，配置分发、证书管理、策略执行

2.2 Sidecar 流量拦截机制

Pod 内网络流量：

┌─────────────────────────────┐
│           Pod                │
│  ┌──────────┐               │
│  │ App 容器  │──→ iptables ──→ Envoy Sidecar ──→ 目标服务
│  │ (outbound)│   拦截出站    │  (处理 LB/路由/ mTLS)  │
│  └──────────┘               │
│        ↑                    │
│    inbound                  │
│        │                    │
│  ┌─────┴────┐               │
│  │  Envoy   │←── iptables ──┘
│  │  Sidecar │   拦截入站
│  └──────────┘
│
│  iptables 规则（Init Container 设置）：
│    - 出站流量 → 重定向到 Envoy 15001 端口
│    - 入站流量 → 重定向到 Envoy 15006 端口
│    - Envoy 自身流量 → 豁免（避免死循环）
└─────────────────────────────┘

3. Istio 核心功能

3.1 流量管理（Traffic Management）

# VirtualService：定义路由规则
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: reviews-route
spec:
  hosts:
    - reviews
  http:
    - match:
        - headers:
            end-user:
              exact: jason
      route:
        - destination:
            host: reviews
            subset: v2
    - route:
        - destination:
            host: reviews
            subset: v1
          weight: 75
        - destination:
            host: reviews
            subset: v3
          weight: 25

# DestinationRule：定义服务子集和策略
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: reviews-dr
spec:
  host: reviews
  trafficPolicy:
    connectionPool:
      tcp:
        maxConnections: 100
      http:
        http1MaxPendingRequests: 50
    loadBalancer:
      simple: LEAST_CONN
    outlierDetection:
      consecutiveErrors: 5
      interval: 30s
      baseEjectionTime: 30s
  subsets:
    - name: v1
      labels:
        version: v1
    - name: v2
      labels:
        version: v2
    - name: v3
      labels:
        version: v3

流量管理能力：

3.2 安全通信

mTLS（双向 TLS）自动实现：

服务 A          Istio          服务 B
  │              │              │
  │── HTTP ─────→│             │
  │              │── mTLS ─────→│
  │              │  (自动加解密) │
  │              │←─ mTLS ──────│
  │←── HTTP ─────│              │

Citadel 自动管理：
  1. 为每个服务生成证书（SPIFFE 身份）
  2. 证书分发到 Sidecar
  3. 自动轮换证书（短期证书，24小时）
  4. 自动撤销异常证书

三种 mTLS 模式：
  PERMISSIVE：明文和 TLS 都接受（迁移期）
  STRICT：只接受 mTLS（最严格）
  DISABLE：明文通信

3.3 可观测性

# 自动收集的指标（Prometheus 格式）
istio_requests_total{
  reporter="source",
  source_workload="productpage",
  destination_workload="reviews",
  response_code="200",
  request_protocol="http"
}

istio_request_duration_milliseconds_bucket{
  le="100",
  ...
}

# 分布式追踪（自动注入 Trace Headers）
# Envoy 自动处理：
#   x-request-id、x-b3-traceid、x-b3-spanid
# Jaeger/Zipkin 收集完整调用链

# 访问日志（自动输出到 stdout）
{
  "authority": "reviews:9080",
  "bytes_received": 0,
  "bytes_sent": 295,
  "duration": 87,
  "method": "GET",
  "protocol": "HTTP/1.1",
  "response_code": 200,
  "upstream_cluster": "outbound|9080||reviews.default.svc.cluster.local",
  ...
}

4. Sidecar vs Proxyless vs Sidecarless

4.1 三种模式的演进

Sidecar 模式（Istio 默认）：
┌─────────────────┐
│   Pod           │
│  ┌───┐ ┌─────┐ │
│  │App│ │Envoy│ │
│  └───┘ └─────┘ │
│        ↑       │
│   iptables 拦截 │
└─────────────────┘
优点：与应用解耦、透明、无需修改代码
缺点：资源占用（每 Pod 一个 Envoy）、延迟增加 1-3ms

Proxyless 模式（gRPC + xDS）：
┌─────────┐
│   Pod   │
│  ┌───┐  │
│  │App│  │  gRPC 内置 xDS 客户端，直连控制平面
│  └───┘  │  优点：更低延迟、更少资源
└─────────┘  缺点：仅支持 gRPC、需改代码

Sidecarless 模式（Cilium/eBPF）：
┌─────────┐
│   Pod   │
│  ┌───┐  │
│  │App│  │  内核层面处理（eBPF），无 Sidecar
│  └───┘  │  优点：零侵入、高性能、无额外资源
└─────────┘  缺点：需较新内核、功能受限

4.2 模式选择指南

5. Istio 实践要点

5.1 渐进式采用

阶段 1：安装 Istio，PERMISSIVE 模式（兼容明文）
阶段 2：核心服务启用 STRICT mTLS
阶段 3：配置基础流量策略（超时、重试）
阶段 4：启用熔断、故障注入
阶段 5：灰度发布（VirtualService 权重路由）
阶段 6：完整可观测性（Metrics + Tracing + Access Log）

5.2 性能调优

5.3 常见问题

6. 替代方案对比

7. 总结

服务网格本质：
  将"服务如何通信"从"服务做什么"中解耦出来

核心价值：
  1. 流量管理：灰度发布、熔断、超时、重试
  2. 安全：自动 mTLS、策略执行
  3. 可观测性：Metrics、Tracing、Logging 自动生成

采用建议：
  - 微服务数量 > 20 时开始考虑
  - 先小范围试点，再逐步推广
  - 监控 Sidecar 资源消耗
  - 关注 Proxyless/Sidecarless 演进（未来趋势）

演进趋势：
  Sidecar → Proxyless (gRPC) → Sidecarless (eBPF)
  核心不变：控制平面统一管理 + 代理处理流量
  变化的是：代理在哪里运行（用户态 vs 内核态 vs 应用内）