架构到底是什么？

PS：本系列文章都是在极客时间学习的笔记，只做学习，不用于商业用途，如有侵权，请联系作者删除，谢谢！

以下三组概念的意义：

1. 系统与子系统

系统的定义：系统泛指由一群有关联的个体组成，根据某种规则运作，能完成个别元件不能单独完成的工作的群体。它的意思是“总体”“整体”或“联盟”。

根据系统的定义可知：系统是由有关联关系的个体组成的，并且个体之间存在某种运作规则，并且这些个体组成系统之后，系统产生了一种新的能力，能完成单个个体无法独自完成的能力。

子系统的定义：子系统也是由一群有关联的个体所组成的系统，多半会是更大系统中的一部分。

从定义看，子系统也是一种系统，从观察者的角度看，子系统是系统的一部分。

一个系统的架构，只包括顶层这一个层级的架构，而不包括下属子系统层级的架构。

2.模块与组件

软件模块（Module）是一套一致而互相有紧密关连的软件组织。它分别包含了程序和数据结构两部分。现代软件开发往往利用模块作为合成的单位。模块的接口表达了由该模块提供的功能和调用它时所需的元素。模块是可能分开被编写的单位。这使它们可再用和允许人员同时协作、编写及研究不同的模块。软件组件定义为自包含的、可编程的、可重用的、与语言无关的软件单元，软件组件可以很容易被用于组装应用程序中。

上面是模块和组件的定义，两者主要区别在于视角不同，从业务角度拆分出来的叫模块，从部署角度拆分出来的叫组件

如果你是业务系统的架构师，首先需要思考怎么从业务逻辑的角度把系统拆分成一个个模块角色，其次需要思考怎么从物理部署的角度把系统拆分成组件角色

3.框架与架构

软件框架（Software framework）通常指的是为了实现某个业界标准或完成特定基本任务的软件组件规范，也指为了实现某个软件组件规范时，提供规范所要求之基础功能的软件产品。

框架是组件规范，框架提供基础功能的产品，框架典型的例子就是Spring MVC

软件架构指软件系统的“基础结构”，创造这些基础结构的准则，以及对这些结构的描述。

框架关注的是“规范”，架构关注的是“结构”。

框架是一整套开发规范，架构是某一套开发规范下的具体落地方案，包括各个模块之间的组合关系以及它们协同起来完成功能的运作规则。

软件架构指软件系统的顶层（Rank）结构，它定义了系统由哪些角色（Role）组成，角色之间的关系（Relation）和运作规则（Rule）。

因为这个定义中的 4 个关键词，都可以用 R 开头的英文单词来表示，分别是 Rank、Role、Relation 和 Rule，所以我把定义简称为“4R 架构定义”，每个 R 的详细解释如下。第一个 R，Rank。它是指软件架构是分层的，对应“系统”和“子系统”的分层关系。通常情况下，我们只需要关注某一层的架构，最多展示相邻两层的架构，而不需要把每一层的架构全部糅杂在一起。无论是架构设计还是画架构图，都应该采取“自顶向下，逐步细化”的方式。

第二个 R，Role。它是指软件系统包含哪些角色，每个角色都会负责系统的一部分功能。架构设计最重要的工作之一就是将系统拆分为多个角色。最常见的微服务拆分其实就是将整体复杂的业务系统按照业务领域的方式，拆分为多个微服务，每个微服务就是系统的一个角色。

第三个 R，Relation。它是指软件系统的角色之间的关系，对应到架构图中其实就是连接线，角色之间的关系不能乱连，任何关系最后都需要代码来实现，包括连接方式（HTTP、TCP、UDP 和串口等）、数据协议（JSON、XML 和二进制等）以及具体的接口等。

第四个 R，Rule。它是指软件系统角色之间如何协作来完成系统功能。我们在前面解读什么是“系统”的时候提到过：系统能力不是个体能力之和，而是产生了新的能力。那么这个新能力具体如何完成的呢？具体哪些角色参与了这个新能力呢？这就是 Rule 所要表达的内容。在架构设计的时候，核心的业务场景都需要设计 Rule。

在实际工作中，为了方便理解，Rank、Role 和 Relation 是通过系统架构图来展示的，而 Rule 是通过系统序列图（System Sequence Diagram）来展示的。