在类生产环境中使用流量镜像调试和测试微服务

介绍

传统上，流量镜像与安全和网络监控相关联——这种技术允许安全工具在不中断主流的情况下检查网络流量的副本。然而，今天它已经远远超出了这一角色。组织现在通过在非面向客户的环境中重放生产流量，使用流量镜像来测试和调试微服务。

通过将真实用户请求的副本重定向到服务的并行版本，可以获得大量类似于生产的数据，用于识别难以捉摸的缺陷、验证新特性和分析性能。

关键在于，用户只接收来自主服务的可信输出，而次要（或影子）服务以静默方式处理流量。

在现代微服务生态系统中，容器、Kubernetes 集群和服务网格占主导地位，这种技术变得更加易于访问。像AWS VPC流量镜像这样的云产品和Istio这样的服务网格解决方案简化了实现，使得 SRE、平台团队和软件工程师都可以毫无风险的情况下进行实时流量调试。

本文解释了流量镜像在云原生环境中的工作原理，探讨了实际的实施策略，并回顾了用例、安全注意事项和操作权衡。

到文章结束时，读者将了解如何将这种方法不仅作为安全工具，而且作为增强微服务架构中测试和可观测性的手段。

技术深入：流量镜像的工作原理

在其核心，流量镜像复制传入请求，这样，当一个副本由主（或“基线”）服务提供时，另一个副本被发送到在测试或预发环境中运行的相同服务。镜像服务的响应永远不会返回给客户端；它的存在仅仅是为了让工程师观察、比较或处理来自实际使用的数据。

镜像流量有几种实现技术，大致可分为以下几类：

1. 应用层（L7）镜像

服务网格，比如 Istio，使用 sidecar 代理（通常是 Envoy）来拦截 HTTP 或 gRPC 调用。通过简单的路由配置，可以指示代理将每个传入请求的副本发送到第二个“影子”服务。在这种设置中，客户端只看到来自实时服务的响应，而镜像副本则是独立处理的。

图 1：基本流量镜像设置

这种方法在已经使用 Istio 或其他服务网格的 Kubernetes 环境中工作得很好。可以进一步配置要镜像的流量百分比，仅针对特定的端点或请求类型。

2. 网络层（L4）镜像

在网络层面，云提供商提供数据包级别的镜像功能。例如，AWS VPC 流量镜像从 EC2 实例的网络接口复制数据包，并将其发送到镜像目标——通常是另一个 EC2 实例或负载均衡器。由于这种方法在应用层以下运行，所以它与协议无关；然而，可能需要额外的工具来将数据包重新组装成完整的请求以进行分析。网络层镜像场景示意图如下：

图 2：网络层的流量镜像

这种方法减少了应用程序本身的开销，因为镜像发生在基础设施层。然而，它通常会产生原始数据包数据，需要额外的处理来重构完整的应用层请求。

3. DIY 和专业技术

除了标准的服务网格和云网络功能之外，组织还可以使用各种专业工具和技术实施自定义的流量镜像解决方案。

一个值得注意的例子是eBPF（扩展的 Berkeley 数据包过滤器），这是 Linux 内核中的一项强大的技术，允许用户空间程序连接到内核的各个点并执行自定义逻辑。工程师可以使用 eBPF 程序高效地捕获网络数据包，执行复杂的过滤，并根据特定标准选择性地镜像流量。使用 eBPF 可以实现细粒度镜像策略，这是通用工具所不能提供的。例如，eBPF 程序可以仅为由唯一标头或元数据标识的特定用户或事务镜像流量。

其他 DIY 技术可能涉及编写自定义脚本，利用如 tcpdump 这样的工具进行数据包捕获，然后将流量重放到目标服务。也可以使用网络分流器等专业硬件解决方案来物理复制网络流量以用于镜像目的。这些技术提供了灵活性和潜在的更高的性能，但代价是增加了开发工作量和复杂性。DIY 和专业技术对于有特定镜像要求的组织或在没有服务网格或云提供功能的环境中运营的组织来说，可能是有价值的替代方案。

1. 混合方法

高级实现可能会混合使用这两种方法。例如，一个团队可能会使用服务网格来处理 HTTP 流量，同时依赖于 VPC 级别的镜像来处理低级别的 TCP 流量，并且还可能使用 eBPF 程序来专门过滤和镜像某些连接类型。无论选择哪种方法，共同的主题都是异步的、“即发即弃”的请求复制，而不会影响客户体验。

实现策略

Istio 的服务网格镜像

许多 Kubernetes 部署使用 Istio 来管理服务之间的通信。使用 Istio， VirtualService 可以将 100%的流量从生产环境镜像到影子版本。例如，考虑这个简化的配置片段：

apiVersion: networking.istio.io/v1kind: VirtualServicemetadata:  name: payment-servicespec:  hosts:  - payment.example.com  http:  - route:    - destination:        host: payment-v1      mirror:        host: payment-v2      mirrorPercentage:        value: 100.0

在这个配置中，所有 HTTP 请求都由 payment-v1 （基线）提供服务，并将副本发送到 payment-v2 。可以调整 mirrorPercentage 来控制镜像流量的大小。这种方法不需要修改代码，完全依赖于服务网格配置。

入口控制器和基于代理的解决方案

如果使用像NGINX这样的入口控制器，可以使用其内置的指令启用流量镜像。NGINX 的 mirror 指令配置一个后端来接收传入请求的副本。下面是一个简化的例子：

server {  listen 80;  location /api/ {    proxy_pass http://primary_service;    mirror /mirror;    mirror_request_body on;  }  location /mirror {    internal;    proxy_pass http://shadow_service;  }}

这种配置确保每个到达 /api/ 的请求首先传递给主服务，同时副本内部路由到影子服务进行日志记录或测试。即使微服务运行在 EC2 实例或非 Kubernetes 设置中，也可以应用这种方法。

云网络镜像

在 AWS 中，可以设置VPC流量镜像来在弹性网络接口（Elastic Network Interface，ENI）级别复制流量。首先，创建一个流量镜像目标（例如，AWS 网络负载均衡器）来接收重放流量。然后，在源实例上设置流量镜像会话。AWS 的文档详细描述了这个过程。尽管这种方法在应用层以下运行，但它可以在不能修改应用程序配置或不能添加边车的情况下使用。

流量回放工具

对于那些不使用服务网格的人来说，像GoReplay这样的专用工具可以捕获和重放流量。GoReplay 监听一个定义的端口，并将传入的 HTTP 请求复制到指定的目标。它甚至支持过滤和采样，如果需要一个轻量级的独立解决方案，这是一个灵活的选择。许多团队将 GoReplay 集成到他们的部署管道中，以便每个新的微服务版本在影子模式下接收真实的生产流量。

流量镜像用例

调试难以复现的缺陷

现实世界的流量是混乱的。某些缺陷只有在请求包含特定的 API 调用序列或意外的数据模式时才会出现。通过将生产流量镜像到影子服务，开发人员可以在受控环境中捕获这些难以复现的缺陷。例如，假设一个微服务偶尔在特定的有效载荷下失败。在这种情况下，其镜像副本可以记录触发失败的输入，允许团队稍后复现和诊断问题。

真实工作负载下的性能分析

合成负载测试不能轻易捕捉到实时用户行为的细微差别。镜像生产流量允许团队观察新服务版本如何处理与其前身相同的负载。这种测试对于识别响应时间或资源利用方面的回归特别有用。团队可以比较主服务和影子服务之间的 CPU 使用率、内存消耗和请求延迟等指标，以确定代码更改是否会对性能产生负面影响。

无风险地测试新功能

在推出新功能之前，开发人员必须确保它在生产条件下正确工作。流量镜像允许在部署带有特性标志的新微服务版本的同时，仍然服务于来自稳定版本的请求。影子服务处理真实请求，并记录其输出以供审查。这种“在生产环境中测试”的方法允许团队验证新功能是否符合预期，而不会冒停机或用户体验差的风险。一旦有了信心，团队可以逐渐将流量转移到新版本上。

回归检测

在重构或迁移微服务时，确保新更改不引入回归至关重要。团队可以通过将所有生产流量镜像到新服务并将其输出与稳定版本进行比较来自动检测差异。一些组织构建自动化工具来比较相同镜像请求的响应，标记任何意外的差异以供审查。

负载测试和自动扩缩验证

镜像环境可以模拟新服务副本上的负载条件。这对于容量规划和测试自动扩缩策略特别有用。你可以单独扩展镜像服务，并观察它如何处理突发的请求。它验证了在现实流量模式下，扩缩规则是否适当触发，而不是依赖于人为生成的负载。

安全及隐私考虑

保护敏感数据

镜像流量是真实的生产数据，可能包括个人身份信息（PII），如用户名、支付详情或会话令牌。团队应实施即时的删除或掩码以遵守法规（例如，GDPR）并保护用户隐私。例如，团队可以配置服务网格或入口代理，在数据到达影子服务之前剥离敏感的标头并擦除有效载荷字段。

隔离镜像环境

确保影子服务在完全隔离的环境中运行。不允许它写入生产数据库或与实时下游系统交互。相反，将其指向依赖服务的预发版本或使用虚拟端点。这可以防止意外的副作用（例如重复事物）并保护数据完整性。

安全访问和监控

应该严格控制对镜像数据的访问。像对待生产环境一样对待影子环境：加密存储的日志，使用访问控制和审计跟踪，并监控异常。在云原生环境中，确保网络策略限制镜像目标和外部服务之间的通信。定期审查镜像配置，确认只有预期的流量被复制。

安全处理副作用

镜像服务可能会无意中触发如发送电子邮件或推送通知之类的操作。为了防止这种情况，使用请求头（例如， X-Shadow-Request: true ），以便下游系统识别调用来自影子服务并绕过副作用。将影子环境配置为在外部集成存根或禁用的“试运行”模式下运行。

现实世界的案例研究：验证支付服务迁移

考虑一个受真实实践启发的假设示例：一家名为 FinServ Corp 的金融科技公司将其支付处理服务从旧的基于 Java 的版本（v1）迁移到新的基于 Go 的微服务（v2）。鉴于支付处理的关键性质，公司使用流量镜像来确保其顺利推出。

服务迁移的设置和镜像策略

• 环境：FinServ Corp 在 Amazon EKS 上运行其服务。

• 镜像配置：使用 Istio，团队配置了一个 VirtualService ，以便稳定的 v1 处理 100%的生产支付请求。同时，50%的请求被镜像到新的 v2 服务。

• 隔离：影子服务（v2）使用预发数据库和假支付网关，确保没有实时事务发生。

• 数据清洗：Istio 过滤器链从指向 v2 的请求中删除敏感字段（例如，信用卡号）。

• 监控：团队为 v1 和 v2 设置了单独的仪表板，实时比较延迟、错误率和关键事务指标。

图 3：使用流量镜像的服务 Rollout

结果：通过流量镜像识别问题并进行纠正

在几个小时内，监控系统就会标记 v2 在地址字段中包含带有国际字符的交易验证错误——这是一个在部署前测试时没有发现的错误。工程师检查日志并迅速修补新的验证库。后来，性能指标显示 v2 具有更好的平均响应时间，但尾部延迟略高。这种差异促使进一步的查询优化，确保 v2 满足生产标准。

FinServ Corp 逐渐将镜像百分比提高到 100%，在实际负载下建立对 v2 的信心，并执行完整的金丝雀发布。部署后分析信用流量镜像，尽早发现细微问题，最终实现无缝迁移，保护用户事务并提高系统性能。

权衡和运维考虑

虽然流量镜像提供了显著的优势，团队还必须考虑几个权衡：

• 基础设施开销：镜像会复制流量，因此影子环境必须进行扩展以容纳额外的负载。使用采样（例如，10-50%镜像）来平衡可见性和成本。

• 性能影响：在使用高效代理（如 Envoy）时，应用层镜像增加的开销很小，但网络级镜像可能会增加带宽使用。密切监控系统指标，确保生产性能不会降低。

• 工具复杂性：在服务网格、入口控制器和云平台之间集成和维护镜像配置需要协调。自动化和全面日志记录有助于减少这种运维负担。

• 数据同步和状态：确保影子服务接收到适当的状态数据。使用只读副本或预发数据库为下游服务提供支持。

• 预警疲劳：由于镜像请求会产生日志和度量指标，因此设计监控时要专注于可操作的异常而不是噪声。适当地设置阈值，以便只有在出现重大差异时才向团队发出预警。

尽管存在这些权衡，但通过仔细规划、自动化和逐步增加镜像流量，可以缓解大多数问题。投资的回报在于降低风险、提高了对部署的信心，最终实现更具弹性的微服务架构。

结论

流量镜像已经从一种网络安全工具发展为一种使用真实世界数据调试和测试微服务的强大方法。通过安全地将生产流量复制到影子环境，团队可以复制难以捉摸的缺陷，分析实际负载下的性能，验证新功能，并检测回归，确保生产环境保持隔离，用户体验不受影响。然而，这种精确性是有代价的：需要仔细编排网络探针或服务网格配置，增加基础设施以吸收镜像负载，以及严格的保护措施以防止有状态的副作用。

相比之下，蓝绿部署通过维护两个并行的生产机群（蓝色和绿色）来简化切换，将流量路由到一个机群，同时构建另一个。这种方法在最小化停机时间和回滚复杂性方面表现出色。尽管如此，它缺乏对新代码在高峰或异常流量模式下行为的细粒度洞察，因为您只使用真实流量的子集或金丝雀部分进行测试。

金丝雀发布则走的是中间路线：它们将一小部分实时流量引导到新版本上，允许团队在广泛发布之前监控关键指标（延迟、错误率）。虽然比全面镜像更容易实施，但金丝雀只能在有限的流量切片中发现问题，对于检测低频或特定区域的问题效果较差。

最后，传统的性能测试（负载或压力测试）可以使用合成流量生成器模拟高容量场景，但这些工具难以模拟真实用户行为的全部多样性——会话模式、复杂的事务流程以及由外部事件触发的突然峰值。

对于现代软件工程师、SRE 和平台团队来说，流量镜像仍然是保证与实时流量 1:1 保真度的唯一方式，代价是更大的设置复杂性和资源开销。它允许你在现实条件下测试你的系统，捕捉到合成测试遗漏的问题，并更自信地对关键服务进行迭代。重要的是，它扩展了熟悉的“在生产环境中测试”的概念，而不会将客户暴露于风险之中。随着组织继续采用微服务和容器化基础设施，将流量镜像作为测试和调试策略的核心部分，不仅有益，而且至关重要。

通过重新思考流量镜像的传统安全角色，并利用其实时质量保证的潜力，你可以构建更具弹性和可靠性的系统。拥抱这种方法——计划安全的数据处理，选择正确的工具，并开始实验。从真实流量中获得的洞察将加强你的部署，减少代价高昂的生产故障，并最终带来更顺畅、响应更快的用户体验。

原文链接：

https://www.infoq.com/articles/microservices-traffic-mirroring-istio-vpc/