4. 后端发布拓扑概述：蓝绿发布、金丝雀发布、滚动更新、A/B测试场景下的服务网格拓扑

在现代微服务架构中，后端发布拓扑决定了流量如何从旧版本迁移到新版本。不同的发布策略对服务网格中的流量管理、安全拦截与权限校验提出了差异化的要求。本章将系统梳理四种主流发布拓扑，并分析其在服务网格（如 Istio）中的流量路径与拦截器生效位置。

4.1 四种发布策略的核心对比

4.2 服务网格中的通用拓扑结构

无论采用哪种发布策略，服务网格的底层拓扑都遵循统一的 Sidecar 代理模型。每个服务实例旁挂一个 Envoy 代理，所有入站（Inbound）与出站（Outbound）流量均经过该代理。gRPC 拦截器在代理的 L7 过滤器链中执行，负责身份认证、授权校验与审计日志。

4.3 蓝绿发布拓扑

蓝绿发布维护两套完全独立的环境（蓝环境与绿环境）。流量在某一时刻全部指向其中一个环境。切换通过更新服务网格的 VirtualService 权重实现：将 100% 流量从蓝环境瞬间切换至绿环境。

• 拓扑特征： 两套完整服务栈并行运行，数据库需双向兼容或采用双写策略。
• 拦截器影响： 切换瞬间，所有 gRPC 拦截器实例的版本标签（version label）发生变化。安全策略需同时覆盖两个版本，避免切换后出现权限遗漏。
• 回滚操作： 将权重切回 0/100 即可，拦截器无需重新配置。

4.4 金丝雀发布拓扑

金丝雀发布将小比例流量（如 5%）导向新版本，逐步验证稳定性后再全量切换。在服务网格中，通过 DestinationRule 的 weight 字段实现精细化的流量分配。

apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: my-service
spec:
  host: my-service
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2
---
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: my-service
spec:
  hosts:
  - my-service
  http:
  - route:
    - destination:
        host: my-service
        subset: v1
      weight: 90
    - destination:
        host: my-service
        subset: v2
      weight: 10

• 拓扑特征： 新旧版本共存于同一命名空间，通过 subset 区分。金丝雀版本通常只部署少量 Pod。
• 拦截器影响： 拦截器必须根据 version 标签动态加载不同的权限规则。金丝雀版本可能使用更严格的审计策略。
• 渐进式迁移： 权重从 10% → 50% → 100%，每次调整后需验证拦截器日志无异常拒绝。

4.5 滚动更新拓扑

滚动更新是 Kubernetes 原生的默认发布策略。它逐个替换旧版本 Pod，确保服务始终可用。在服务网格中，滚动更新对拓扑的影响最小，因为 Envoy 代理会自动感知 Endpoint 的变化。

• 拓扑特征： 无额外资源消耗，但回滚速度慢（需逐个替换回旧版本）。
• 拦截器影响： 滚动更新期间，同一服务的不同 Pod 可能运行不同版本的拦截器逻辑。建议在更新期间保持拦截器规则向后兼容。
• 健康检查： 滚动更新依赖 Readiness Probe。如果新版本拦截器启动失败，Kubernetes 会阻止流量进入，确保安全。

4.6 A/B 测试拓扑

A/B 测试并非严格意义上的发布策略，而是一种基于请求特征（如 Header、Cookie、地域）的路由方法。在服务网格中，通过 VirtualService 的 match 条件实现。

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: my-service
spec:
  hosts:
  - my-service
  http:
  - match:
    - headers:
        x-ab-group:
          exact: "B"
    route:
    - destination:
        host: my-service
        subset: v2
  - route:
    - destination:
        host: my-service
        subset: v1

• 拓扑特征： 流量不是按比例分配，而是按规则匹配。同一用户在整个测试期间始终访问同一版本。
• 拦截器影响： 拦截器需要解析请求中的 A/B 测试标识（如 x-ab-group Header），并据此执行不同的权限策略。例如，B 组用户可能可以访问实验性 API。
• 数据隔离： A/B 测试通常需要独立的数据存储或数据标记，拦截器应在审计日志中记录测试分组信息。

4.7 拓扑选择对安全拦截器的影响总结