微服务全做错了！谷歌提出新方法，成本直接降为1/9！ _微服务

2023，微服务“水逆”之年。
长期以来，不管大厂还是小厂，微服务都被认为是云原生服务应用程序架构的事实标准，然而2023 ，不止那位37signals的DHH决心下云，放弃微服务，就连亚马逊和谷歌等这些云巨头，正在带头开始革了微服务的命。
01谷歌坐不住了：我们做的微服务都错了！“在编写分布式应用程序时，传统观点认为将应用程序拆分为可以独立推出的独立服务。这种方法的初衷是好的，但像这样基于微服务的体系结构往往会适得其反，带来的挑战抵消了体系结构试图实现的好处。”
今年6月，一群谷歌员工（由谷歌软件工程师Michael Whittaker领导）发表了一篇名为“Towards Modern Development of Cloud Applications”的论文，开篇就对当下的微服务架构开怼。

文章插图
文章认为，从架构上讲，微服务本身设置就有问题，它是一个没有边界的结构：“从根本上说，这是因为微服务将逻辑边界（如何编写代码）与物理边界（如何部署代码）混为一谈。”
因此，谷歌的工程师们提出了一种堪称“微服务2.0”的方法。将应用程序构建为逻辑整体，但将其交给自动化运行时，后者可以根据应用程序所需的内容和可用的内容来决定在哪里运行工作负载。

文章插图
基于新提出的结构，他们能够将系统的延迟降低到1/15，成本降低到1/9 。
“从有组织的模块化代码开始，我们就可以将部署架构作为实现细节，”google开发人员倡导者Kelsey Hightower在10月份对这项工作表示了下一步计划。

文章插图
这群谷歌开发者们发现了将应用程序拆分为独立部署的服务方法缺点太明显，并给出了非常有创新性的3条原则：
（1）鼓励开发人员编写分为逻辑组件的单片应用程序（2）将物理分布和执行模块化单片的挑战推迟到运行时（3）原子部署应用程序。
这三个指导原则带来了许多好处，并会为未来的开发创新打开大门。
02亚马逊Prime Video团队：放弃微服务，改用单体无独有偶，同样是在6月，亚马逊流媒体平台 Prime Video发布的一则案例研究似乎改变了风向：“我们放弃了无服务器、微服务架构，改用单体架构取而代之，此举为客户节省90%的运营成本，还简化了系统复杂度” 。
单体应用对微服务的“反戈一击”，还是亚马逊团队提出来的，再次让这个话题迅速引爆技术圈。
整个案例看下来，微服务跟降本增效似乎也扯不到一起去。问题出在哪里？
Prime Video 团队需要一个监控视频流质量问题的工具，由于视频数量太大，就要求该工具有很强的可扩展性。
【微服务全做错了！谷歌提出新方法，成本直接降为1/9！】最初这项工作是由一组分布式组件完成的，这些组件由AWS Step Functions（一种无服务器编排服务，AWS Lambda无服务器服务）编排，分分钟就能搭出一个有模有样的监控系统。但谁能想到，Step Function 伸缩问题竟然成为最大的绊脚石。
具体来看，一是对于视频流的每一秒，需要很多并发的 AWS Step Function ，所以很快就达到了账户限制；二是 AWS Step Function 是按照状态转换向用户收费的，太贵了实在用不起。
无奈之下，Prime Video开始考虑用单体的解决方案以降低成本和增加应用的扩展能力，在经历了反复试验后，团队最终决定重建Prime Video的整个基础设施。
亚马逊在博客文章总结道：“微服务和无服务器组件是可以大规模工作的工具，但是否在整体上使用它们必须根据具体情况而定……将服务迁移成单体让我们的基础设施成本降低了 90%以上，还提升了我们的伸缩能力。”
这就说明，至少在视频监控领域，单体架构比微服务、无服务器主导的方法产生了更高的性能、更能降本增效。
始终鼓吹下云和反对微服务化的DHH（ Ruby on RAIls创始人，David Heinemeier Hansson）一针见血地指出：连亚马逊自个都觉得微服务或无服务器“扯淡”了。
03放弃微服务的，不止谷歌、亚马逊最近几年，无数的中小团队在权衡利弊后选择放弃微服务。
Uber 就是其中一家，此前 Uber 通过构建微服务来完成很小的需求或功能，甚至出现很多由一个人构建维护的微服务。这些微服务的存在给Uber带来了更多的挑战，比如监控、测试、持续集成 / 持续交付（CI/CD）、服务级别协议（SLA）等。