什么是单体架构
这篇文章主要讲解了"什么是单体架构"，文中的讲解内容简单清晰，易于学习与理解，下面请大家跟着小编的思路慢慢深入，一起来研究和学习"什么是单体架构"吧！
模块化软件开发
模块化编程是 20 世纪 60 年代末到 70 年代间提出的方案。它是从类到更粗粒度代码单元的明确定义的进化。编程语言使用不同等级的明确性来实现模块化。
例如，JAVA 在类这个层级的可见性有默认级别和 public 级别，默认级别意味着类只在它所属的 package (模块)内可见，而 public 级别意味着这个类在 package (模块)内和 package (模块)外都可见。
组件化软件开发
组件是另一种模块化风格。如我之前一篇文章(译)所述，组件是按照领域概念划分的模块。理想情况下，它们是可以组成应用的独立的"应用程序"。老生常谈的例子是在 Unix 系统中广泛使用的管道和过滤器架构，例如我们可以使用这样的命令ps -ef | grep php。另外的例子就是 Netflix 将微服务作为应用的组件。
代码的组织风格和模块化软件开发一样，早在 20 世纪 60 年代末就已经存在了。
现代的单体
现在，单体架构风格就是简单地意味着所有应用代码被部署并运行在单一节点的单一进程中。我们认为它会用到模块和组件，尽管事实往往并非如此。
这里有两个关键词"部署"和"节点"要好好地理解。第一个词"部署"的意思是运行时代码的组织方式，无论代码在物理上是存储在一个还是多个代码库之中。而第二个词"节点"的意思是即便是在横向扩展的情况下我们将应用部署到了多个服务器，它依然是一个单体。
在单一节点的服务器上，单体的所有模块都被集中到同一个内存映像里，作为单一节点上的单个进程运行。通过标准进程调用在同一个栈和堆内进行模块间的通信。单个的内存映像让应用变成了单体。如果模块在不同的进程中运行，通信就变成了 IPC (进程间调用)。由于模块进入了不同的进程边界，你将要面临分布式计算的挑战。这就进入了微服务的范畴。(感谢dban的反馈)。
尽管这种风格声名狼藉，但它依然可以在大型应用中工作得很好。只是下面这些条件下表现得不足够好：
不同的领域组件需要独立可伸缩;
不同的组件需要不同的编程语言来编写;
独立可部署，因为我们的发布频率比一个代码库的持续交付流水线要快，由于需要等待其它发布的部署导致自身发布的部署变慢，或者导致部署队列增长太快无法及时响应。
这时，我们需要将单体按照面向服务的架构风格(接下来的文章中将详细介绍)拆分成不同的应用程序。
反模式：大泥球/意大利面架构
"大泥球"又称意大利面架构，是这种风格的反模式。这种反模式中，包结构和关系十分模糊，结构化的内聚和封装完全没有或极少，依赖毫无规则，子系统很难分辨，也很难修改和重构。系统晦涩、粘滞、脆弱、僵化：就是一个大泥球!
感谢各位的阅读，以上就是"什么是单体架构"的内容了，经过本文的学习后，相信大家对什么是单体架构这一问题有了更深刻的体会，具体使用情况还需要大家实践验证。这里是，小编将为大家推送更多相关知识点的文章，欢迎关注！
