架构定义

系统与子系统

【系统】

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

【子系统】

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

架构与框架

【软件框架（Software Framework）】

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

【软件架构（Software Architecture）】

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

模块与组件

【软件模块（Module）】

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

【软件组件（Component）】

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

架构定义和剖析

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

【软件架构】

软件架构指软件系统的顶层结构，它定义了系统由哪些角色（Role）组成，角色之间的关系

（Relation）和运作规则（Rule）。

分层架构 s vs 架构分层

分层架构是一种可扩展架构模式，架构分层是指架构是自顶向下，逐步细化！

4R 架构应用

架构师职责: 1. 确定层级 2. 拆解角色 3. 定义关系 4. 设计规则

架构文档内容 1.指明层级 2.描述角色 3. 定义关系 4. 展现规则

如何学习架构 1. 自顶向下学习 2. 角色有哪些 3. 角色关系如何 4.运作规则是什么

思维导图

画出优秀的架构图

4+1 架构视图

4+1 架构视图 – – 定义

逻辑视图： 系统提供给用户的功能，对应 UML 的 class 和 state diagrams。

处理视图： 系统的处理过程，对应 UML 的 sequence 和 activity diagrams。

开发视图： 程序员角度看系统的逻辑组成，对应 UML 的 package diagrams。

物理视图： 系统工程师角度看系统的物理组成，对应 UML 的 deployment diagrams。

场景视图： 用户角度看系统需要实现的需求，对应 UML 的 use case diagrams。

4+1 架构视图 – – 现状

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

2. 绑定 UML 图：UML 图画架构图存在问题。

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

大厂常见架构图介绍

架构图分类

业务架构

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

使用场景：

1. 产品人员规划业务；

2. 给高 P 汇报业务；

3. 给新员工培训业务。

画图技巧：

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

2. 业务分组管理。

客户端架构、前端架构

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

使用场景：

1. 整体架构设计；

2. 架构培训。

画图技巧：

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

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

系统架构 – – 简单画 1 张图 ，复杂，画 2 张图

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

使用场景：

1. 整体架构设计；

2. 架构培训。

画图技巧：

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

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

应用架构

定义：

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

使用场景：

1. 项目开发、测试；

2. 部署发布；

3. 子域架构设计。

画图技巧：

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

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

部署架构

定义：

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

使用场景：

1. 总体架构设计；

2. 运维规划和优化。

画图技巧：

用图标代替区块。

系统序列图

序列图补充完善了架构运作规则部分

思维导图

面向复杂度架构设计

方法论的意义

面向模式

1. 核心思想：应用经过验证的成熟架构模式，例如 MVC、Reactor 等。

2. 核心问题：知道模式，但是不知道什么时候用哪个模式。

3. 太庞大，且比较理论化，看起来比较累。

4. 5 卷本由不同的作者完成，前后风格不完全一致。

面向风险

1. 核心思想：根据系统风险大小来设计软件架构。

2. 核心问题：风险是一种概率预判，“一切皆有可能”。

3. 建模部分的内容本质是面向对象设计的建模过程。

领域驱动设计

1. DDD 是可扩展架构的设计技巧，不是架构方法论。

2. DDD 兼顾架构设计和方案设计，大部分人会搞混。

3. DDD、敏捷架构不关注存储和计算，只关注业务

整洁架构

面向复杂度

面向复杂度架构设计逻辑

本质 架构设计是为了降低软件系统的复杂度。

思路 通过分析系统需求找到系统复杂的地方，然后设计方案。

模式 复杂度来源：高性能、高可用、可扩展、安全、成本……

套路 分库分表、缓存、集群、分片、微服务、DDD、异地多活……

面向复杂度架构设计体系

面向复杂度架构设计环

思维导图

做好架构设计

架构设计三原则

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

架构设计原则 1 – – 合适原则 合适原则宣言：“合适优于业界领先”

架构设计原则 2 – – 简单原则 简单原则宣言：“简单优于复杂”

架构设计原则 3 – – 演化原则 演化原则宣言：“演化优于一步到位”

架构设计三原则应用

架构设计原则具体应用

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

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

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

面向复杂度架构设计环

架构设计原则常见判断维度

业务

1. 业务当前的量级

2. 业务发展速度

3. 业务的发展形态

团队

1. 团队规模

2. 团队能力水平

3. 投入的资源

技术

1. 已有技术体系

2. 当前技术能力

3. 技术成熟度

思维导图