通过摆脱共享环境，团队可以并行测试，从而实现更快、更高质量的发布。

采用微服务架构的工程团队的典型 CI/CD 工作流程如下：

对于每个微服务，每天可能会有多次部署到暂存环境。虽然这种设置已成为常态，但共享暂存环境通常会造成瓶颈，从而减缓团队速度并削弱微服务的优势。让我们深入了解为什么会发生这种情况，以及领先的工程团队如何超越暂存环境来有效地扩展测试。

共享暂存环境的脆弱性

在这个架构中，多个服务（如支付、订单、运输和媒体）相互交互。一个服务（如支付服务）的故障可能不会立即显现，并可能表现为订单服务中的问题。这些相互依赖关系使得难以确定测试失败的根本原因，尤其是在涉及多个服务时。调试这种复杂的微服务网络中的故障非常耗时，因为每个服务可能都有不同的团队负责维护它。

连锁反应：减缓工程速度，降低质量

这些问题会导致开发人员生产力大幅下降。CI/CD 管道中的瓶颈会导致他们花费更多时间调试而不是编码。如果您的工程团队每月因暂存环境相关问题而损失数天时间，这对您的速度和士气都是一个严重的打击。

从发布流程的角度来看，脆弱的暂存环境造成的延迟会导致功能和补丁发布速度变慢。当团队花费更多时间修复暂存环境问题而不是构建新功能时，产品开发速度会变慢。在快速发展的行业中，这可能是一个主要的竞争劣势。

如果您的发布流程很痛苦，您发布的频率就会降低，生产环境中错误的成本也会更高。这种放缓也会影响产品质量，因为工程师在压力下为了赶上截止日期，可能会跳过添加新的测试用例。结果是什么？错误会进入生产环境。例如，对于电子商务公司来说，即使是微不足道的错误也会扰乱结账流程，导致收入损失和品牌受损。

最后，还有对开发人员体验的影响。开发人员在能够快速高效地发布代码的环境中茁壮成长。发布流程中的摩擦会让开发人员感到沮丧，增加倦怠和人员流动。快乐的开发人员编写更好的代码，而无摩擦的发布流程是实现这一目标的关键。

为什么暂存环境会崩溃：争用问题

共享预发布环境的核心问题在于竞争。团队无法安全地隔离测试他们的更改。这种隔离的缺乏会导致瓶颈，阻碍团队有效地验证他们的工作。

正如 Sridharan 恰如其分地指出：

预发布环境是针对单体应用程序设计的，而不是针对微服务的动态、分散的性质。

一种天真的方法可能是创建更多预发布环境，但这也不能很好地扩展。管理多个环境会带来更多复杂性，正如“环境复制不适用于微服务”中所述，跨微服务准确地复制环境极其困难且成本高昂。

更好的方法：隔离测试

那么解决方案是什么？一些最具创新性的科技公司——如 Uber、Lyft 和 DoorDash——已经放弃了共享预发布环境。他们开发了通过沙盒服务和使用动态流量路由来隔离测试的方法。

正如Lyft 博客文章关于预发布覆盖的说明：

“我们从根本上改变了隔离模型的方法：我们不是提供完全隔离的环境，而是在共享环境中隔离请求。”

通过隔离微服务更改，团队可以避免竞争并独立测试代码。这种隔离测试模型消除了共享环境带来的问题，并实现了真正的持续交付。隔离测试允许团队在开发周期的早期发现问题，降低了后期修复错误的复杂性和成本。

隔离测试的实际应用

构建内部系统以实现这种级别的隔离在技术上可能很复杂且成本高昂。但是，像Signadot这样的平台提供了解决方案，可以大规模提供隔离的测试环境。得益于沙盒和流量路由，团队可以安全高效地测试微服务，而无需传统的预发布环境。

结论：微服务测试的未来

预发布环境非常适合单体应用程序，但对于当今的微服务架构来说已经过时了。随着工程团队的规模扩大，共享环境会带来代价高昂的延迟，降低质量并让开发人员感到沮丧。

微服务测试的未来在于隔离测试。通过放弃共享环境，团队可以并行测试，从而实现更快、更高质量的发布。在一个速度、质量和开发人员幸福至关重要的世界里，隔离测试不仅仅是锦上添花——它是必不可少的。