今时今日的微服务是否比以往的单体应用还臃肿了?

写这篇文章时,我略有一些犹豫,因为其可能会引起一些批评。但尽管如此,我还是告诉自己说,分享观点并没有错误(尽管这些观点可能不太会被很好地接受)。我想在本文中分享对过去的单体应用,以及今时的微服务架构的一些个人经验。

过去的单体应用程序

20 年前,我刚刚开始工作。那时,我在北美的一家大型金融公司工作。该金融机构的中间件平台运行在 CORBA 和 C++ 平台上。那时的 CORBA 已经濒临“灭绝”,所以技术供应商决定不再对 CORBA 提供支持服务。对于企业而言,使用不受支持的技术运行对于业务而言十分关键的中间件平台,这是存在巨大风险的。因此,管理层决定将中间件应用程序移植到与平台无关的技术栈中,为此我们选择了 SOAP 和 Java,这些在当时被认为是很酷炫的选项。言归正传,那时候大约有 500 多个服务运行在这个 C++ 和 CORBA 的技术栈上。所以,公司把所有服务都移植到了 SOAP/Java 技术栈中。这在当时也称得上是业内规模最大的移植工作之一。从那时起,一切为了满足不断增长的业务需求而开发的新服务也都建立在了新的平台上。那么我在这里提到的这次技术迁移,和本文的关系又是什么呢?我是不是有点偏题过度了?并没有…

令人惊讶的一点是,这 500+ 个服务都是根据同一个代码库进行构建的,而且还部署在了同一个 JVM 实例上——这完全符合当今的“单体”架构定义。还有一点非常有趣,前面提到过这 500+ 服务都运行于同意个 JVM 实例,但是,这个实例只用 2GB 的内存(-Xmx)。我在把这样的一个内存大小告诉千禧一代的工程时,他们表示无法相信。一直在问“你确定?你是不是年纪大了?这些事记不太清了?”不过,对此我还是 100% 确信的 :-)。同时公司也准备了多个 2GB 的 JVM 实例来为传入流量提供服务。其中有一些服务设计关键敏感的业务交易,如“列出交易历史”、“资金转移”、“获取账户详细信息”、“获取客户详细信息”…该中间件平台每天需要处理数以百万计的事务,也有着毫秒级的 SLA 要求。

今日的微服务

接下来让我们快进到 20 年后的现在。2021 年的今天,是微服务、容器以及 Kubernetes 的世界。在我的个人职业生涯中,在经历了令人难以置信的斗争和痛苦之后,我总算是建立起了一个“小小的”有些利润的技术公司。我们的公司专业从事构建性能工程工具(GCeasy, HeapHerofastThreadyCrash)的工作。很荣幸,现在也有一些世界一流的企业在使用者我们的工具集。鉴于目前的角色,我有机会看到使用产品的大公司们的架构和部署方式。我可以看到,一些企业要么正在谈论着转向“微服务”架构,要么已经在转向“微服务”架构的过程中。还可以看到,一些企业已经完成了向微服务架构的转移。但这里有点十分明显:其中一些微服务应用程序的内存大小相当大。大体都会在 10GB、20GB…100GB 等等。在 2GB 堆内存下运行的现代企业级应用程序是越来越少见了。除此之外,由于微服务和垃圾回收之间还会存在几次网络跳转,所以整体的响应时间也有所降低。

那么这是否就现代应用程序就比之前的要消耗更多内存呢?这里是一项我们之前发布过的调查研究,其中重点介绍了某世界知名框架的低效率问题

所以我自问了一下:现代/微服务应用程序,其是否会比之前的单体应用程序消耗更多资源呢?我们所处的行业,是否也正朝着正确的方向前进呢?

结论

还是请大家不要将本文的中心思想理解为是反对微服务架构。我非常清楚微服务架构的优势:快速开发、解耦部署、测试周期缩短、多语言编程…在本文中,我只是想表达对于不断增长的内存大小、响应时间及其相关计算成本和复杂性的担忧。在此页欢迎大家分享自己的经验和想法!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Blog at WordPress.com.

Up ↑

%d bloggers like this: