架构演进史之整体式架构

整体式架构

构建整体式架构一直是默认的建筑风格。我的意思是，一开始我们每个应用程序都有一个文件，然后我们开始拥有包含多个文件的应用程序，直到1990年代，我们才开始看到由其他应用程序组成的应用程序（尽管第一次实验是在1980年代）。

巨石本身进化了。当应用程序开始使用多个文件构建时，没有太多关于它们的推理，也不需要这种推理，因为应用程序相对简单。随着应用程序变得越来越大，越来越复杂，需要对要创建的文件以及如何关联它们进行一些推理。

模块化软件开发

模块化编程是 20 世纪 60 年代末和 70 年代提出的解决方案。它是从类到代码单元的更粗粒度的显式定义的演变。编程语言实现了具有不同等级显式的模块化。

例如，JAVA 具有默认和公共的类级可见性，其中默认级别意味着类仅在其包（模块）中可见，而public表示该类在其包（模块）内外可见。这允许我们定义包的客户端应该使用哪些类。

组件化软件开发

模块化的另一种风格是组件。组件是根据域概念创建的模块。理想情况下，它们是可用于创建复合应用程序的独立"应用程序"。这种风格的一个反复出现的例子，如果管道和过滤器架构，在Unix系统中广泛使用，这允许我们做类似"ps -ef|grep php".另一个例子是将微服务用作复合应用程序（如Netflix）的组件。

这种代码组织风格也已经存在了很长时间，可以追溯到1960年代后期，就像模块化软件开发一样。

现代巨石

如今，拥有整体架构风格只是意味着所有应用程序代码都作为单个进程在单个节点上部署和运行。我们假设，它使用的是模块和组件，尽管实际上情况往往并非如此。

重要的是要理解为什么这里的关键词是"已部署"和"节点"。关于第一个*，deployed，这意味着如果代码组织在一个或多个存储库中，则代码物理存储在哪里并不重要，重要的是它在运行时的组织方式。关于第二个关键字node*，这意味着如果我们将应用程序部署到多个服务器，就像在水平扩展上下文中一样，它仍然是一个整体。

在单节点服务器中，*整体式架构中的所有模块都组装到同一内存映像中，该映像在单个节点上作为单个进程运行。通信是通过同一堆栈和堆的标准过程调用完成的。它是单个内存映像使应用程序成为整体式。如果你在不同的进程中运行模块，那么你正在做IPC。由于模块属于不同的流程边界，因此您将开始面临分布式计算挑战。

这种风格虽然声誉很差，但即使对于大型应用程序也可以很好地工作。只有当我们需要时，它才会停止足够好：

• 不同域组件的独立可扩展性;
• 用不同的编程语言编写不同的组件或模块;
• 独立可部署性，可能是因为我们的发布速率高于部署管道可以处理的一个代码库，导致发布版的部署速度很慢，因为它需要等待其他版本的部署，甚至导致部署队列的增长速度快于它被消耗的速度。

在这一点上，我们需要以SOA架构风格将我们的整体架构隔离到不同的应用程序中（在后续文章中会详细介绍）。

“大泥球”，又名意大利面架构，是这种风格的反模式，其中包结构和关系不明确，结构内聚和封装不存在或最小，依赖关系不遵循任何规则，很难推理子系统，进行更改和重构。该系统是不透明的，粘稠的，脆弱的和刚性的：一个大泥球！