导读：如果你的软件开发团队无法独立地将单个微服务变更推向生产机，那你实际上就没有用上微服务。

微服务的优势其实是让人羡慕的，可以独立部署、团队自主和快速发布。

然而，在与数百个工程团队合作之后，我观察到一个惊人的现象：许多成长型组织虽然采用微服务架构，但发布流程却依然是单一的。

令人不安的事实是：如果你的团队无法独立地将单个微服务变更推送到生产环境，那么实际上并没有微服务，你拥有的却是一个额外复杂的“分布式单体”。

少人谈论的批处理问题

一批拉取请求被合并到暂存区并进行测试，这个过程会导致测试缓慢且反馈延迟。

这种场景似曾相识。工程师们各自独立开发代码，针对模拟代码运行一些本地测试，提交拉取请求并获得批准。拉取请求被合并到主分支，在那里它与其他数十个等待部署的变更合并。

然后等待的游戏便开始了。

这些变更会累积起来，直到有人触发部署到共享环境（通常是集成环境或暂存环境）。全面能力的测试套件会运行，通常需要数小时。不可避免的是，某些变更会中断。但是，是哪个变更中断了呢？是你三天前的 PR 吗？还是别人的？还是多个变更之间的相互作用？

这种神秘的处理案件往往需要数小时甚至数天的调试时间。工程师们需要切换回几天前编写的代码，修复问题，然后重新启动流程。这样的循环在多个环境中重复进行，直到最终代码变更投入生产——通常是在编写完成数周之后。

为什么每个团队最终都会走到这一步？有两个主要限制因素导致了这种批量处理行为：

• 成本和时间：集成测试套件成本高昂且速度缓慢。如果要对 100 多名开发人员的每个 PR 进行完整测试，仅在 CI 时间方面，每月就可能花费 50 万美元以上。
• 环境匮乏：大多数团队只有两到三个共享环境，服务于数十名开发人员。根本没有足够的环境来对单个变更进行独立测试。

这就像驾驶一辆拉着手刹的赛车。你投入了如此多的动力和能力，却最终被看似不可避免的限制所阻碍。

批量发布的真实成本

这种分批测试和发布的方式会带来巨大的隐性成本：

1. 延长交货时间：变更需要几天或几周才能投入生产，从而破坏了微服务承诺的灵活性。
2. “上下文切换税”：被迫重新访问旧代码的工程师每次切换都会遭受 20% 到 40% 的生产力损失。
3. 调试复杂性：在一批 50 多个更改中找到根本原因比在单个 PR 中要困难得多。
4. 质量下降：由于对发布过程的掌控力减少，工程师在测试质量和自动化方面的投入也减少。
5. 失去独立性：团队因发布计划而紧密耦合，从而抵消了微服务的核心优势。

最糟糕的是，这种方法会造成恶性循环。随着发布质量的下降，组织机构会添加更多环境和更多测试阶段，从而进一步减慢发布进程。

打破束缚：测试个人改变

批量测试最明显的方法很简单：单独测试每个代码更改。许多团队已经尝试使用模拟依赖项进行契约测试和集成验证。

模拟非常适合测试负面情况和边缘条件，但它们会带来两个关键问题：持续的维护开销和低保真度反馈。每次服务变更都需要在代码库中更新数十个模拟。更严重的是，模拟会忽略时序问题、网络故障以及实际服务交互中出现的细微行为差异。

所以问题就变成了：是否有可能在不花费太多成本的情况下针对真实环境单独测试每个代码更改？

沙箱解决方案

单个拉取请求将在实时测试环境中进行测试。此流程可实现快速测试并获得早期反馈。

沙箱环境通过提供轻量级隔离，充分利用共享的实时基础设施，彻底改变了这种局面。与其在昂贵的完整环境复制和不切实际的模拟之间做出选择，沙箱提供了第三条路径。

突破在于：当你修改服务 A 时，你的沙箱只会启动服务 A，同时将请求路由到服务 B、C 和 D 的当前实时版本。

这使得能够针对系统的最新实际情况进行全面测试，而不是陈旧的模拟或快照。

工作流程转换：

1. 一名工程师提交了 PR。
2. 沙箱仅使用经过修改的服务自动启动。
3. 多种测试类型可在几分钟内针对真实依赖关系运行——合同测试、集成测试、性能测试、安全扫描。
4. 工程师在代码新鲜时修复问题。
5. 只有经过验证后，PR 才会合并。

值得留意的关键洞察：

沙箱成为左移测试的平台。无需将不同类型的测试分批放入不同的阶段，而是针对每个代码变更，针对实际依赖关系运行相关的测试。不再存在阶段性瓶颈。也不再需要调试数十个批量变更导致的失败。

一家金融科技团队采用这种方法，将投产时间从九天缩短至两小时以内。由于每次故障都能直接追溯到特定的、孤立的代码变更，调试时间几乎降至零。

打破批量习惯

单个变更测试的技术壁垒已经消除。像Signadot这样的现代工具为我们提供了沙盒环境，无需重复基础设施或内部构建复杂的隔离系统，从而为团队节省了数百万的开发成本和数月的工程时间。

微服务承诺了我们的独立性，但大多数团队仍然受制于批量发布，这并非出于技术限制，而是由于组织习惯。做出这一转变的团队交付速度更快、质量更高，软件工程师们也更满意。

前进的道路已经清晰。你的团队会继续错误地实施微服务吗，还是会开始正确实施？

编辑：行动中的大雄

参考：

https://thenewstack.io/why-90-of-microservices-still-ship-like-monoliths/