历史总会重演。一切刚过去的，又会被重新提起。开源项目Codename One的联合创始人Shai，曾是Sun Microsystems开源LWUIT项目的共同作者，参与了无数开源项目。作为最早一批Java开发者，最近感慨道：单体，又回来了！
Shai说道：我已经在这个圈子里很久时间了，看到了一次次被抛弃、被重新发现的想法，超越"时髦词汇"，并凯旋而归。
他进一步举例，"近年来，SQL也挣扎过后，死而复生。我们再次热爱关系数据库。我认为单体架构将再次迎来奇幻之旅。微服务和无服务器是云供应商推动的趋势，目的当然是在向我们兜售更多的云计算资源。然而对于大多数用例来说，微服务在财务上意义不大。是的，供应商当然也可以降低成本。但当他们扩大规模时，他们会以股息来覆盖掉成本。单是可观测性成本的增加，就让'大型云'供应商的腰包鼓起来了！"
作为从业近30年的资深技术大神，为何做此感叹？本文通过一场"利用模块降低架构成本"的探讨，帮助大家梳理现在的架构设计难题，希望对诸君有所启发。
1、问题背景
我最近领导了一个会议小组，讨论了微服务与单体服务的主题。组内认为，单块的规模不如微服务。这对于亚马逊、eBay等所取代的那些庞然大物来说可能是正确的。这些确实是巨大的代码库，其中的每一次修改都是痛苦的，而且它们的扩展都是具有挑战性的。但这不是一个公平的比较。较新的方法通常优于旧的方法。但如果我们用更新的工具构建一个整体，我们会得到更好的可扩展性吗？它的局限性是什么？现代的单体（也称巨石）到底该是什么样子？
2、单体回归范例：Modulith
Spring Modulith是一个模块化的单体结构，可以让我们使用动态隔离件构建单体结构。通过这种方法，我们可以分离测试、开发、文档和依赖项。这有助于微服务开发的独立方面，而所涉及的开销很少。它消除了远程调用和功能复制（存储、身份验证等）的开销。
Spring Modulith不是基于Java平台模块化（Jigsaw）。他们在测试期间和运行时强制分离，这是一个常规的Spring Boot项目。它有一些额外的运行时功能，可以实现模块化的可观测性，但它主要是"最佳实践"的执行者。这种分离的价值超出了我们通常使用微服务的价值，但也有一些权衡。
举个例子，传统的Spring monolith将采用分层架构，其包如下：
com.debugagent.myapp
com.debugagent.myapp.services
com.debugagent.myapp.db
com.debugagent.myapp.rest
这很有价值，因为它可以帮助我们避免层之间的依赖关系；例如，DB层不应依赖于服务层。我们可以使用这样的模块，并有效地将依赖关系图推向一个方向：向下。但随着我们的成长，这没有多大意义。每一层都将充满业务逻辑类和数据库复杂性。
有了Modulith，我们的架构看起来更像这样：
com.debugagent.myapp.customers
com.debugagent.myapp.customers.services
com.debugagent.myapp.customers.db
com.debugagent.myapp.customers.rest
com.debugagent.myapp.invoicing
com.debugagent.myapp.invoicing.services
com.debugagent.myapp.invoicing.db
com.debugagent.myapp.invoicing.rest
com.debugagent.myapp.hr
com.debugagent.myapp.hr.services
com.debugagent.myapp.hr.db
com.debugagent.myapp.hr.rest
这看起来非常接近一个合适的微服务架构。我们根据业务逻辑分离了所有部分。在这里，可以更好地控制交叉依赖关系，团队可以专注于自己的孤立区域，而不必互相踩脚。这是微服务的价值之一，且没有开销。
我们可以使用注释进一步深入地和声明性地实现分离。我们可以定义哪个模块使用哪个并强制单向依赖关系，因此人力资源模块将与发票无关。客户模块也不会。我们可以在客户和发票之间建立单向关系，并使用事件进行反馈。Modulith中的事件是简单、快速和事务性的。它们消除了模块之间的依赖关系，无需麻烦。这可以用微服务实现，但很难实现。比如，开票需要向不同的模块公开接口。如何防止客户使用该界面？
有了模块，我们就可以做到。对用户可以更改代码并提供访问权限，但这需要经过代码审查，这会带来自己的问题。请注意，对于模块，我们仍然可以依赖常见的微服务，如功能标志、消息传递系统等。您可以在文档和Nicolas Fränkel的博客中阅读有关Spring Modulith的更多信息。
模块系统中的每个依赖项都被映射并记录在代码中。Spring实现包括使用方便的最新图表自动记录所有内容的能力。你可能会认为，依赖性是Terraform的原因。对于这样的"高级"设计来说，这是正确的地方吗？
对于Modulith部署，像Terraform这样的基础设施即代码（IaC）解决方案仍然存在，但它们会简单得多。问题是责任的划分。正如下图所展示，微服务并没有消除整体结构的复杂性。我们只把"难啃的骨头"踢给了DevOps团队。更糟糕的是，我们没有给他们正确的工具来理解这种复杂性，所以他们不得不从外部管理。
这就是为什么我们行业的基础设施成本在上升，而传统行业的基础设施价格却在下降。当DevOps团队遇到问题时，他们会投入资源。这显然不是正确的做法。
3、其他模块
我们可以使用标准Java平台模块（Jigsaw）来构建Spring Boot应用程序。这样做的好处是可以分解应用程序和标准Java语法，但有时可能会很尴尬。当使用外部库或将一些工作拆分为通用工具时，可能会更有效。
另一个选项是Maven中的模块系统。这个系统允许我们将构建分解为多个单独的项目。这是一个非常方便的过程，可以让我们省去大量项目的麻烦。每个项目都是独立的，易于使用。它可以使用自己的构建过程。然后，当我们构建主项目时，这些全部都变成了一个单体。在某种程度上，这才是我们真正想要的。
4、单体架构：扩展，有解吗
可以使用大多数微服务扩展工具来扩展我们的单体们。许多与扩展和集群相关的开发都是在单体架构的情况下进行的。这是一个更简单的过程，因为只有一个移动部分：应用程序。我们复制其他实例并观察它们。没有哪项服务是失败的。我们有细粒度的性能工具，所有的功能都可以作为一个统一的版本。
我认为扩展单体为微服务比直接构建微服务更简单------
- 我们可以使用分析工具，并获得瓶颈的合理近似值。
- 我们的团队可以轻松地（并且经济实惠地）设置运行测试的登台环境。
- 我们拥有整个系统及其依赖关系的单一视图。
- 我们可以单独测试单个模块并验证性能假设。
跟踪和可观测性工具非常棒。但它们也会影响生产，有时还会产生噪音。当我们试图解决伸缩瓶颈或性能问题时，这些工具可能会让设计者踩一些坑。
我们可以将Kubernetes与monolits一起使用，就像将其与微服务一起使用一样有效。镜像尺寸会更大（如果我们使用GraalVM这样的工具，则可能不会太大）。有了这一点，我们可以跨区域复制monolith ，并提供与微服务相同的故障转移行为。相当多的开发人员将monolics部署到Lambdas。笔者不太喜欢这种方法，因为非常昂贵。
5、单体的瓶颈问题：有解
但仍有一点是巨大的障碍：数据库。由于微服务固有地具有多个独立的数据库，因此它们实现了巨大的规模。单体架构通常与单个数据存储一起工作。这通常是应用程序的真正瓶颈。有多种方法可以扩展现代数据库。集群和分布式缓存是强大的工具，可以让我们达到在微服务架构中很难达到的性能水平。
在一个单体结构中，也并不需要单个数据库。例如：在使用Redis进行缓存时，选择使用SQL数据库也是很常见的事情。但我们也可以为时间序列或空间数据使用单独的数据库。我们也可以使用单独的数据库来提高性能，尽管根据笔者经验，这种情况从未发生过。将数据保存在同一数据库中的好处是巨大的。
6、回归单体的好处
事实上，这样做有一个惊人的好处，我们可以在不依赖"最终一致性"的情况下完成交易。当我们尝试调试和复制分布式系统时，可能会遇到一个很难在本地复制的过渡状态，甚至很难通过查看可观测性数据来完全理解。
原始性能消除了大量网络开销。通过适当调整的二级缓存，我们可以进一步删除80-90%的读IO。在微服务中，要实现这一点要困难得多，而且可能不会删除网络调用的开销。
正如我之前提到的，应用程序的复杂性在微服务架构中不会消失。我们只是把它搬到了另一个地方。所以从这个层面讲，微服务并不算真正的进步，因为在此过程中平白添加了许多移动部件，增加了整体复杂性。因此，回归更智能、更简单的统一架构更有意义。
7、再看微服务的卖点
编程语言的选择是微服务亲和力的首要指标之一。微服务的兴起与Python和JavaScript的兴起相关。这两种语言非常适合小型应用程序，对于较大型的应用就不太适用了。
Kubernetes使得扩展此类部署相对容易，因此为已经增长的趋势增添了动力。微服务也有一些相对快速的升降能力。这可以以更细粒度的方式控制成本。在这方面，微服务被出售给组织，作为降低成本的一种方式。
这并非完全没有优点。如果以前的服务器部署需要强大（昂贵）的服务器，那么这一论点可能有一定道理。这可能适用于极端使用的情况，比如：突然面临非常高的负载，但随后没有堵塞。在这些情况下，可以从托管的Kubernetes提供商动态（廉价）获取资源。
微服务的主要卖点之一是组织调度方面。这使得各个敏捷团队能够在不完全了解"大局"的情况下解决小问题。问题也在于此，这就会创造一种"单干"文化，让每个团队都"自己做自己的事情"。在缩减规模的过程中，尤其是在代码"腐烂"的情况下，问题更甚。系统可能仍能工作数年，但实际上无法维护。
8、互联网建立在单体之上
为什么要离开呢？
笔者组内中的一个共识是，我们应该始终从单体开始。它更容易构建，如果我们选择使用微服务，我们可以稍后将单体分解。
提及具体某个软件相关的复杂性,我们讨论单个模块而不是单个应用程序要更有意义些。二者在资源使用和财务浪费上的差异是巨大的。在这个追求"降本"的时代，为什么人们还要不知变通地默认构建微服务，而不是动态的模块化单体架构呢？
我们可以从这两大"架构阵营"学到很多东西。诚然，微服务为亚马逊创造了奇迹。但公平地说，他们的云成本已包含在这个奇迹之中。所以，一位的搞微服务教条肯定是有问题的。
另一方面，互联网是建立在单体之上的。它们中的大多数都不是模块化的。两者都有普遍适用的技术。因此，笔者看来，正确的选择是构建一个模块化的单体结构，先搭建好合适的身份验证基础设施，如果我们想在未来转向微服务，我们可以利用这些基础设施来进行解构拆分。
9、后记
在设计应用时，我们目前更多是面临"二选一"的架构选择：单体和微服务。它们二者通常被视为相反的方法。
在小型系统演进过程中，有这样一个不争的事实：单体应用程序往往会随着时间的推移而在架构上降级，即使在其生命周期开始阶段就定义其为架构。随着时间的推移，各种架构的禁止事项会不知不觉地进入项目，久而久之，系统变得更难改变，进化性受到影响。
另一方面，微服务提供了更强的分离手段，但同时也带来了许多复杂性，因为即使对于小型应用程序，团队也必须应对分布式系统的挑战。
单体回归，也是具体的有条件的回归。我们看到，趋势的改变，代表着某段时期具体任务或者目标正在变化。出于目标的变化，我们对于微服务和单体架构的二选一的选择问题，也不能再教条式的看待。
事物往往都在螺旋式的演进，对于架构而言，亦如是。
最后，推荐一款应用开发神器
关于目前低代码在技术领域很活跃！
低代码是什么？一组数字技术工具平台，能基于图形化拖拽、参数化配置等更为高效的方式，实现快速构建、数据编排、连接生态、中台服务等。通过少量代码或不用代码实现数字化转型中的场景应用创新。它能缓解甚至解决庞大的市场需求与传统的开发生产力引发的供需关系矛盾问题，是数字化转型过程中降本增效趋势下的产物。
这边介绍一款好用的低代码平台------JNPF快速开发平台。近年在市场表现和产品竞争力方面表现较为突出，采用的是最新主流前后分离框架（SpringBoot+Mybatis-plus+Ant-Design+Vue3）。代码生成器依赖性低，灵活的扩展能力，可灵活实现二次开发。
以JNPF为代表的企业级低代码平台为了支撑更高技术要求的应用开发，从数据库建模、Web API构建到页面设计，与传统软件开发几乎没有差异，只是通过低代码可视化模式，减少了构建"增删改查"功能的重复劳动，还没有了解过低代码的伙伴可以尝试了解一下。
应用：https://www.jnpfsoft.com/?csdn
有了它，开发人员在开发过程中就可以轻松上手，充分利用传统开发模式下积累的经验。所以低代码平台对于程序员来说，有着很大帮助。