如何通过Envoy parallel filter实现请求镜像且不影响主链路性能

这个场景的核心原则是主服务A的链路完全和观测服务B解耦，B的任何性能波动、可用性故障都绝对不能影响A的正常响应，基于Envoy的原生能力按以下方式配置即可满足要求：

• 优先使用Envoy原生的请求镜像（Request Shadowing）能力实现流量副本转发，不要自定义Lua脚本/外部插件做转发
  原生镜像策略采用*发后即忘（fire-and-forget）*的异步逻辑：Envoy接收下游请求后，会同时将请求副本发往服务B，主链路仅等待服务A的响应返回给客户端，服务B的所有响应包会被Envoy直接丢弃，既不会透传给下游，也不会阻塞主链路的处理流程，从机制上避免B拖慢A的响应。
  基础路由配置参考如下：

  route_config:
    name: core_service_route
    virtual_hosts:
    - name: service_a_vhost
      domains: ["*"]
      routes:
      - match: {prefix: "/"}
        route:
          cluster: service_a_prod_cluster # 主链路指向服务A集群
          timeout: 30s # 主链路超时仅和服务A相关，不受服务B影响
          request_mirror_policies:
          - cluster: service_b_observe_cluster # 镜像流量指向服务B集群
            runtime_fraction:
              default_value:
                numerator: 100
                denominator: HUNDRED # 配置100%全量镜像
            trace_sampled: false # 镜像请求默认不采样链路追踪，减少额外开销
  

• 为服务B集群配置独立的隔离限流、熔断规则，彻底阻断故障传导
  哪怕是异步镜像请求，如果对B的连接堆积、资源占用过高，也可能挤占Envoy本身的工作资源，因此必须给服务B对应的集群单独配置严苛的资源阈值：

  • 给B集群设置极短的独立超时，比如timeout: 1s，超过时间直接断开镜像连接，不等待慢响应
  • 配置低阈值的熔断规则：根据B的实际承载能力设置最大连接数、最大并发待处理请求数，超出阈值直接丢弃新的镜像请求，绝不排队等待
  • 为B集群分配独立的连接池，和服务A的连接池资源完全隔离
  • 关闭镜像请求的自动重试逻辑，B请求失败直接丢弃，不做无意义的重试消耗资源

• 给镜像请求添加特殊标识，避免脏数据
  在发往B的镜像请求中追加专用请求头x-envoy-mirrored-request: true，服务B侧识别到该请求头后，仅执行日志记录、流量观测类操作，不触发任何业务写逻辑，避免镜像请求干扰业务数据。

• 监控指标做链路隔离
  单独统计镜像发往B的请求成功率、延迟、丢弃率指标，用于观测B的运行状态，这部分指标异常不纳入核心业务SLA统计，也不触发主链路的告警规则。

注意：不要在主请求的HTTP处理过滤链中加入任何依赖服务B响应的逻辑，所有和B的交互全部走原生镜像流程，才能保证主链路零阻塞。

内容的提问来源于stack exchange，提问作者Mohammad Mahdi Setak