1、什么是架构，你理解对了么？

系统、子系统、架构、框架、模块、组件，这些概念到底是什么？它们的区别又是什么？

目标：掌握架构的准确定义；能够区分架构相关的易混淆的概念。

1.1、系统与子系统

1.1.1、系统（System）

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

-- 来自《维基百科》

1.1.2、子系统（Subsystem）

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

-- 来自《维基百科》

1.1.3、“系统”概念的架构理解

系统 = 关联 + 规则 + 能力 + 分层

1.1.4、样例

微信是个大系统，下面又细分了 用户子系统、聊天子系统、朋友圈子系统、支付子系统 等。

1.2、架构与框架

1.2.1 软件框架（Software Framework）

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

简而言之，框架就是制定一套规范或者规则（思想），大家（程序员）在该规范或者规则（思想）下工作。或者说使用别人搭好的舞台来做编剧和表演。

-- 来自《维基百科》

1.2.2 软件架构（Software Architecture）

软件架构是有关软件整体结构与组件的抽象描述，用于指导大型软件系统各个方面的设计。

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

-- 来自《维基百科》

1.2.3 区别

1.2.4 样例

1.3、模块与组件

1.3.1 软件模块（Module）

是一套一致而互相有紧密关连的软件组织。它分别包含了程序和数据结构两部分。现代软件开发往往利用模

块作为合成的单位。模块的接口表达了由该模块提供的功能和调用它时所需的元素。模块是可能分开被编写

的单位。这使它们可再用和允许人员同时协作、编写及研究不同的模块。

-- 来自《维基百科》

1.3.2 软件组件（Component）

自包含的、可编程的、可重用的、与语言无关的软件单元，软件组件可以很容易被用于组装应用程序中。

-- 来自《维基百科》

1.3.3 区别

将系统进行逻辑拆分，可以得到模块，目的是为了职责分离。

将系统进行物理拆分，可以得到组件，目的是为了单元复用。

1.3.4 样例

1.4、重新定义架构

1.4.1 4R 架构（重要）

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

4R 架构 = Rank + Role + Relation + Rule

1.4.2 案例（汽车）

汽车由 发动机、电机、变速箱、控制器、ABS 等组成。

1.4.3 4R 架构的应用

2、如何画出优秀的架构图？

目标：理解常见架构图的分类；掌握常见架构图的画法。

2.1、4+1 架构视图

2.1.1 定义

“4+1”视图是对逻辑架构进行描述，最早由 Philippe Kruchten 提出，他在 1995 年的《IEEE Software》上发表了题为《The 4+1 View Model of Architecture》的论文，引起了业界的极大关注，并最终被 RUP 采纳。

--来自《百度百科》

2.1.2 不使用 4+1 视图的原因

• 架构复杂度增加：1995 年的系统大部分还是单体系统，现在分布式系统

• 绑定 UML 图：UML 图画架构图存在问题，展示形式太丑，“颜值即正义”

• 理解困难：4+1 视图的逻辑视图、开发视图、处理视图比较容易混淆

2.1.3 现实中 4+1 视图的用处

• 考证用：比如软考的系统分析师

• 国企用：一般项目招标用此规范

2.2、常见的架构图

2.2.1 业务架构

定义：

描述系统对用户提供了什么业务功能，类似于 4+1 视图的场景视图。

使用场景：

1. 产品人员规划业务

2. 给领导汇报业务

3. 给新员工培训业务

画图技巧：

1. 通过不同颜色来标识业务状态

2. 业务分组管理

2.2.2 客户端架构、前端架构

定义：

客户端和前端的领域逻辑架构，类似于 4+1 视图的逻辑视图。

使用场景：

1. 整体架构设计

2. 架构培训

画图技巧：

1. 通过不同颜色来标识不同角色

2. 通过连接线来表示关系

2.2.3 系统架构

定义：

后端的逻辑架构，又叫“后端架构”、“技术架构”。

使用场景：

1. 整体架构设计

2. 架构培训

画图技巧：

1. 通过不同颜色来标识不同角色类型

2. 通过连接线来表示关系

简单的系统架构图，画 1 张图：

复杂的系统架构图，画 2 张图：

2.2.4 应用架构

定义：

描述后端系统由哪些应用组成。

使用场景：

1. 项目开发、测试

2. 部署发布

3. 子域架构设计

画图技巧：

1. 通过不同颜色来标识不同角色

2. 通过连接线来表示关系

开源案例：

2.2.5 部署架构

定义：

描述后端系统具体如何部署的，对应 4+1 视图的物理视图。

使用场景：

1. 总体架构设计

2. 运维规划和优化

画图技巧：

1. 用图标代替区块

2.3、系统序列图

序列图（Sequence Diagram），亦称为循序图、时序图，是一种 UML 行为图。描述物件在时间序列中的交叉作用。序列图会描绘在此情境下有关的物件，以及此物件和其他物件交换讯息的顺序。序列图一般和待开发系统逻辑视图上，用例的实现有关。序列图有时也称为事件图或事件情境。

3、什么是面向复杂架构设计？

目标：了解常见的架构设计方法论；理解面向复杂度架构设计。

3.1、方法论的意义

3.2、面向模式

POSA 的《面向模式的软件架构》5 本书都比较抽象，比较难以用到现实中，有兴趣可以翻下第一本书《面向模式的软件架构-模式系统》。

3.3、面向风险

《恰如其分的软件架构》的核心是根据系统风险大小来设计软件架构，其中建模部分的本质是面向对象设计的建模过程。

3.4、DDD 领域驱动

DDD（Domain-Driven Design，领域驱动设计）只适合可扩展的业务架构设计，经常用在服务划分的场景。

《架构整洁之道》其实就是 DDD 的实际应用，核心是中间的 Entities，外围的结构都是基于 Entities 的“企业业务规则”来搭建的。

3.5、面向复杂度

3.5.1 错误的架构设计原因

1. 因为架构很重要，所以要做架构设计

2. 公司流程要求系统开发过程中必须有架构设计

3. 为了高性能、高可用、可扩展，所以要做架构设计

4. 为了提升开发效率，为了促进业务发展

5. 。。。。。。。

3.5.2 软件技术发展史

随着软件系统规模的增长，软件设计越来越复杂，数据结构和算法不再是主要问题，整个系统的结构成为首要问题。

3.5.3 面向复杂度的架构设计

3.5.4 架构设计环（重要）

4R 架构搭建的过程，非常重要。

4、如何做好架构设计？

目标：理解架构设计三原则；知道如何应用架构设计三原则；防止过度设计。

4.1、架构设计三原则介绍

4.1.1 架构设计原则的意义

原则的作用是指导我们做更好的设计，而不是可用的设计！

4.1.2 架构设计原则 1-合适原则

具体问题具体分析，根据实际需要选择合适的工具，而不是只要所谓的“高大上”的法拉利。

合适原则宣言：“合适优于业界领先”！

合适原则 = 资源到位 + 时间充足 + 满足业务

4.1.3 架构设计原则 2-简单原则

微服务是为了解决单体系统的问题，但一旦把服务拆得非常细，虽然内部复杂度降低了，但外部复杂度会急剧上升，全链路会变长，所以平衡 内部复杂度 & 外部复杂度 是架构师要重点考虑的要点。

简单原则宣言：“简单优于复杂”

简单原则 = 可靠性高 + 可扩展性好 + 故障处理效率高

4.1.4 架构设计原则 3-演化原则

建筑是静态的，一旦建成就固定下来了，无法继续演化。

软件是动态的，可以不断新增修改删除，可以持续演化。

演化原则宣言：“演化优于一步到位”

演化原则 = 具有创造性 + 持续迭代优化 + 重构提升质量

4.2、架构设计三原则案例

4.2.1 案例 1：菊花厂“三网合一”

试图用一套设备搞定所有市场，大大降低研发、运维、市场的成本，但徒劳无功。

后来，4G 时代实现了当初的项目目标，目前国内的 4G 都是 TD-LTE 的制式。

感悟：

1. 即使大公司，也不是有钱有人就可以为所欲为，同样需要遵循架构三原则

2. 目标高大上，如果没有能够落地的手段，就是空中楼阁

3. 人多并不一定能够办大事，架构设计本质上是“精英设计”

4.2.2 案例 2：松鼠厂超前建设亿级用户平台

追求亿级用户平台的建设，子系统拆分过细，导致测试效率奇低，故障排查异常困难。

不要过度设计，互联网行业一般能满足未来 1-2 年的发展就足够了。

感悟：

1. 创业公司也不需要超前的高瞻远瞩，同样需要遵循架构三原则

2. 技术高大上没有意义，符合团队和业务的才是最好的

3. 架构的质量遵循“木桶理论”，最短的短板决定了架构的质量

4.3、架构设计三原则应用

4.3.1 具体应用

架构设计要足够持久（能满足未来一段时间的业务需求）和坚挺（具备可靠性）

架构设计三原则应用的优先级：合适原则 > 简单原则 > 演化原则

1. 合适原则：设计出来的架构要满足当时的业务需要，符合团队和技术的能力水平

2. 简单原则：先按照简单的方式来设计架构，然后不断地在实际应用过程中迭代优化

3. 演化原则：当业务发生变化时，架构要扩展、重构，甚至重写

架构设计环：

4.3.2 判断维度

常见的架构设计判断维度：业务 + 团队 + 技术

5、外包学生管理系统实战

只有理论，你不知道如何落地；没有理论，你不会举一反三！

目标：通过案例学习具体如何进行架构设计；学习架构设计三原则的应用。

5.1、学生管理系统需求

5.1.1 需求背景

随着学校的规模的不断扩大，学生数量的增加，需要处理的信息也日趋增大。不仅花费大量的教师资源，处理效率也十分地下。为提高学生管理的管理水平，优化资源，尽可能降低管理成本成为学生管理的新课题，学生管理系统是从学生管理现状出发，根据学生管理的新要求进行开发设计的，它需要解决学生信息管理数据信息量大修改不方便，对一系列数据进行分析时花费时间长等问题，帮助学生管理人员有效管理学生信息。

因此学生信息管理系统可以通过系统规范化的管理、科学性统计和快速查询、修改、增加、删除等，提高信息的准确度以及日常管理的工作效率。

本系统主要是应用于学生各类信息的管理，总体任务是实现学生信息关系的系统化、规范化、自动化，其主要任务是统计学生各类新型进行日常管理，如查询、修改、增加、删除、以及学生选课、成绩的查询等功能设计的管理系统。

5.1.2 总体需求

系统主要应用于学校学生信息管理，总体任务是实现学生信息管理的系统化、规范化和自动化，其主要任务是管理学生相关信息，如学籍、课程、成绩、奖惩。

5.1.3 详细需求

原则：要从繁杂的需求里提炼总结出核心功能，再展开进行详细描述。

学生管理：系统登录 + 账号分配 + 账号绑定 + 组织管理层级 + 文件上传/下载 + 信息查询

课程管理：课程录入 + 选课功能 + 排课功能 + 教材选择

考试管理：试卷区域分割 + 平时成绩 + 评分判定

权限管理： 角色管理 + 流程审核 + 权限分配 + 奖惩设置 + 试题设置

5.2、外包系统架构设计分析

5.2.1 面向复杂度架构设计

先明确需求，再动手设计！

判断复杂度：对扩展性要求不高，对数据的高可用要求很高。

5.2.2 方案 1-按子系统划分

优势：按功能模块划分，职责清晰

劣势：多个子系统需要协同，运维、部署成本较高

5.2.3 方案 2-单体水平扩展

优势：单体应用，运维、部署简单，机器可水平扩展，成本较低

劣势：系统功能集中在一起，耦合度较高

5.2.4 方案 1 VS 方案 取舍

根据架构设计三原则进行分析：

1、合适原则：

1）符合团队技术水平和积累

2）开发成本低

3）系统运维成本低

2、简单原则：

1）不进行系统拆分，部署维护简单

2）没用微服务，无需微服务基础设施

3、演化原则：

1）一次性交付，无需考虑太多后期演化

2）学校的学生数量不会发生很大变化，系统架构够用多年

相比方案 1，方案 2 的开发周期较短、运维成本较低、相对简单、甲方易认可，故选择方案 2。

5.2.5 备选方案 3-使用 MongoDB 存储

受团队技术水平影响，将方案 2 的存储组件由 MySQL 更改为 MongoDB

5.2.6 备选方案 4-使用 Oracle 存储

受客户技术影响，客户已经在使用 Oracle，将方案 2 的存储组件由 MySQL 更改为 Oracle

5.2.7 备选方案 5-使用 DNS

受客户预算影响，用已有的 DNS 替换掉 Nginx，并将 3 台 Web 服务器缩减为 2 台 Web 服务器

6、学生管理系统云平台实战

目标：通过案例学习具体如何进行架构设计；学习架构设计三原则的应用。

6.1、云平台需求

6.1.1 需求背景

你们是一家创业公司，公司老板具备丰富的高校人脉资源，老板看到各个高校都在重复建设各自的学生管理系统，建设周期长，功能不完善，老板认为做一个学生管理云平台，既能够减少高校这方面的投入，又可以让高校也“上云”。全中国有 3000 多所高校，这是一个很大的市场。

6.1.2 系统需求

【功能需求】

和外包学生管理系统一样

【平台需求】

1）云平台要具备高可用、高性能

2）云平台要能够隔离各个高校，避免互相影响

6.2、云平台架构分析

6.2.1 三原则分析

创业公司业务发展不可预测，没必要追求一步到位，成本太大

6.2.2 备选方案 1-单机房数据隔离

6.2.3 备选方案 2-单机房服务数据双隔离

数据隔离才是核心，不会做“服务隔离但数据不隔离”

6.2.4 备选方案 3-双机房数据隔离

方案 3 将方案 1 改为双机房

6.2.5 备选方案 4-双机房服务数据双隔离

方案 4 结合方案 2 和方案 3

6.2.6 方案取舍

如果老板不同意方案 1 而要方案 4，如何处理？答：跟老板谈钱、谈时间

6.3、云平台架构设计

6.3.1 总体架构

6.3.2 核心场景 1-创建学校

6.3.3 核心场景 2-用户注册