服务网格（Service Mesh）将服务间通信的复杂性从应用层剥离到 Sidecar 代理层，引入 Envoy、Istio 等组件后，测试策略需要覆盖数据平面和控制平面的协同工作。
在银行微服务架构中，服务网格负责服务发现、负载均衡、断路器、流量分割、TLS 加密等关键能力，其正确性直接影响交易链路的稳定性和安全性。
IstioEnvoy流量管理可观测性mTLS| 测试层次 | 测试对象 | 验证内容 |
|---|---|---|
| Sidecar 注入验证 | Pod 中的 Envoy 代理 | Sidecar 是否正确注入、端口转发是否正常、资源限制是否生效 |
| 流量策略测试 | VirtualService / DestinationRule | 金丝雀发布流量比例、超时重试策略、熔断阈值 |
| 安全策略测试 | PeerAuthentication / AuthorizationPolicy | mTLS 是否强制开启、JWT 鉴权是否生效、RBAC 权限控制 |
| 可观测性测试 | 日志/指标/追踪 | Envoy 访问日志、Prometheus 指标采集、Jaeger 链路追踪 |
| 故障注入测试 | FaultInjection 配置 | 延迟注入、HTTP 错误注入是否按预期触发 |
加密合规：金融监管要求服务间通信全程加密，需验证 mTLS 证书的签发、轮换和过期处理机制。测试时需要模拟证书即将过期和已过期的场景。
网络隔离：生产环境通常存在严格的网络隔离策略，服务网格的测试环境需要准确模拟不同网段间的通信规则。
审计追踪：每笔金融交易必须可追溯，需验证 Envoy 访问日志的完整性，确保包含 traceId、spanId 等关键字段。
| 陷阱 | 表现 | 解决方案 |
|---|---|---|
| Sidecar 资源不足 | 高负载下 Envoy 内存溢出导致服务中断 | 压测验证资源限制，设置合理的 requests/limits |
| 配置生效延迟 | 策略变更后部分 Pod 仍使用旧规则 | 添加配置同步等待机制，使用健康检查确认 |
| mTLS 误配置 | 服务间间歇性 503 错误 | 开启 Istio STRICT 模式并全量验证 |
| 追踪采样率过高 | Jaeger 存储压力大，影响性能 | 生产环境使用自适应采样策略 |