我对昨天的单体架构和今天的微服务架构的个人经验。
二、昨天的单体应用
对于企业来说，在不受支持的技术上运行其关键任务中间件平台是一个巨大的风险。因此，管理层决定将他们的中间件应用程序移植到独立于平台的技术堆栈：“SOAP”和“Java”，这在当时被认为是很酷的孩子。大约有 50多个服务在这个堆栈上运行。他们将所有这些服务移植到 SOAP/Java 技术中。自那以后，他们为满足不断增长的业务需求而开发的任何新服务也都写在这个新平台上。
令人惊讶的是，所有这 50多个服务都是从一个单一的代码库构建的，并部署在一个单一的 JVM 实例上——完全符合当今“单体”架构的定义。但有趣的是，所有这 50 多个服务都在一个只有 2 GB 内存大小 (-Xmx) 的 JVM 实例上运行。当我现在将这个内存大小告诉一些千禧一代的工程师时，他们无法相信。他们在问“你确定吗？你长大了吗？记忆力衰退了吗？” 我 100% 肯定，我的记忆没有消退:-)。然而，他们有几个 2 GB JVM 实例来服务传入的流量。其中一些服务是关键业务和敏感交易，例如“列出交易历史”、“资金转移”、“获取帐户详细信息”、“获取客户详细信息”……。
今天的微服务
我们现在处于 2021 年的微服务、容器、kubernetes 世界。在我的人事生涯中，在经历了难以置信的挣扎和痛苦之后，我逐渐建立了一个*小*、盈利的技术企业。很荣幸看到世界一流的企业使用我们的工具集。由于目前的角色，我有机会看到使用我们产品的大公司的架构和部署。我可以看到有几家企业正在谈论切换到“微服务”架构，或者已经在切换到“微服务”架构的过程中。我们还可以看到一些企业已经转向微服务架构。但这里的一个敏锐观察是：其中一些微服务应用程序的内存大小非常大。它们在 10 GB、20 GB、... 100 GB 的范围内。越来越难以看到在 2 GB 堆下运行的现代企业应用程序。除此之外，由于微服务和垃圾收集之间的几个网络跃点，响应时间也越来越短.
这是否意味着现代应用程序比其前辈消耗更多内存？这是我们之前发表的一项研究，强调了世界上著名的现代框架之一的低效率。
所以，我问自己：现代/微服务应用程序是否比昨天的单体应用程序消耗更多的资源？我们所走的行业道路是否朝着正确的方向发展？
结论
请不要解释为我在游说反对微服务架构。我非常清楚微服务架构的好处：快速开发、解耦部署、减少测试周期、多语言编程……在这里我只表达对不断增长的内存大小、响应时间及其相关计算成本、复杂性的担忧
