本文转载自微信公众号“一言”，作者秦语。转载本文请联系一言公众号。混沌之初，巨石开始出现……默认的架构风格是构建巨石。我的意思是，应用程序一开始只有一个文件，然后应用程序开始包含多个文件，直到1990年代应用程序才包含其他应用程序（尽管最初的应用程序始于1980年代）。巨石本身正在发生变化。当开始使用多个文件创建应用程序时，实际上不需要太多考虑，也没有太多需要考虑，因为应用程序相当简单。当应用程序开始扩展并变得越来越复杂时，就需要考虑在应用程序的背后需要创建哪些文件，以及它们是如何关联的。模块化软件开发模块化编程是20世纪60年代末到1970年代的一种方法。这是从类到更粗粒度代码单元的定义明确的演变。编程语言使用不同级别的显式来实现模块化。比如JAVA在类级别的可见性有默认级别和公共级别。默认级别是指类只在所属的包（模块）内可见，公共级别是指类在包（模块）内可见，包（模块）外可见。组件化软件开发组件是另一种模块化风格。在我之前的文章（翻译）中提??到过，组件是按照领域概念划分的模块。理想情况下，它们是独立的“应用程序”，可以组合成应用程序。一个常见的例子是在Unix系统中广泛使用的管道和过滤器架构，例如我们可以使用命令ps-ef|grepphp。另一个例子是Netflix使用微服务作为应用程序组件。代码组织风格，如模块化软件开发，自1960年代末以来一直存在。现代单体现在，单体架构风格仅仅意味着所有应用程序代码都在单个节点上的单个进程中部署和运行。我们认为它会使用模块和组件，尽管通常情况并非如此。有两个关键词“部署”和“节点”很好理解。第一个词“部署”表示代码在运行时的组织方式，无论它是物理存储在一个还是多个代码存储库中。第二个词“节点”是指即使我们在水平扩展的情况下将应用部署到多台服务器上，它仍然是一个单体。在单节点服务器上，单体的所有模块都集成到同一个内存映像中，并作为单个进程运行在单个节点上。通过标准过程调用在同一堆栈和堆中进行模块间通信。单个内存映像使应用程序成为一个整体。如果模块运行在不同的进程中，通信就变成了IPC（Inter-ProcessCall）。随着模块进入不同的进程边界，您将面临分布式计算的挑战。这就进入了微服务领域。（感谢dban的反馈）。尽管这种风格臭名昭著，但它在大型应用程序中仍然运行良好。它只是在以下条件下表现得不够好：不同的域组件需要独立扩展；不同的组件需要用不同的编程语言编写；可独立部署是因为我们的发布频率比一个代码库的持续交付流水线要快，由于需要等待其他发布的部署拖慢自己发布的部署，或者导致部署队列增长太快而无法响应时间。这时候，我们就需要按照面向服务的架构风格，将单体拆分成不同的应用（下一篇文章详细介绍）。反模式：大泥球/意大利面条架构大泥球，也称为意大利面条架构，是这种风格的反模式。在这种反模式中，包结构和关系非常模糊，没有或很少有结构化的内聚和封装，没有依赖规则，子系统很难区分，也很难修改和重构。系统晦涩、粘稠、脆弱、僵硬：只是一个大泥球！引用来源1997–BrianFoote、JosephYoder–BigBallofMud2012–LenBass、PaulClements、RickKazman–实践中的软件架构2017–HerbertoGra?a–微服务架构：大师们对它的评价2017–HerbertoGraca–软件架构Premises2017*–Wikipedia–Modularprogramming2017*–Wikipedia–Component-basedsoftwareengineering探索软件开发的所有方面，从端到云，从工具到实践。我喜欢通过翻译来学习和分享知识，我的翻译有《Kotlin实战》、《领域驱动设计精粹》、《Serverless架构：无服务器应用与AWS Lambda》和《云原生安全与DevOps保障》。
