如何使用代理路由在单个环境中测试分布式系统

如果没有专门的 QA 环境，团队在测试分布式系统时将面临技术和协调问题。一个缓慢的、难以维护的 CLI 导致一个组织向左移，采用自动化测试。他们使用 CI 和代理路由构建了一个用于版本化部署的工具，使开发人员能够在多个版本上运行隔离测试，以尽早地发现错误。

Po Linn Chia 在波士顿开发峰会上解释了他们如何重用一个开发环境来部署多个服务版本，以测试他们的分布式系统。

Chia 说，没有专门的 QA 环境会导致很多问题，无论是技术方面还是团队方面，因为一切都是社会技术性的。她补充说，这个方程的社会部分总是很难，可能比技术部分更难。

他们的测试基础设施由大量微服务和单个 ECS 开发环境集群组成。在他们的团队中，人们争夺同一个微服务，或者一个微服务影响另一个微服务的行为。

他们之前投资了一个自主开发的命令行界面程序，该程序可以在一个持续集成运行器上运行整个环境，但结果是，在运行测试之前，需要 15-30 分钟才能启动框架。还有由于超时导致的构建失败，系统的开发人员离开了公司，没有人知道如何维护它。

然后他们决定的解决方案是向左转移，采用自动化测试，并优先考虑工具和协调。这将帮助他们尽早发现错误，Chia 说。它将是一个环境，但上面有多个版本，他们使用持续集成来运行集成测试。

他们开发了一个内部部署工具，让工程师选择他们想要部署或关闭的版本：

在底层，我们使用所需的版本启动适当的 ECS 任务，并注册了带有代理（Traefik）的条件路由规则，该代理可查看 Baggage 头。Baggage 头应该包含一个特殊的键/值对 dynamic_route=VERSION ，表示客户端想要访问的版本，否则它将回退到路由到服务的 main 版本。

他们将 APM 数据、自定义指标和日志发送给各种第三方提供者，Chia 说。对于单一部署的多个版本，他们会更新元数据，如服务名称、已部署版本，并发送 Baggage 头，以便他们可以跟踪请求链路并单独监控部署。

他们的集成测试现在正在进行中，开发人员可以启动他们的临时容器并编写集成测试。团队可以在 CI 之外按需部署，以测试更大的东西，如 React 框架的升级，而不会干扰开发前端，Chai 说。

她提到，他们还连接了架构，以便开发人员可以在共享存储库中编写服务，或者只在自己的存储库中编写服务，并且可以来回移动。

InfoQ 采访了Po Linn Chia，以了解他们的测试环境。

InfoQ：你是如何在一个环境中切换到不同版本的？

Po Linn Chia：我们内部称之为“动态路由”，其中应用程序代码和 DNS 不需要修改——只需要代理规则。

 

举例说明：如果通过 http://my-service.classpass.com 访问服务的主版本，则没有指定行 Baggage 头的流量默认会路由到那里。将 Baggage: dynamic_route=feature-2981 作为头的请求将根据部署 feature-2981 时添加的 Traefik 路由规则进行计算，并将其发送到该版本的服务。

InfoQ：你是如何进行遥测的？它给你带来了什么好处？

Chia：对多个部署的遥测让我们能够区分特定版本的缺陷和性能问题，与主版本运行的问题分开。我们还没有达到在生产中执行金丝雀部署的阶段，所以这是我们朝着那个方向努力的简化版本。

 

它非常有用：例如，有时我们不得不发布大的变更集，这些变更集很难或不可能以小单位进行测试，当我们这样做时，能够单独监控和调试版本，同时保持稳定的最新版本在我们的开发环境中运行，这提高了我们的 QA 工作，并减少了对我们工程师的干扰。我们已经通过这种方式进行了几次大型框架的主要版本升级。

InfoQ：测试人员什么时候会使用共享仓库，什么时候更喜欢使用自己的仓库？

Chia：由于我们采用的微服务架构，我们的核心业务流程由多个底层应用程序提供服务。如果某个测试对这些类型的某个流程非常关键，将其放在共享存储库中是有帮助的——参与这些流程的服务可以触发这些共享测试，而不必在他们自己的存储库中重新发明轮子。缺点是测试需要设置和编写得非常好；失败会影响多个团队。在同一个存储库中进行开发工作并在另一个存储库中编写测试也稍微困难一些。

 

另一方面，如果一个应用程序是相当独立的，那么将测试放在自己的仓库中会很方便，也更容易进行迭代。这与编写共享测试是相反的。归根结底，工程师会对何时将测试提取到共享位置做出判断——他们可能会先在应用程序代码库中编写测试，然后意识到它可能普遍有用，之后再将其移出。

原文链接：

https://www.infoq.com/news/2025/10/testing-distributed-system/