Justin-刘清政的博客

python/分布式与微服务/2-单体应用和缺点

2020-05-09

一 单体应用

我们假设,您开始开发一个打车应用。

该新应用是一个模块化的六边形架构,如下图(一个简单的打车应用)所示:

img

该应用的核心是由模块实现的业务逻辑,它定义了服务、领域对象和事件。围绕核心的是与外部世界接口对接的适配器。适配器示例包括数据库访问组件、生产和消费消息的消息组件和暴露了 API 或实现了一个 UI 的 web 组件。

尽管有一个逻辑模块化架构,但应用程序被作为一个单体进行打包和部署。实际格式取决于应用程序的语言和框架。例如,许多 Java 应用程序被打包成 WAR 文件部署在如 Tomcat 或者 Jetty 之类的应用服务器上。其他 Java 应用程序被打包成自包含 (self-contained) 的可执行 JAR。类似地, Rails 和 Node.js 应用程序被打包为有目录层次的结构

以这种风格编写的应用是很常见的。他们很容易开发,因为我们的 IDE 和其他工具就是专注于构建单体应用。这些应用程序也很容易测试, 您可以通过简单地启动并使用如 Selenium 测试包来测试 UI 以轻松地实现端到端 (end-to-end) 测试。单体应用同样易于部署。您只需拷贝打包好的应用程序到服务器上。您还可以通过运行多个副本和结合负载均衡器来扩展应用。在项目的早期阶段,它可以良好运作

二 单体应用的缺陷

成功的应用有一个趋势,随着时间推移而变得越来越臃肿。你的开发团队在每个阶段都要实现更多的用户需求,这意味着需要添加了许多行代码。

几年之后,小而简单的应用将会逐渐成长成一个庞大的单体。例如某团队,他正在编写一个工具,该工具用于从他们的数百万行代码 (lines of code, LOC) 应用中分析出数千个 模块。这是大量开发者在多年齐心协力下创造出了这样的野兽。

一旦您的应用程序成为了一个庞大、复杂的单体,你的开发组织可能会陷入了一个痛苦的境地,敏捷开发和交付的任何一次尝试都将原地徘徊。一个主要问题是应用程序实在非常复杂。对于任何一个开发人员来说显得过于庞大,这是可以理解的。最终,正确修复 bug 和实现新功能变得非常困难而耗时。此外, 这种趋势就像是往下的螺旋。如果基本代码都令人难以理解,那么改变也不会变得正确,您最终得到的将是一个巨大且不可思议的大泥球。

应用程序的规模也将减缓发展。应用程序越大,启动时间越长。一个应用启动时间为 12 分钟,有的甚至40 分钟以上。如果开发人员经常要重启应用服务器,那么很大一部分时间都是在等待中度过,他们的生产力将受到限制。

另一个大问题是,复杂的单体应用本身就是持续部署的障碍。如今, SaaS 应用发展到了可以每天多次将变更推送到生产环境中。这对于复杂的单体来说非常困难,因为您需要重新部署整个应用程序才能更新其中任何一部分。 联想到之前提到的漫长启动时间,这也不会是什么好事。此外,因变更所产生的影响通常不是很明确,您很可能需要做大量的手工测试。因此,持续部署是不可能做到的。

当不同模块存在资源需求冲突时,单体应用可能难以扩展。例如,一个模块可能会执行 CPU 密集型图像处理逻辑,理想情况下是部署在 Amazon EC2 Compute Optimized 实例中。另一个模块可能是一个内存数据库,最适合部署到 EC2 Memory-optimized 实例。然而, 由于这些模块被部署在一起,您必须在硬件选择上做出妥协。

单体应用的另一个问题是可靠性。因为所有模块都运行在同一进程中。任何模块的一个 bug,比如内存泄漏,可能会拖垮整个进程。此外,由于应用程序的所有实例都是相同的,该错误将影响到整个应用的可用性。

最后但同样重要,单体应用使得采用新框架和语言变得非常困难。例如,我们假设您有 200 万行代码使用了 XYZ 框架编写。如果使用较新的 ABC 框架来重写整个应用,这将非常昂贵(在时间和成本方面),即使框架非常好。因此,这对于采用新技术是一个非常大的障碍。在项目开始时, 您无论选择何种新技术都会感到困扰。

总结一下:你有一个成功的关键业务应用程序,它已经发展成为一个只有少数开发人员(如果有的话)能够理解的巨大单体。它使用了过时、非生产性技术编写,这使得招聘优秀开发人员变得非常困难。应用程序变得难以扩展,不可靠。因此敏捷开发和应用交付是不可能的。

使用支付宝打赏
使用微信打赏

点击上方按钮,请我喝杯咖啡!

扫描二维码,分享此文章