【从零开始学架构 架构基础】架构设计的本质、历史背景和目的

本文是《从零开始学架构》的第一篇学习笔记，主要理解架构的设计的本质定义、历史背景以及目的。

架构设计的本质

分别从三组概念的区别来理解架构设计。

系统与子系统

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

• 关联：系统是由一群有关联的个体组成的，没有关联的个体堆在一起不能成为一个系统。例如，把一个发动机和一台 PC 放在一起不能称之为一个系统，把发动机、底盘、轮胎、车架组合起来才能成为一台汽车。
• 规则：系统内的个体需要按照指定的规则运作，而不是单个个体各自为政。规则规定了系统内个体分工和协作的方式。例如，汽车发动机负责产生动力，然后通过变速器和传动轴，将动力输出到车轮上，从而驱动汽车前进。
• 能力：系统能力与个体能力有本质的差别，系统能力不是个体能力之和，而是产生了新的能力。例如，汽车能够载重前进，而发动机、变速器、传动轴、车轮本身都不具备这样的能力

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

例如微信本身是一个系统，包含聊天、登录、支付、朋友圈等子系统。朋友圈这个系统又包括动态、评论、点赞等子系统。评论这个系统可能又包括防刷子系统、审核子系统、发布子系统、存储子系统。评论审核子系统不再包含业务意义上的子系统，而是包括各个模块或者组件，这些模块或者组件本身也是另外一个维度上的系统。例如，MySQL、Redis 等是存储系统，但不是业务子系统。

模块与组件

模块和组件都是系统的组成部分，只是从不同的角度拆分系统而已。 划分模块的主要目的是职责分离；划分组件的主要目的是单元复用

• 从业务逻辑的角度来拆分系统后，得到的单元就是模块；
• 从物理部署的角度来拆分系统后，得到的单元就是组件。

以学生管理系统为例，从业务逻辑的角度分解，有如下模块

从物理部署的角度分解，有如下组件：

子系统是独立运行的，模块是子系统的逻辑组成部分，如果学生管理系统规模很大（例如在线学校），需要支撑每秒上万的登录请求，那么学生管理的登录模块可以升级为子系统。

框架与架构

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

• 框架是组件规范，例如，MVC 就是一种最常见的开发规范
• 框架提供基础功能的产品，例如，Spring MVC 是 MVC 的开发框架，除了满足 MVC 的规范，Spring 提供了很多基础功能来帮助我们实现功能，包括注解（@Controller 等）、Spring Security、Spring JPA 等很多基础功能

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

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

4R架构方法

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

4R 是指 4 个关键词：Rank，Role，Relation 和 Rule。既然可以通过 4R 来定义软件系统的架构，那么按照 4R 架构定义的思路来画架构图也是很合情合理的，具体步骤如下

• 第一步，明确 Rank：它是指软件架构是分层的，对应“系统”和“子系统”的分层关系。不要事无巨细地把一个大系统的方方面面都在一张架构图中展现出来，而应该明确你要阐述的系统所属的级别（L0～L4），然后只描述这个级别的架构信息。
• 第二步，画出 Role：指软件系统包含哪些角色，每个角色都会负责系统的一部分功能。架构设计最重要的工作之一就是将系统拆分为多个角色，角色对应架构图中的区块、图标和节点等。
• 第三步，画出 Relation：有了角色后，画出角色之间的关系，对应架构图中角色之间的连接线，不同的连接线可以代表不同的关系。
• 第四步，最后画出 Rule：挑选核心场景，画出系统角色之间如何协作来完成某项具体的业务功能，对应系统序列图。

为了方便理解，Rank、Role 和 Relation 是通过系统架构图来展示的，而 Rule 是通过系统序列图（System Sequence Diagram）来展示的，以支付系统为例，顶层为支付系统，描述其子系统角色及角色之间的关系

“扫码支付”这个核心场景的系统序列图如下所示：

软件架构的历史背景

机器语言（太难写、太难读、太难改）-》汇编语言（仍然面向机器）-》高级语言（不再面向机器）-》结构化程序设计【模块】-》面向对象程序设计【对象】-》软件架构【组件】

软件设计过程中，模块、对象、组件本质上是对一定规模软件在不同粒度和层次上的“拆分”方法论（随着软件的复杂度不断增加，拆分的粒度越来越粗，拆分的层次越来越高），软件架构是一种对软件的“组织”方法论。一分一合，其目的是为了软件研发过程中的成本、进度、质量得到有效控制。一个成功的软件设计是要适应并满足业务需求，同时不断“演化”。设计需要根据业务的变化、技术的发展不断进行“演进”，这就决定了这是一个动态活动，出现新问题，解决新问题，没有所谓的“一招鲜”。

软件架构的目的

不是所有系统都需要架构设计，也不需要每个架构都具备高性能、高可用、高扩展等特点，架构设计的主要目的是为了解决软件系统复杂度带来的问题

总结一下

Rank分层区分系统与子系统暂时隔离关注面，在一个系统层面上，其子系统就是角色Role，子系统之间的关系就是Relation，一个核心的业务流程Rule可能涉及多个子系统的交互。如果子系统就是最小层级业务系统，那么它从逻辑层面讲可能包含很多模块，从部署的角度讲也包含很多组件，单个子系统可以使用springBoot框架搭建，遵守其规范使用其功能；软件架构没有银弹，是以解决系统复杂度为目的而随业务演进的方法论。知道WHAT，WHY，才能更好的学习HOW。