2023，微服务“水逆”之年。
长期以来，不管大厂还是小厂，微服务都被认为是云原生服务应用程序架构的事实标准，然而2023，不止那位37signals的DHH决心下云，放弃微服务，就连亚马逊和谷歌等这些云巨头，正在带头开始革了微服务的命。
“在编写分布式应用程序时，传统观点认为将应用程序拆分为可以独立推出的独立服务。这种方法的初衷是好的，但像这样基于微服务的体系结构往往会适得其反，带来的挑战抵消了体系结构试图实现的好处。”
今年6月，一群谷歌员工（由谷歌软件工程师Michael Whittaker领导）发表了一篇名为“Towards Modern Development of Cloud Applications”的论文，开篇就对当下的微服务架构开怼。
文章认为，从架构上讲，微服务本身设置就有问题，它是一个没有边界的结构：“从根本上说，这是因为微服务将逻辑边界（如何编写代码）与物理边界（如何部署代码）混为一谈。”
因此，谷歌的工程师们提出了一种堪称“微服务2.0”的方法。将应用程序构建为逻辑整体，但将其交给自动化运行时，后者可以根据应用程序所需的内容和可用的内容来决定在哪里运行工作负载。
基于新提出的结构，他们能够将系统的延迟降低到1/15，成本降低到1/9。
“从有组织的模块化代码开始，我们就可以将部署架构作为实现细节，”google开发人员倡导者Kelsey Hightower在10月份对这项工作表示了下一步计划。
这群谷歌开发者们发现了将应用程序拆分为独立部署的服务方法缺点太明显，并给出了非常有创新性的3条原则：
（1）鼓励开发人员编写分为逻辑组件的单片应用程序（2）将物理分布和执行模块化单片的挑战推迟到运行时（3）原子部署应用程序。
这三个指导原则带来了许多好处，并会为未来的开发创新打开大门。
无独有偶，同样是在6月，亚马逊流媒体平台 Prime Video发布的一则案例研究似乎改变了风向：“我们放弃了无服务器、微服务架构，改用单体架构取而代之，此举为客户节省90%的运营成本，还简化了系统复杂度”。
单体应用对微服务的“反戈一击”，还是亚马逊团队提出来的，再次让这个话题迅速引爆技术圈。
整个案例看下来，微服务跟降本增效似乎也扯不到一起去。问题出在哪里？
Prime Video 团队需要一个监控视频流质量问题的工具，由于视频数量太大，就要求该工具有很强的可扩展性。
最初这项工作是由一组分布式组件完成的，这些组件由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）一针见血地指出：连亚马逊自个都觉得微服务或无服务器“扯淡”了。
最近几年，无数的中小团队在权衡利弊后选择放弃微服务。
Uber 就是其中一家，此前 Uber 通过构建微服务来完成很小的需求或功能，甚至出现很多由一个人构建维护的微服务。这些微服务的存在给Uber带来了更多的挑战，比如监控、测试、持续集成 / 持续交付（CI/CD）、服务级别协议（SLA）等。
踩了微服务的“坑”之后，Uber 团队对新服务进行了更加深思熟虑的规划：不再只是完成一件事，而是使其服务于一项业务功能，由 5-10 个工程师负责维护，还总结出了血泪教训：要在正确的时间选择正确的解决方案来构建产品。
办公管理软件公司 Managed by Q 的应用程序是一个部署在 ECS 上的 Django 单体。为了赶上现代化开发实践的步伐，他们转向微服务架构。但他们很快发现，每多一个新服务，就会增加一些基础设施，而且开发一个跨多个服务的功能需要做更多的工作。
结果，在转向微服务两年之后，他们开始合并微服务。一些微服务被合到了单体中，其他的则合并成较大的服务。他们也在实践中得出经验：不能理所当然地认为微服务就是正确的选择。
本来想把微服务当银弹，结果工程开销太大，得不偿失。以上提到的企业最大的问题是在只有20位工程师的环境中实现了几十个微服务，有种杀鸡焉用牛刀的错位感。
随着越来越多“逃离微服务”的案例发生，人们对于2005年就提出的“微服务”再度审视，甚至批评。
比如开头提到的谷歌工程师们，就在他们的论文中列出了目前微服务方法的缺陷，包括：
性能：通过网络将数据序列化并发送到远程服务会损害性能，如果应用程序变得足够复杂，甚至可能导致瓶颈。
理解追踪：众所周知，在分布式系统中，考虑到微服务之间的许多交互，很难追踪Bug。
管理问题：应用程序的不同部分可以按照自己的时间表进行更新，这被认为是一个优势。但这导致开发人员不得不管理大量的二进制文件，每个二进制文件都有自己的发布时间表。祝您好运，使用本地运行的服务运行端到端测试。
API变得脆弱：微服务互操作性的关键是，一旦建立了微服务，API就不能改变，让它们破坏任何其他依赖API的微服务。因此，API只能用更多的API进行扩展，从而产生膨胀。
看起来跟之前提到的“过度设计”的概念不谋而合。
事实上有些团队在将集中式单体应用拆分为微服务时，首先进行的往往不是建立领域模型，而只是按照业务功能将原来单体应用的一个软件包拆分成多个所谓的“微服务”软件包，而这些“微服务”内的代码高度耦合，逻辑边界不清晰，本质上还是单体架构模式，所以只是实现了“表面繁荣”，并没有实现想要的结果。
正如Sam Newman在《构建微服务》一书中提到的那样，架构需要满足一定的前提条件，否则就可能过度设计。
业内有这样一种依旧支持微服务架构的观点：微服务需要与之匹配的规模。“如果你知道最终会以一定的规模来做这件事，在开始时可能会以不同的方式来构建它。但问题就在于，你知道如何做这件事情吗？你知道你将以多大的规模来运营它吗？”
事实上在许多应用程序中，尤其是内部应用程序，开发成本往往会超过了运行时成本。
谷歌的论文恰恰解决了这个问题，编程模式和部署模式的分开，可以让开发人员更加轻松，同时让运行时基础设施的“赌注”找到运行这些应用程序的最具成本效益的方法。
正如谷歌研究人员所写道的：“通过将所有执行责任委托给运行时，我们的解决方案能够提供与微服务相同的好处，但性能更高，成本更低。”
今年进行了许多基础架构的重新思考，微服务并不是唯一被质疑的泡沫。例如，云计算也受到了审查。
6月，同时运行Basecamp和Hey电子邮件应用程序的37signals公司采购了一批戴尔服务器，并离开了云计算，打破了几十年来大家抛弃老旧拥抱新故事的传统。
David Heinemeier Hansson在一篇博客文章中解释道：“这是云营销的常用话术：它会变得容易得多，几乎不需要任何人来操作。”“（但事实是）我从来没有见过。37signals没有，来自大型互联网公司的人也没有见过。云有一些优势，但它通常不会减少运维人员。”
当然，DHH是一名赛车手，有可能更喜欢裸机。但也有不少拥趸愿意支持这一赌注。今年晚些时候，Oxide Computers推出了他们的新系统，希望能为其他人提供类似的服务：运行云计算工作负载，但在自己的数据中心更具成本效益。
此外，在云账单即将到期的情况下，这种情绪似乎更加强烈。2023年，随着越来越多的组织转向KubeCost等公司来控制其云支出，FinOps成为一件引人注目的事。一位DataDog的客户收到6500万美元的云监控账单的消息，也再次让业界无数人惊到了。
也许对于一个创造数十亿收入的机构来说，6500万美元的可观测性账单可能是值得的。但是对于架构师而言，面对过去十年中做出的工程决策带来的技术债，也许是时候做出一些调整的决定。
当然，微服务也不例外。
京公网安备 11010802035086号