通过摆脱共享环境，团队可以并行测试，从而实现更快、更高质量的发布。
译自 Why Staging Is a Bottleneck for Microservice Testing，作者 Arjun Iyer。
采用微服务架构的工程团队的典型 CI/CD 工作流程如下：
- 在合并拉取请求 (PR) 之前构建并运行基本的单元测试。
- 合并 PR 后，CI/CD 管道将构建部署到共享暂存环境。
- 集成和端到端 (E2E) 测试在此环境中运行，通常按批次安排。
对于每个微服务，每天可能会有多次部署到暂存环境。虽然这种设置已成为常态，但共享暂存环境通常会造成瓶颈，从而减缓团队速度并削弱微服务的优势。让我们深入了解为什么会发生这种情况，以及领先的工程团队如何超越暂存环境来有效地扩展测试。
共享暂存环境的脆弱性
- 一个 PR，多个问题: 当一个团队将带有错误的 PR 部署到暂存环境时，它可能会扰乱整个工程团队。在共享暂存环境中，这个问题会加剧，因为来自一个团队的错误可能会阻止多个其他团队。
- 寻找有问题的 PR 就像大海捞针: 每天合并数百个 PR，找到导致环境崩溃的那个 PR 非常耗时。
- 测试失败含糊不清: 微服务之间的依赖关系使得隔离测试失败的原因变得很困难。例如，考虑以下电子商务微服务架构：
来源：DeathStarBench，一个用于云微服务的开源基准测试套件
在这个架构中，多个服务（如支付、订单、运输和媒体）相互交互。一个服务（如支付服务）的故障可能不会立即显现，并可能表现为订单服务中的问题。这些相互依赖关系使得难以确定测试失败的根本原因，尤其是在涉及多个服务时。调试这种复杂的微服务网络中的故障非常耗时，因为每个服务可能都有不同的团队负责维护它。
- 功能测试变成等待游戏: 多个团队经常等待轮到他们在暂存环境中测试功能。这会造成瓶颈。团队之间共享资源的压力会严重延迟发布，因为他们争夺对暂存环境的访问权限。尝试在本地机器上启动整个堆栈以进行测试的开发人员会遇到类似的问题。正如分布式系统工程师 Cindy Sridharan 指出，“我现在认为，无论是在初创公司还是在大公司，尝试在开发人员的笔记本电脑上启动整个堆栈从根本上来说是错误的思维方式。” 微服务的复杂性使得在本地复制整个环境变得不切实际，就像在规模上维护共享暂存环境很困难一样。
- 来自计划测试的延迟反馈: 自动化测试通常安排在非高峰时段，例如夜间运行。当检测到故障时，可能已经部署了多个 PR，这使得追踪有问题的代码变得更加困难。这会延迟反馈循环，并对生产力造成“时间税”。
连锁反应：减缓工程速度，降低质量
这些问题会导致开发人员生产力大幅下降。CI/CD 管道中的瓶颈会导致他们花费更多时间调试而不是编码。如果您的工程团队每月因暂存环境相关问题而损失数天时间，这对您的速度和士气都是一个严重的打击。
从发布流程的角度来看，脆弱的暂存环境造成的延迟会导致功能和补丁发布速度变慢。当团队花费更多时间修复暂存环境问题而不是构建新功能时，产品开发速度会变慢。在快速发展的行业中，这可能是一个主要的竞争劣势。
如果您的发布流程很痛苦，您发布的频率就会降低，生产环境中错误的成本也会更高。这种放缓也会影响产品质量，因为工程师在压力下为了赶上截止日期，可能会跳过添加新的测试用例。结果是什么？错误会进入生产环境。例如，对于电子商务公司来说，即使是微不足道的错误也会扰乱结账流程，导致收入损失和品牌受损。
最后，还有对开发人员体验的影响。开发人员在能够快速高效地发布代码的环境中茁壮成长。发布流程中的摩擦会让开发人员感到沮丧，增加倦怠和人员流动。快乐的开发人员编写更好的代码，而无摩擦的发布流程是实现这一目标的关键。
为什么暂存环境会崩溃：争用问题
共享预发布环境的核心问题在于竞争。团队无法安全地隔离测试他们的更改。这种隔离的缺乏会导致瓶颈，阻碍团队有效地验证他们的工作。
正如 Sridharan 恰如其分地指出：
作为行业，我们受制于在与我们当前时代截然不同的时代发明的测试方法。Sridharan 的引言
预发布环境是针对单体应用程序设计的，而不是针对微服务的动态、分散的性质。
一种天真的方法可能是创建更多预发布环境，但这也不能很好地扩展。管理多个环境会带来更多复杂性，正如“环境复制不适用于微服务”中所述，跨微服务准确地复制环境极其困难且成本高昂。
更好的方法：隔离测试
那么解决方案是什么？一些最具创新性的科技公司——如 Uber、Lyft 和 DoorDash——已经放弃了共享预发布环境。他们开发了通过沙盒服务和使用动态流量路由来隔离测试的方法。
正如Lyft 博客文章关于预发布覆盖的说明：
“我们从根本上改变了隔离模型的方法：我们不是提供完全隔离的环境，而是在共享环境中隔离请求。”
通过隔离微服务更改，团队可以避免竞争并独立测试代码。这种隔离测试模型消除了共享环境带来的问题，并实现了真正的持续交付。隔离测试允许团队在开发周期的早期发现问题，降低了后期修复错误的复杂性和成本。
隔离测试的实际应用
构建内部系统以实现这种级别的隔离在技术上可能很复杂且成本高昂。但是，像Signadot这样的平台提供了解决方案，可以大规模提供隔离的测试环境。得益于沙盒和流量路由，团队可以安全高效地测试微服务，而无需传统的预发布环境。
结论：微服务测试的未来
预发布环境非常适合单体应用程序，但对于当今的微服务架构来说已经过时了。随着工程团队的规模扩大，共享环境会带来代价高昂的延迟，降低质量并让开发人员感到沮丧。
微服务测试的未来在于隔离测试。通过放弃共享环境，团队可以并行测试，从而实现更快、更高质量的发布。在一个速度、质量和开发人员幸福至关重要的世界里，隔离测试不仅仅是锦上添花——它是必不可少的。
