入门
三组概念
在理解架构之前，先搞清楚三组容易混淆的概念。
系统与子系统
系统，泛指由一群相关联的个体所组成的群体，它们根据某种规则来运作，并且能够完成单独个体所不能完成的工作。
关联：系统是由一群相关联的个体组成的，没有关联的个体堆在一起不能成为一个系统。比如把一个发动机和一台 PC 放在一起就不能称之为一个系统，而把发动机、底盘、轮胎、车架组合起来就能成为一辆汽车。
规则：系统内的个体需要按照指定的规则运作，而不是单个个体各自为政，规则规定了系统内个体分工与协作的方式。比如汽车发动机负责产生动力，然后通过变速器和传动轴将动力输出到车轮上，从而驱动汽车前进。
能力：系统的能力和个体的能力之间有着本质的差别，系统的能力不是个体的能力之和，而是产生了新的能力。比如汽车能够载重前进，而发动机、变速器、传动轴、车轮本身都不具备这样的能力。
子系统的定义和系统的定义是一样的，只是观察的角度不同，一个系统可能是另外一个更大系统的子系统。
举个例子：微信本身是一个系统，它包括聊天、登录、支付、朋友圈等子系统。朋友圈这个子系统，又包括动态、评论、点赞等子系统。朋友圈评论这个子系统，可能又包括防刷、审核、发布、存储等子系统。朋友圈评论的审核子系统，不再包含业务意义上的子系统，而是包括各个模块或组件，这些模块或组件本身也是另外一个维度上的系统，比如 MySQL、Redis 等是存储（而不是业务）系统。
一个系统的架构，只包括顶层这一个层级的架构，而不包括下属子系统层级的架构。所以微信架构，就是指微信系统这个层级的架构。当然，微信的子系统，比如支付系统，也有它自己的架构，同样只包括顶层。
模块与组件
模块和组件都是系统的组成部分，只是拆分的角度不同而已。
从业务逻辑的角度拆分系统，得到的单元是模块（module），划分模块的主要目的是职责分离。现代软件开发，往往都利用模块作为合成单位。
从物理部署的角度拆分系统，得到的单元是组件（component），划分组件的主要目的是单元复用。component 也可以翻译为零件，零件就是一个物理概念，且具备“独立可替换”的特点。软件组件就是自包含的、可编程的、可重用的、与语言无关的软件单元，它们可以很容易地组装应用程序。
举个例子：学生信息管理系统
从业务逻辑的角度拆分，可以分为登录注册模块、个人信息模块、个人成绩模块
从物理部署的角度拆分，可以分为 Nginx、Web 服务器、MySQL
作为业务系统的架构师，首先需要从业务逻辑的角度把系统拆分成一个个模块角色，然后需要从物理部署的角度把系统拆分成一个个组件角色，比如选择 MySQL 作为存储系统，但是对于 MySQL 内部的体系架构（Parser、Optimizer、Caches&Buffers 和 Storage Engines 等）其实是可以不用关注的，也不需要在我们的业务系统架构中展现这些内容。
框架与架构
软件框架（software framework）通常指的是为了实现某个业界标准或为了完成特定任务的软件组件规范，也指为了实现某个软件组件规范而提供的包含基础功能的软件产品。
framework 是组件规范。比如 MVC 就是一种最常见的开发规范，比如 MVP、MVVM、J2EE 等框架
framework 提供基础功能的产品。比如 Spring MVC 是 MVC 的开发框架，除了满足 MVC 的规范之外，还提供了很多基础功能来帮助我们实现功能，包括注解（@Controller 等）、Spring Security、Spring JPA 等
软件架构（software architecture）是指软件系统的基础结构及其创造准则和相关描述。对于系统的“基础结构”，采用不同的角度或维度，就可以划分为不同的结构。
eg1. 从业务逻辑的角度拆分，学生管理系统的架构如下：
eg2. 从物理部署的角度拆分，学生管理系统的架构如下：
eg3. 从开发规范的角度拆分，学生管理系统可以采用标准的 MVC 框架来开发，因此架构又如下：
这些架构都是学生管理系统的正确架构，只是从不同的角度分解而已，这也是 IBM 的 RUP 将软件架构视图分为著名的“4+1 视图”的原因。
framework 是一整套开发规范，而 architecture 是某套开发规范下的具体落地方案，包括各个模块之间的组合关系以及它们协同起来完成功能的运作规则。
4R 架构
李运华老师将 software architecture（软件架构）重新定义为：软件架构是指软件系统的顶层（Rank）结构，它定义了系统由哪些角色（Role）组成、角色之间的关系（Relation）和运作规则（Rule）。
Rank 分层
软件架构是分层的，对应系统和子系统的分层关系。
通常情况下，我们只需要关注某一层的架构，最多展示相邻两层的架构，而不需要把每一层的架构全部糅杂在一起。无论是架构设计还是画架构图，都应该采取“自顶向下，逐步细化”的方式。
以微信为例，Rank 的含义如下所示：
说明：L0\L1\L2 指层级，一个 L0 往下可以分解多个 L1，一个 L1 可以往下分解多个 L2，以此类推，一般建议不超过 5 层（L0~L4）。
Role 角色
软件系统包含哪些角色，每个角色都会负责系统的一部分功能。
架构设计最重要的工作之一就是将系统拆分为多个角色。最常见的微服务拆分其实就是将整体复杂的业务系统按照业务领域的方式，拆分为多个微服务，每个微服务就是系统的一个角色。
Relation 关系
软件系统中角色之间的关系，对应到架构图中其实就是连接线。
角色之间的关系不能乱连，任何关系最后都需要代码来实现，包括连接方式（HTTP、TCP、UDP 和串口等）、数据协议（JSON、XML 和二进制等）以及具体的接口等。
Rule 规则
软件系统中的角色之间，是如何协作来完成系统功能的。
之前有提到过：系统的能力不是个体的能力之和，而是产生了新的能力。那么这个新的能力是如何完成的？哪些角色参与了这个新能力？这些就是 Rule 所要表达的内容。在架构设计的时候，核心的业务场景都需要设计 Rule。
在实际工作中，为了方便理解，Rank、Role 和 Relation 是通过系统架构图来展示的，而 Rule 是通过系统序列图（System Sequence Diagram）来展示的。
eg.
举个例子，比如一个简化版的支付系统，其架构图如下：
“扫码支付”这个核心场景的系统序列图如下：
分层+连线、序列图
业务逻辑 -> 物理部署 -> 开发规范
主要参考
Last updated
