Service Mesh 策略治理：配置多了，也会变成事故源

Service Mesh 策略治理：配置多了，也会变成事故源

一、网格配置不是越多越安全

Service Mesh 提供流量治理、mTLS、熔断、重试、限流、镜像流量等能力。能力强是一回事，配置多是另一回事。多个 VirtualService、DestinationRule、AuthorizationPolicy 叠在一起，很容易让团队不知道真实流量会怎么走。

网格策略治理的核心，是让配置可读、可测、可回滚。

二、先梳理策略类型

flowchart TD A[Mesh 策略] --> B[流量路由] A --> C[安全认证] A --> D[重试熔断] A --> E[可观测性]

不同策略有不同风险。流量路由影响访问路径，安全认证影响可用性，重试熔断影响下游压力，观测配置影响排障能力。

mesh_policy_catalog: traffic: owner_required security: security_review_required retry: load_test_required

策略要分类治理，而不是所有 YAML 都一样 review。

三、配置要能预演

istioctl analyze

上线前至少做静态检查，发现冲突、无效引用、端口错误、策略未生效等问题。更进一步，可以在预发环境跑流量回放，验证策略是否符合预期。

不要直接在生产里试重试策略。AI 模型服务和高成本接口尤其怕重试风暴，网格层重试要保守。

四、策略要有 owner 和过期时间

临时灰度、临时放行、临时镜像流量最容易变成永久配置。每条策略都应该有负责人、目的和过期时间。

policy_metadata: owner: platform-team reason: canary-release expire_at: "2026-07-12"

过期后自动提醒或清理，能减少策略堆积。配置堆得越多，真正事故时越难判断哪条生效。

还要建立变更审计。谁改了流量比例，谁打开了 mTLS，谁调整了重试次数，都要能查。网格问题经常不是代码 bug，而是一条配置改错。

最后，Mesh 策略要和应用策略合并看。应用 SDK 有重试，网格也有重试，网关还有重试，叠加起来可能很吓人。总预算必须统一。

网格策略还需要环境分层。开发、预发、生产可以共享模板，但不能共享所有参数。生产的重试次数、超时、熔断阈值应更保守，预发可以更激进地验证策略。

mesh_env_overlay: base_policy: shared production: retry_attempts: 1 timeout: 3s staging: retry_attempts: 2

还要做策略差异审计。预发验证通过的配置，生产是否真的一致？如果中间有人手改 YAML，灰度结果就没有参考价值。

最后，策略治理最好接入 GitOps。所有网格策略通过 PR 变更、自动分析、审批和发布，能减少直接改生产配置带来的不确定性。

策略还要有运行时验证。配置分析通过，不代表真实流量符合预期。可以在灰度期间对比访问日志、mTLS 握手失败、重试次数和 upstream reset，确认策略没有引入新问题。

mesh_runtime_validation: check_mtls_error: true check_retry_count: true check_route_distribution: true

对于模型服务，要特别限制重试。一次失败请求如果已经进入模型推理，网格自动重试可能制造额外成本和重复输出。业务层更懂哪些错误可重试。

最后，网格策略文档要面向服务 owner，而不是只给平台团队看。服务 owner 不理解策略含义，就无法判断某次变更是否安全。

五、总结

Service Mesh 策略治理要分类管理、上线前分析、配置预演、owner 归属、过期清理和审计。

配置多了，也会变成事故源。网格的强大能力，需要同样强的治理。