一、核心概念

服务网格（Service Mesh） 是一个专用的基础设施层，用于处理服务间通信，使其可靠、快速、安全。

关键特征

  • 透明代理：以 Sidecar 模式注入到每个服务 Pod，应用无感知
  • 非侵入式：业务代码无需修改，治理逻辑下沉到基础设施
  • 统一管控：通过控制平面统一配置流量规则、安全策略
  • 可观测性：自动收集指标、日志、链路追踪

类比：如果微服务是城市中的建筑，服务网格就是统一管理的交通网络（红绿灯、路牌、监控）。

二、架构原理

1. 双平面架构 

┌────────────────────────────────────────┐
│         控制平面（Control Plane）       │
│  ┌──────────┐  ┌──────────┐  ┌───────┐ │
│  │  Pilot   │  │  Citadel │  │ Mixer │ │
│  │(流量管理)│  │(安全认证)│  │(策略) │ │
│  └──────────┘  └──────────┘  └───────┘ │
└────────────────────────────────────────┘
               ↓ (下发配置)
┌────────────────────────────────────────┐
│          数据平面（Data Plane）         │
│  ┌─────────┐      ┌─────────┐          │
│  │ Service │←────→│ Service │          │
│  │    A    │      │    B    │          │
│  └────┬────┘      └────┬────┘          │
│       │ Envoy          │ Envoy          │
│       │ Proxy          │ Proxy          │
│       └────────────────┘                │
└────────────────────────────────────────┘

2. 核心组件（以 Istio 为例）

组件 职责 类比
Pilot 服务发现、流量管理规则下发 交通指挥中心
Citadel 证书管理、身份认证 安检系统
Galley 配置验证和分发 配置仓库
Envoy 数据平面代理，执行流量拦截 路由器

三、核心功能

1. 流量管理

（1）智能路由 

# 虚拟服务示例：根据 Header 路由到不同版本
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
  - reviews
  http:
  - match:
    - headers:
        end-user:
          exact: jason
    route:
    - destination:
        host: reviews
        subset: v2  # 金丝雀发布：特定用户访问新版本
  - route:
    - destination:
        host: reviews
        subset: v1

（2）负载均衡策略

  • 轮询（Round Robin）
  • 最少连接（Least Connection）
  • 一致性哈希（Session Sticky）

2. 安全

（1）双向 TLS（mTLS） 

# 严格模式：强制服务间加密通信
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
spec:
  mtls:
    mode: STRICT

（2）访问控制 

# 授权策略：只允许 order-service 调用 payment-service
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: payment-policy
spec:
  selector:
    matchLabels:
      app: payment
  rules:
  - from:
    - source:
        principals: ["cluster.local/ns/default/sa/order-service"]

3. 可观测性

  • 指标：自动采集 QPS、延迟、成功率（Prometheus）
  • 日志：访问日志自动记录（格式可自定义）
  • 追踪：集成 Jaeger/Zipkin，实现分布式链路追踪
# 自动生成的 Envoy 访问日志
[2025-11-20T15:30:45.123Z] "GET /api/order/123 HTTP/1.1" 200 - 
via_upstream - "-" 45 234 5 4 "-" "Mozilla/5.0" 
"request-id-12345" "order-service:8080" "192.168.1.10:8080"

4. 弹性能力

功能 说明 配置示例
超时控制 防止级联延迟 timeout: 3s
重试 失败自动重试 retries: attempts: 3
熔断 连接池限制 maxConnections: 100
故障注入 混沌工程测试 注入延迟/错误

四、Service Mesh vs 传统微服务治理

对比项 传统方式（SDK 侵入） Service Mesh
实现方式 Spring Cloud、Dubbo 框架 Sidecar 代理（Envoy）
代码侵入 需引入 SDK，修改代码 无侵入，透明注入
语言限制 绑定特定语言（如 Java） 多语言支持（透明代理）
升级成本 重新编译发布应用 只需升级 Sidecar
运维复杂度 业务团队管理 平台团队统一管理
性能损耗 低（进程内调用） 稍高（多一跳网络代理）

适用场景：

  • ✅ 推荐用 Service Mesh：多语言异构系统、微服务规模大（>50）、需要统一治理
  • ❌ 不推荐：简单系统、对延迟极度敏感（如超高频交易）

五、主流实现对比

产品 厂商 特点 社区活跃度
Istio Google/IBM 功能最全、生态丰富 ⭐⭐⭐⭐⭐
Linkerd Buoyant 轻量级、Rust 实现 ⭐⭐⭐⭐
Consul Connect HashiCorp 与 Consul 服务发现集成 ⭐⭐⭐
AWS App Mesh AWS 深度集成 AWS 生态 ⭐⭐⭐

国内现状：

  • 阿里云 ASM（基于 Istio）
  • 腾讯云 TCM
  • 华为云 ASM

六、实际应用案例

场景 1：灰度发布（金丝雀） 

# 90% 流量到 v1，10% 流量到 v2
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: product-service
spec:
  hosts:
  - product-service
  http:
  - route:
    - destination:
        host: product-service
        subset: v1
      weight: 90
    - destination:
        host: product-service
        subset: v2
      weight: 10

场景 2：故障注入测试 

# 为 20% 的请求注入 5 秒延迟
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: payment-service
spec:
  hosts:
  - payment-service
  http:
  - fault:
      delay:
        percentage:
          value: 20.0
        fixedDelay: 5s
    route:
    - destination:
        host: payment-service

七、性能与成本考量

1. 性能影响

  • 延迟增加：每次请求多一跳代理（约 1-3ms）
  • 资源占用：每个 Pod 增加 Envoy 容器（约 50-100MB 内存）

优化建议：

# 调整 Envoy 资源限制
resources:
  requests:
    cpu: 100m
    memory: 128Mi
  limits:
    cpu: 500m
    memory: 512Mi

2. 学习成本

  • 需要理解 Kubernetes、CRD（自定义资源）
  • YAML 配置复杂（建议用 Kustomize/Helm 管理）

八、答题总结

回答框架（2 分钟）：

  1. 定义：服务网格是微服务通信的基础设施层，Sidecar 模式透明代理
  2. 核心价值：
    • 非侵入治理（无需修改代码）
    • 多语言支持（跨语言统一）
    • 统一管控（流量、安全、观测）
  3. 架构：控制平面（Pilot/Citadel）+ 数据平面（Envoy）
  4. 典型功能：
    • 流量管理（灰度发布、A/B 测试）
    • 安全（mTLS、访问控制）
    • 可观测（自动采集指标）
  5. 对比 Spring Cloud：
    • SDK 侵入 → Sidecar 透明
    • 语言绑定 → 语言无关
  6. 主流实现：Istio（首选）、Linkerd

加分点：

  • 提及 Envoy（数据平面事实标准）
  • 说明适用场景（多语言、大规模）
  • 指出局限性（性能损耗、运维复杂度）

延伸问题：

  • Istio 的性能瓶颈在哪里？如何优化？
  • 服务网格和 API 网关有什么区别？
  • 如何在生产环境逐步迁移到 Service Mesh？