这是一个可能对您有用的社区

一对一沟通/面试手册/简历优化/求职问题，欢迎加入“知识星球”。以下是提供的部分信息：

这是一个开源项目，可能对您有用

国内Star是一个10万+的开源项目。前端包括管理后端+微信小程序，后端支持单体和微服务架构。

功能涵盖RBAC权限、SaaS多租户、数据权限、商城、支付、工作流、大屏报表、微信公众号、CRM等功能：

【国内首批】支持JDK 21+ 3.2.2、JDK 8 + Boot 2.7.18双版本

写 |言语如烟

2023年是微服务的“水逆”年。

长期以来，微服务无论大小，都被认为是云原生服务应用架构事实上的标准。然而，到了2023年，不仅DHH决心上云、放弃微服务，亚马逊、谷歌等云公司也决心上云。巨头们正在带头革新微服务。

“在编写分布式应用程序时，传统观点是将应用程序拆分为可以独立推出的独立服务。这种方法的初衷是好的，但像这样的基于微服务的架构常常适得其反，带来的挑战抵消了架构试图实现的好处。

今年 6 月，一群 员工（以 软件工程师为首）发表了一篇名为《of》的论文，文章首先批评了当前的微服务架构。

文章认为，从架构的角度来看，微服务的设置存在问题。它是一种没有边界的结构：“从根本上来说，这是因为微服务将逻辑边界（如何编写代码）与物理边界（如何部署代码）混合在一起。”

因此，工程师提出了一种称为“微服务2.0”的方法。将应用程序构建为一个逻辑整体，但将其留给自动化运行时，该运行时可以根据应用程序的需求和可用内容来决定在哪里运行工作负载。

基于新提出的结构，他们能够将系统延迟降低15倍，成本降低9倍。

“从有组织的模块化代码开始，我们可以将架构部署为实现细节，” 在 10 月份谈到后续工作时说道。

这群开发者发现将应用拆分成独立部署的服务的缺点太明显，并给出了三​​个非常创新的原则：

(1) 鼓励开发人员编写分为逻辑组件的单体应用程序 (2) 将模块化单体应用程序的物理分配和执行挑战推迟到运行时 (3) 以原子方式部署应用程序。

这三个指导原则带来了许多好处，并将为未来的发展创新打开大门。

基于Boot+Plus+Vue实现的后台管理系统+用户小程序，支持RBAC动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能

无独有偶，同样是在 6 月，亚马逊流媒体平台发布的一个案例研究似乎改变了趋势的方向：“我们放弃了 和微服务架构，代之以单体架构。此举为客户节省了 90% 的运营成本，并且还简化了系统复杂性。”

亚马逊团队提出单体应用对微服务的“反击”，再次让这个话题在科技圈迅速炸开。

纵观整个案例，似乎微服务和降本增效并没有什么关系。有什么问题吗？

该团队需要一种工具来监控视频流质量问题。由于视频数量如此之大，因此该工具需要具有高度可扩展性。

最初，这项工作是由一组分布式组件完成的，这些组件由AWS Step（一种无服务器编排服务，AWS无服务器服务）编排，几分钟内就可以构建一个功能监控系统。但谁能想到，Step 的扩展问题却成为了最大的绊脚石。

具体来说，首先，视频流的每一秒都需要大量并发的AWS ，因此很快就会达到账户限制；其次，AWS Step根据状态转换向用户收费，成本太高，无法使用。 。

无奈之下，团队开始考虑使用单一解决方案来降低成本并提高应用程序的可扩展性。经过反复尝试，团队最终决定重建整个基础设施。

亚马逊的博客文章总结道：“微服务和无服务器组件是可以大规模工作的工具，但是否将它们作为一个整体使用必须根据具体情况而定……将服务转移到整体中可以让我们降低基础设施成本。它增加了 90% 以上，并且还提高了我们的可扩展性。”

这表明，至少在视频监控领域，单体架构比微服务和无服务器主导的方法产生更高的性能，并且可以降低成本并提高效率。

一直主张迁移到云、反对微服务的DHH（Ruby on创始人）一针见血地指出：就连亚马逊自己也认为微服务或是“无稽之谈”。

基于+++++Vue实现的后端管理系统+用户小程序&支持RBAC动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能

近年来，无数中小型团队在权衡利弊后选择放弃微服务。

优步就是其中之一。此前，Uber 构建微服务来完成小型需求或功能。甚至有很多微服务是一个人构建和维护的。这些微服务的存在给Uber带来了更多的挑战，比如监控、测试、持续集成/持续交付（CI/CD）、服务水平协议（SLA）等。

踏入微服务的“坑”后，Uber 团队对新服务做了更周到的规划：不再仅仅完成一件事，而是让它服务于业务功能，并由 5-10 名工程师维护。也总结了血泪的教训：在正确的时间选择正确的解决方案来打造产品。

Q 的办公管理软件公司的应用程序是部署在 ECS 上的整体应用程序。为了跟上现代开发实践，他们转向了微服务架构。但他们很快发现，每一项新服务都会添加一些基础设施，并且跨多个服务开发功能需要更多的工作。

因此，在转向微服务两年后，他们开始合并微服务。一些微服务被组合成整体，另一些则被合并成更大的服务。他们也在实践中获得了经验：不能想当然地认为微服务是正确的选择。

本来想用微服务作为灵丹妙药，但项目成本太高，得不偿失。上述公司最大的问题在于，他们在只有20名工程师的环境中实施了数十个微服务，感觉像是在浪费时间。

随着越来越多“逃离微服务”的案例发生，人们正在重新审视甚至批评2005年提出的“微服务”。

例如，开头提到的 工程师在论文中列出了当前微服务方法的缺点，包括：

性能：通过网络序列化数据并将其发送到远程服务可能会损害性能，如果应用程序变得足够复杂，甚至可能导致瓶颈。

了解跟踪：在分布式系统中，由于微服务之间存在大量交互，因此跟踪错误非常困难。

管理问题：应用程序的不同部分可以按照自己的时间表进行更新，这被认为是一个优势。但这导致开发人员必须管理大量二进制文件，每个二进制文件都有自己的发布时间表。祝您使用本地运行的服务运行端到端测试好运。

API 变得脆弱：微服务互操作性的关键在于，一旦建立了微服务，API 就无法更改，从而允许它们破坏依赖于该 API 的任何其他微服务。因此，只能用更多的API来扩展API，从而造成臃肿。

这似乎与之前提到的“过度设计”的概念不谋而合。

事实上，当一些团队将集中式单体应用拆分为微服务时，他们做的第一件事往往不是建立领域模型，而是根据业务将原有单体应用的软件包拆分为多个所谓的“微服务”功能。服务”软件包，而这些“微服务”中的代码耦合度高，逻辑边界不清晰，本质上是一个单体架构模型，因此只实现了“表面繁荣”，并没有达到预期的效果。

正如 Sam 在《构建微服务》一书中提到的，架构需要满足一定的先决条件，否则可能会被过度设计。

业界有一种观点仍然支持微服务架构：微服务需要与规模相匹配。 “如果你知道最终会达到一定的规模，你可能会在一开始就以不同的方式构建它。但问题是，你知道如何去做吗？你知道你会以什么规模去做吗？规模化经营吗？

事实上，在许多应用程序中，尤其是内部应用程序，开发成本常常超过运行时成本。

谷歌的论文正是解决了这个问题，将编程和部署模式分开，使开发人员的工作变得更容易，同时让运行时基础设施“赌注”找到运行这些应用程序的最具成本效益的方式。

正如谷歌研究人员所写：“通过将所有执行职责委托给运行时，我们的解决方案能够提供与微服务相同的优势，但具有更高的性能和更低的成本。”

今年对基础设施进行了许多重新思考，微服务并不是唯一受到质疑的泡沫。例如，云计算也受到了密切关注。

今年 6 月，这家还运行 Hey 电子邮件应用程序的公司购买了一批戴尔服务器，并放弃了云计算，打破了数十年来抛弃旧事物、拥抱新事物的传统。

“这是云营销中的常见说法：它将变得更加容易，几乎不需要任何人来操作，”在一篇博客文章中解释道。 “[但事实是]我从未见过这种情况。不，大互联网公司的人也没见过。云有一些优势，但通常不会减少运营人员。”

当然，DHH 是一名赛车手，可能更喜欢裸机。但也有很多粉丝愿意支持这个赌注。今年晚些时候，微软将推出他们的新系统，希望为其他人提供类似的服务：运行云计算工作负载，但在自己的数据中心更具成本效益。

此外，随着云账单即将到期，这种情绪似乎更加强烈。 2023 年是值得关注的一年，因为越来越多的组织转向其他公司来控制其云支出。一位客户收到6500万美元云监控账单的消息再次震惊了无数业内人士。

对于一个产生数十亿收入的机构来说，6500 万美元的可观测性费用也许是值得的。但对于建筑师来说，面对过去十年做出的工程决策的技术债务，可能是时候做出一些调整了。

当然，微服务也不例外。

参考链接：

欢迎加入我的知识星球，全面提升你的技术能力。

如需加入，请“长按”或“扫描”下面的二维码：

的内容包括：实际项目实践、面试招聘、源码分析、学习路线。

文章有帮助的话，在看，转发吧。

谢谢支持哟 (*^__^*）