为什么90%的微服务仍然像单体应用一样交付

还在像单体应用一样发布微服务？小心！独立部署才是真“微服务”。文章揭示批量发布的成本黑洞，力荐“沙箱环境”方案，利用轻量级隔离和实时基础设施，实现单个PR的快速测试和左移测试，提升DevOps效率，Signadot等工具助力摆脱批量习惯，释放Microservices的真正潜力！

译自：Why 90% of Microservices Still Ship Like Monoliths

作者：Arjun Iyer

微服务的承诺非常诱人——独立的部署、团队的自主性和快速的发布。然而，在与数百个工程团队合作之后，我观察到一个惊人的模式：许多成长中的组织拥有微服务架构，但发布过程却是单体式的。

这里有一个令人不舒服的事实：如果你的团队不能独立地将单个微服务更改推送到生产环境，那么你实际上并没有微服务。你拥有的是一个具有额外复杂性的分布式单体应用。

无人提及的批量处理问题

合并到暂存环境并进行测试的一批拉取请求。此过程导致测试缓慢和反馈延迟。

这种情况非常熟悉。工程师们孤立地开发代码，针对模拟对象运行一些本地测试，提交拉取请求并获得批准。PR 被合并到主分支，在那里它与等待部署的其他几十个更改汇合。

然后等待游戏就开始了。

这些更改会累积起来，直到有人触发到共享环境（通常是集成或暂存环境）的部署。全面的测试套件运行，通常需要几个小时。不可避免地，会出现问题。但是哪个更改导致了问题？是三天前的你的 PR 吗？还是别人的？还是多个更改之间的交互？

这个谋杀之谜会消耗数小时或数天的调试时间。工程师们切换回几天前编写的代码，修复问题并重新启动该过程。这个循环在多个环境中重复进行，直到最终更改到达生产环境——通常是在编写完成后的几周。

为什么每个团队最终都会走到这一步？两个主要约束驱动着这种批量处理行为：

这就像开着手刹驾驶赛车。你已经投资了所有的这些力量和能力，却发现它被看似不可避免的约束所阻碍。

这种批量测试和发布方法带来了巨大的隐藏成本：

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

批量测试的显而易见的解决方案很简单：单独测试每个代码更改。许多团队已经尝试使用模拟依赖项进行合同测试和集成验证。

模拟对于测试负面情况和边缘情况非常有效，但它们会产生两个关键问题：持续的维护开销和低保真反馈。每次服务更改都需要更新代码库中的数十个模拟。更重要的是，模拟会遗漏时序问题、网络故障以及在实际服务交互中出现的细微行为差异。

因此，问题变成了：是否有可能针对真实环境单独测试每个代码更改而不会产生过高的成本？

针对实时暂存环境测试的单个拉取请求。此过程产生快速测试和早期反馈。

沙箱环境通过提供利用共享的、实时基础设施的轻量级隔离来改变这个等式。沙箱提供了第三条路径，而不是在昂贵的完整环境复制或不切实际的模拟之间进行选择。

这里的突破是：当您修改服务 A 时，您的沙箱仅启动服务 A，同时将请求路由到当前、实时的服务 B、C 和 D 版本。这使得能够针对您系统的最新实际情况进行全面测试，而不是陈旧的模拟或快照。

工作流程转变：

关键的见解：沙箱成为左移测试的平台。您针对每个代码更改，对真实依赖项运行相关的测试，而不是将不同的测试类型分批处理到不同的阶段。不再有暂存瓶颈。不再需要在数十个批处理更改中调试故障。

一个金融科技团队使用这种方法将其产品上市时间从 9 天减少到 2 小时以内。调试时间几乎降至零，因为每个故障都可以直接追溯到特定的、隔离的代码更改。

单个更改测试的技术障碍已经消除。像 Signadot 这样的现代工具提供了沙箱环境，而无需复制基础设施或内部构建复杂的隔离系统，从而为团队节省了数百万美元的开发成本和数月的工程工作。

微服务向我们承诺了独立性，但大多数团队仍然受到组织习惯的束缚而进行批量发布，而不是受到技术限制。进行这种转变的团队正在以更高的质量和更快乐的工程师更快地交付产品。

前进的道路是明确的。您的团队是会继续以错误的方式进行微服务，还是开始以正确的方式进行微服务？