📚 课程目录第3章服务网格基础

3、服务网格基础：Istio流量拓扑、VirtualService、DestinationRule与故障注入

在服务网格（Service Mesh）体系中，Istio 是最具代表性的实现之一。它通过将流量管理、安全、可观测性能力从业务代码中剥离，注入到 Sidecar 代理（Envoy）中，实现了对微服务通信的细粒度控制。本章将聚焦 Istio 流量管理的三大核心抽象：流量拓扑、VirtualService 与 DestinationRule，并介绍如何通过故障注入验证网格的韧性。

3.1 Istio 流量拓扑：从 Sidecar 到全链路

在 Istio 网格中，每个 Pod 都伴随一个 Envoy Sidecar 代理。所有进出 Pod 的流量都被 Sidecar 拦截，并依据控制面（Pilot/istiod）下发的配置进行路由。这种架构将传统的“客户端直连服务端”模式，转变为“客户端 Sidecar → 服务端 Sidecar”的代理转发模式，形成了一张逻辑上的服务网格拓扑。

  关键概念：流量拓扑中的每个节点代表一个服务实例（Pod），每条边代表一条经过 Sidecar 代理的流量路径。控制面通过 xDS 协议动态更新 Sidecar 的路由规则，使得流量拓扑可以实时调整。

SRE 视角：流量拓扑是故障定位的“地图”。当某个服务出现延迟或错误时，通过拓扑可以快速判断是上游调用问题、下游依赖故障，还是 Sidecar 配置错误。Argo CD 事件流可以记录拓扑中每个配置变更的时间点，帮助还原故障时间线。

3.2 VirtualService：流量路由的“交通指挥”

VirtualService 是 Istio 中定义流量路由规则的核心资源。它告诉 Sidecar 如何将请求分发到不同的服务版本、子集或外部服务。可以将其理解为一份“交通指挥手册”，规定了流量应该走哪条路、权重如何分配、超时和重试策略等。

3.2.1 VirtualService 核心字段

字段	作用	常见配置示例
`hosts`	指定路由的目标服务（DNS 名称或 IP）	`hosts: ["reviews"]`
`gateways`	指定规则生效的网关（mesh 表示网格内部）	`gateways: ["mesh", "bookinfo-gateway"]`
`http`	HTTP 流量路由规则列表	包含 match、route、fault、retry 等子字段
`match`	匹配条件（URI、Header、Method、Query 参数）	`uri: prefix: /api/v1`
`route`	目标子集及权重分配	`destination: host: reviews subset: v1 weight: 80`

3.2.2 典型配置：金丝雀发布

以下 VirtualService 将 90% 的流量路由到 reviews 服务的 v1 版本，10% 路由到 v2 版本，实现金丝雀发布：

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: reviews-route
spec:
  hosts:
  - reviews
  http:
  - match:
    - uri:
        prefix: /reviews
    route:
    - destination:
        host: reviews
        subset: v1
      weight: 90
    - destination:
        host: reviews
        subset: v2
      weight: 10

注意：VirtualService 中的 weight 总和必须为 100。如果只配置一个 destination，可以不写 weight（默认为 100）。权重路由基于请求粒度，不保证会话一致性，如需粘性会话需配合 consistentHash 策略。

3.3 DestinationRule：服务子集与负载均衡策略

DestinationRule 定义了 VirtualService 路由目标的具体行为，包括：服务子集（subset）、负载均衡策略、连接池设置、TLS 设置等。如果说 VirtualService 是“交通指挥”，DestinationRule 就是“每个路口的详细通行规则”。

3.3.1 子集定义与版本隔离

通过标签选择器（labels）将同一服务的不同版本划分为子集，供 VirtualService 引用：

apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: reviews-destination
spec:
  host: reviews
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2
  trafficPolicy:
    loadBalancer:
      simple: ROUND_ROBIN
    connectionPool:
      tcp:
        maxConnections: 100
      http:
        http1MaxPendingRequests: 10
        maxRequestsPerConnection: 10

3.3.2 VirtualService 与 DestinationRule 的协作关系

两者必须配合使用才能完成完整的流量管理：

VirtualService 负责“路由决策”：将流量按条件分发到不同的 subset。
DestinationRule 负责“执行策略”：定义 subset 的实例选择、负载均衡、熔断、TLS 等。

  最佳实践：在 Argo CD 中，建议将 VirtualService 和 DestinationRule 放在同一个 Application 或 ApplicationSet 中管理，确保路由规则与后端策略同时生效，避免因配置顺序不一致导致流量黑洞。

3.4 故障注入：验证网格韧性的“混沌工程”

Istio 支持在 VirtualService 中直接定义故障注入（Fault Injection）规则，无需修改应用代码即可模拟延迟和异常。这是 SRE 进行混沌工程、验证系统容错能力的利器。

3.4.1 支持的故障类型

故障类型	字段	说明	典型场景
延迟注入	`fault.delay`	在请求转发前插入固定或百分比延迟	模拟数据库慢查询、网络抖动
中断注入	`fault.abort`	直接返回指定 HTTP 状态码（如 500、503）	模拟服务宕机、依赖故障

3.4.2 故障注入配置示例

以下 VirtualService 对 reviews 服务的 v2 版本注入 5 秒延迟和 50% 概率的 500 错误：

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: reviews-fault-injection
spec:
  hosts:
  - reviews
  http:
  - match:
    - uri:
        prefix: /reviews
    route:
    - destination:
        host: reviews
        subset: v2
    fault:
      delay:
        percentage:
          value: 100
        fixedDelay: 5s
      abort:
        percentage:
          value: 50
        httpStatus: 500

Argo CD 集成提示：故障注入配置可以通过 Argo CD 的 Application 快速部署到指定命名空间。在故障时间线还原中，Argo CD 事件流会记录故障注入规则的创建/更新时间，帮助 SRE 精确判断“故障开始时刻”与“故障恢复时刻”。

3.5 本章小结

流量拓扑是服务网格的骨架，Sidecar 代理构成所有流量路径，控制面动态下发配置。
VirtualService 负责流量路由决策，支持条件匹配、权重分发、超时重试和故障注入。
DestinationRule 定义服务子集和负载均衡策略，与 VirtualService 配合完成端到端流量管理。
故障注入是 SRE 验证网格韧性的核心手段，通过 VirtualService 的 fault 字段即可实现，无需修改业务代码。
在 Argo CD 事件流还原故障时间线时，VirtualService 和 DestinationRule 的配置变更事件是关键的时间锚点。