系统架构师知识点

第一章 计算机组成

• 第1节 ： 磁盘调度移臂算法

  1. 最短移臂调度：找距离当前磁头所在 柱面 最近的 柱面 ，即最短寻道时间。

• 第2节 ： 总线

  1. 串行总线：适合 长距离 传输，传输速率低。有 半双工 、 全双工 之分。

a. 波特率：受硬件时钟频率控制

b. 按位传输，正确性依赖于校验码纠正

1. 并行总线：适合 近距离高速 传输

• 第3节 ： CRC 校验码

  1. 补0，数量是多项式的指数，如 x 3 就是 5 个 0

  2. 取余，除数是多项式的指数，有则是1，如 x 3：101000

  3. 余数就是 CRC 校验码

• 第4节 ： 指令集

  1. RISC：指令数量少，指令长度固定，指令周期短，寻址方式少，寄存器多

  2. CISC：指令数量多，指令长度不固定，指令周期长，寻址方式多，寄存器少

• 第5节 ： 指令流水线

  1. 流水线执行时间：一条指令总执行时间+（指令条数 - 1） * 流水线周期（指令最长的段）

  2. 吞吐率：指令条数 / 流水线执行时间；最大吞吐率，就是把指令条数设置为 n，当 n 趋向于 正无穷 时的值

  3. 加速比：不使用流水线 / 流水线执行时间

第二章 系统性能评价

• 第1节 ： 评价方法：

基准程序：用的最多，最频繁的 核心 程序

第三章 操作系统

• 第1节 ： 进程

  1. 由 PCB 进程控制块、程序、数据三部分组成

  2. 进程状态包含：就绪、运行、阻塞

  3. 资源的 P、V 操作指的是：

a. P 操作：申请资源，资源数 -1

b. V 操作：释放资源，资源数 +1

1. 死锁

a. 死锁资源计算：

• 发生死锁的最大资源数 = 进程数n * 每个进程的最大资源数 R

• 不发生死锁的最小资源数 = 进程数n * （R - 1）+ 1

b. 死锁产生的条件：

• 互斥：资源不能共享

• 占有资源且等待：进程占有资源后，继续申请其他资源

• 系统不能剥夺进程资源：资源不能被抢占

• 进程资源图是环路，循环等待：形成环形等待

c. 死锁避免：银行家算法

• 资源分配图：有向图，节点是进程和资源，边是请求和分配

• 资源分配图的环路：死锁

• 资源分配图的环路没有：不死锁

1. 线程：

a. 共享进程的资源：公共数据、全局变量、代码、文件

b. 不共享：线程的栈指针、一组寄存器、程序计数器

1. 内存

a. 分区

• 首次适应法：从头找到一个符合的切割出来

• 最佳适应法：从小到大排序，找到第一个符合的

• 最坏（最差）适应法：从大到小排序，找到第一个符合的，可以预防过多细小空闲内存碎片

• 循环首次适应法：从上次分配的地方开始找

b. 分页：根据物理空间划分

c. 分段：根据逻辑空间划分

1. 存储

a. DAS（直接附加存储）：存储设备是通过电缆(通常是SCSI接口电缆)直接连接服务器，不能提供跨平台文件共享功能

b. NAS（网络附加存储）：存储设备通过网络连接到服务器，提供跨平台文件共享功能，直接通过网络接口与网络直接相连；NAS设备有自己的OS

c. SAN（存储区域网络）：通过专用高速网将一个或多个网络存储设备和服务器连接起来，使用以太网(IP SAN)和光纤通道(FC SAN)

1. I/O

a. 由设备、控制器、通道、总线和 I/O 软件组成

1. 多级地址索引索引数量：索引块大小 / 地址项大小

a. 例如：索引块大小 4KB，地址项大小 4B，索引数量就是 4KB / 4B = 1024

1. 实时操作系统的外部事件必须在被控对象允许的时间内处理

2. 前趋图中如果有的关系可以通过其他依赖关系隐含表示，那么可以省略

• 第2节 ： 系统性能评估

  1. 等效指令速度法：也称为吉普森混合法（Gibson mix）或混合比例计算法，是通过各类指令在程序中所占的比例（Wi）进行计算得到的

  2. 基准程序法：把应用程序中用得最多、最频繁的那部分核心程序作为评估计算机系统性能的标准程序；不但考虑到了CPU（有时包括主存）的性能，还将I/O结构、操作系统、编译程序的效率等对系统性能的影响考虑进来了

第四章 数据库

• 第1节 ： 从底向上：物理级数据库（内模式、物理存储）、概念级数据库（模式、概念模式）、用户级数据库（外模式、视图）

• 第2节 ： 数据库设计：

  1. 需求分析：获得用户对系统的 信息要求 、 处理要求 、 系统要求 ，产出数据流图、数据字典、需求说明书

  2. 概要设计：产出 E-R 图（实体联系图）

  3. 逻辑结构设计：把 ER 转换成关系模式，即转换成实际的表和列属性

  4. 物理设计：把逻辑结构转换成物理存储结构，确定数据分布、存储结构和访问方式

  5. 数据库实施：创建数据库，导入数据

  6. 数据库维护：数据备份、恢复、性能监控

• 第3节 ： 数据模型三要素

  1. 数据结构：数据的逻辑结构

  2. 数据操作：对数据的操作

  3. 数据约束条件：对数据的限制

• 第4节 ： E-R 图

  1. 过程：

a. 确定局部视图范围

b. 确定实体、联系

c. 分配实体及联系的属性

1. 椭圆：属性

2. 长方形：实体

3. 菱形：联系，两段要写联系类型：1:1、1:N（一对多）、N:M（多对多）

a. M:N 关系：需要引入中间表

1. 冲突

a. 属性冲突：同一个实体或关系中，属性的类型、值域或取值范围定义不一致

b. 结构冲突：一个概念可能被表示成不同的实体、关系或属性

c. 命名冲突：在不同ER图中，同一实体或属性使用了不同的名字，或者不同的实体或属性使用了相同的名字

d. 实体冲突：在不同ER图中，对于同一个概念建模的实体，其结构或定义范围存在冲突

1. 候选码：入度为 0 的唯一性属性

• 第5节 ： 关系运算

  1. 差(-)：S1 - S2：S1 中有，但S2 中没有的

  2. 笛卡尔积(×)：属性列数相加，行数相乘

  3. 投影(π)：选择某个表的某几列

  4. 选择(σ)：选择某个表的某几行

  5. 连接(⨝)：连接两个表，显示属性相同且值相同的记录

  6. 【TODO】关系表达式、关系代数表达式 π

a. π1,4(σ3=6(R×S))

• R × S 笛卡尔积运算

• 选择第三列等于6的

• 只保留第1列和第4列的属性

1. 自然连接：特殊的等值连接，即R关系中的属性与S关系中属性进行等值连接，然后去掉重复属性列

• 第6节 ： 规范化

  1. 函数依赖：

a. 部分函数依赖：A 可以确定 C，A,B 也可以确定 C，由于 A,B 中的一部分就可以确定C，所以称为部分函数依赖

• 会导致存在数据冗余、更新异常、删除异常和插入异常

b. 传递函数依赖：A 可以确定 B，B 可以确定 C，那么 A 也可以确定 C，所以称为传递函数依赖

1. Armstrong 公理系统

a. 反身性：如果 X 是 Y 的子集，那么 Y 是 X 的超集

b. 增广率（增强性）：如果 X -> Y，那么 XZ -> YZ

c. 传递性：如果 X -> Y，Y -> Z，那么 X -> Z

d. 分解性：如果 X -> W，Z 属于 W，那么 X -> Z

e. 合成性：如果 X -> Y，X -> Z，那么 X -> YZ

1. 范式

第一范式：每个属性都是不可分割的原子值

第二范式：满足第一范式，且不存在部分函数依赖（消除非主属性对候选键的部分依赖）

第三范式：满足第二范式，且不存在传递函数依赖（消除非主属性对候选键的传递依赖）

BCNF：满足第三范式，且消除主属性对候选键的传递依赖

• 第7节 ： 保持函数依赖的判断过程：

  1. result := a (例如 a 是 B)

  2. foreach 分解后的 Ri （例如 Ri 是分解后的 (A,B) 或 (B,C)）

  3. t = (result ∩ Ri)+ ∩ Ri （例如 t = (B ∩ (B,C))+ ∩ (B,C) = B+ ∩ (B,C) = BC ∩ (B,C) = B）

  4. result := result ∪ t

• 第8节 ： 事务

  1. 事务的 ACID 特性

a. 原子性：全做或全不做

b. 一致性：事务执行前后，数据是一致的

c. 隔离性：事务的更新对其他事务不可见

d. 持久性：事务提交后，数据是持久的

1. 事务存在的3个问题

a. 丢失更新：两个事务同时更新同一数据，最后一个事务的更新覆盖了第一个事务的更新

b. 脏读：一个事务读取了另一个事务未提交的数据

c. 不可重复读：一个事务读取了另一个事务提交的数据

1. 事务的封锁协议

a. X 锁：排他锁，读写锁，只允许一个事物读取和修改

b. S 锁：共享锁，读锁，允许多个事物读取，但是不能修改

c. 一级封锁协议：修改数据前，先加上 X 锁，可以解决丢失更新问题

d. 二级封锁协议：在一级封锁协议的基础上，读取数据前，先加上 S 锁，读完立即释放，可以解决脏读

e. 三级封锁协议：在二级封锁协议的基础上，读取数据前，先加上 S 锁，事务结束后释放，可以解决不可重复读

• 第9节 ： 分布式数据库【TODO】

  1. 全局概念模式

  2. 全局外模式

  3. 分布模式

  4. 分片模式

• 第10节 ： 常见的 SQL 语句优化策略

  1. 建立物化视图，尽可能减少多表查询

  2. 以不相干子查询替代相干子查询

  3. 只检索需要的列

  4. 使用 IN 替代 OR

  5. 经常提交 commit，尽早释放锁

  6. 避免嵌套的游标和多重循环

• 第11节 ： 常见数据库

  1. Lambda 架构：

a. 优点：容错性好、查询灵活度高、易伸缩、易扩展。支持离线和实时数据。

b. 缺点：编码开销、成本、收益

1. Hadoop 框架：主要在离线批处理模式下

• 第12节：完整性约束

  1. 实体完整性：主码不能为 NULL

  2. 参照完整性：外码必须在主表中存在

  3. 用户定义完整性：用户自定义的约束条件，如数据类型、取值范围等

第五章 计算机网络

• 第1节 ：传输介质

  1. 双绞线

CAT3:3类，10Mbps

CAT4:4类，无应用

CAT5:5类，100Mbps、快速以太网

CAT5e:增强型5类、超五类，1000Mbps

CAT6:6类，1000Mbps

2。 光纤

单模光纤适合：长距离传输，带宽高

多模光纤适合：短距离传输，带宽低

• 第2节 ：OSI/RM 七层模型

  1. 物理层：该层的协议产生检测电压，以便发送和接收比特流；EIA/TIA-232-F FDDI RS-232

  2. 数据链路层：物理地址寻址，该层的协议产生帧，以便发送和接收数据帧；SDLC、PPP、STP、IEEE802

a. IEEE 802.3

• IEEE 802.3：标准以太网，10Mbps，介质为细同轴电缆

• IEEE 802.3u：快速以太网，100Mbps，介质为双绞线

• IEEE 802.3z：千兆以太网，1000Mbps，介质为光纤、双绞线

• IEEE 802.3ab：万兆以太网，10Gbps，介质为光纤

1. 网络层：网络逻辑地址寻址，还实现了拥塞控制等，该层的协议产生【分组】，以便发送和接收数据分组；IP、ICMP、ARP、RARP、IGMP

a. PTR 记录：反向解析记录，可以把 IP 地址转换成域名

1. 传输层：确保数据可靠、顺序、无错的从 A 传输到 B，提供错误恢复和流量控制；TCP、UDP

a. TCP 的端口号用于对应用层进程进行寻址

b. TCP 和 UDP 都是全双工的

c. TCP 是面向连接的，UDP 是无连接的

d. TCP 是面向字节流的，UDP 是面向报文的

1. 会话层：建立、管理和终止会话连接；RPC、SQL

2. 表示层：数据格式转换、加密和解密；JPEG、MPEG、ASCII

3. 应用层：用户直接使用的协议；HTTP、FTP、SMTP、DNS、DHCP

a. DHCP：动态主机配置协议，自动分配 IP 地址，在一个局域网中可以存在多个 DHCP 服务器，客户的申请每台服务器都会响应，客户根据最先到达的报文来选择 ip 地址，对于客户端来说不知道 DHCP 服务器地址，也无法指定

• 第3节 ：设备

  1. 交换机：交换机的初始 MAC 表是空的，通过学习输入帧的源 MAC 地址来建立 MAC 表

作用：根据 MAC 地址转发数据帧

1. 路由器：运行在网络层，负责不同网络之间的通信

作用：根据 IP 地址转发数据包

1. 网桥：工作在数据链路层，连接两个局域网

• 第4节 ：局域网

  1. 大型局域网：范围核心层、汇聚层和接入层

a. 核心层：在逻辑上只有一个，连接多个分布层交换机，通常是一个园区中连接多个建筑物的总交换机的核心网络设备

b. 汇聚层：汇聚层定义网络的访问策略

c. 接入层：接入层提供局域网络接入功能。，可以使用集线器代替交换机

第六章 信息安全

• 第1节：信息安全五要素

  1. 机密性：信息只能被授权的用户访问

  2. 完整性：得到允许的人才能修改，并且能判断出是否已被篡改

  3. 可用性：信息在需要时可用，攻击者不能影响授权者

  4. 可控性：信息的访问和使用受到控制

  5. 可审查性：信息的访问和使用可以被审计

• 第2节：数字证书的验证过程

  1. 证书请求：用户向 CA 提交证书请求，CA 生成数字证书

  2. 证书验证：用户使用 CA 的公钥验证数字证书的合法性

  3. 证书使用：用户使用数字证书进行身份验证

• 第3节：安全算法与协议

  1. PGP：用于消息加密、验证的应用程序，采用 IDEA 散列算法

• 第4节：数字签名

  1. 使用发送方的私钥加密消息摘要，接收方使用发送方的公钥解密消息摘要，因为只有发送方有私钥，所以可以防止抵赖

第七章 软件工程基础

• 第1节：软件工程

  1. 软件开发周期

a. 软件定义：问题定义、可行性研究、详细需求分析

b. 软件开发：概要设计、详细设计、编码、测试

c. 软件运行和维护

1. 软件工程过程

a. P：Plan 软件的功能和运行时限制

b. D：Do 软件开发，软件的设计和实现

c. C：Check 软件确认，软件测试，软件的验证和确认

d. A：Act 软件行动，软件的维护和更新

1. 能力成熟度模型（CMM）

a. 初始级：无序、混乱

b. 可重复级：建立了基本的项目管理过程和实践来跟踪项目的费用、进度和功能

c. 已定义级：有标准、有规范，文档化、标准化

d. 已管理级：制定了软件过程和产品质量的度量标准

e. 优化级：不断改进软件过程和产品质量

1. 能力成熟度模型集成（CMMI）：初始级、已管理级、已定义级、量化管理级、优化级

2. 软件过程模型

a. 瀑布模型：线性、顺序，适合需求明确、变更少的项目（如二次开发）

b. 原型模型：快速开发，适合需求不明确、变更多的项目（新项目）

c. 增量模型：按照功能优先级先开发核心功能

d. 螺旋模型：迭代、增量，适合需求不明确、变更多的项目，与原型类似，但是增加了风险分析

e. V 模型：增加了很多轮测试，贯穿整个开发过程

f. 喷泉模型：特点是面向对象的模型

1. 统一过程模型（RUB）

a. 九个核心工作流：业务建模、需求、分析与设计、实现、测试、部署、配置与变更管理（所有制品的完整性和一致性）、项目管理、环境

b. 特点：用例驱动、迭代、增量

c. 以体系结构为中心，采用多个视图

• 4+1 视图

  • 用例视图：描述系统的功能需求

  • 逻辑视图：描述系统的静态结构、描述设计的对象模型和对象之间的关系

  • 开发视图（实现视图）：描述系统的实现细节、描述了软件模块的组织与管理

  • 过程视图（进程视图）：描述系统的动态行为、描述设计的并发和同步特征

  • 部署视图：描述系统的物理结构

1. 软件文档

a. 用户文档：定义了功能和使用方法

b. 系统文档：定义了系统的体系结构、设计和实现

1. 软件活动

a. 软件描述：定义了软件的功能和使用限制

b. 软件开发

c. 软件验证

d. 软件进化

1. 基于构件的软件工程（CBSE）

a. 构件是对象

• 获取构件的方法：从现有构件中获得符合要求的构件、通过遗留工程提取有潜在复用价值的软件构件、购买现成的商业构件、开发符合需求的构件

• 开发构件通常的策略：分区、抽象、分割

• 主流构件标准：CORBA、COM、EJB

b. 构件组装：顺序、层次、叠加、参数不兼容、操作不兼容、操作不完备

• 第2节：需求工程

  1. 需求开发：需求获取、需求分析、需求定义和需求验证

  2. 需求管理：变更控制、版本控制、需求跟踪和需求状态

  3. 系统设计

a. 流程表示工具

• 程序流程图（PFD）

• IPO 图：输入-处理-输出图

• N-S 图：表示嵌套和层次关系

• PAD：问题分析图

• 盒图：通过简单的方框（盒子）和箭头来表示系统的组件及其相互之间的关系

b. 系统设计的基本原理

• 抽象化

• 自顶向下

• 信息隐蔽

• 模块独立（高内聚、低耦合）

• 系统设计原则

• 保持模块的大小适中

• 尽可能减少调用的深度

• 多扇入少扇出

• 单入口单出口

• 模块的作用域在模块之内

• 功能是可预测的

c. 模块内聚（从低到高）

• 偶然内聚

• 逻辑内聚

• 时间内聚

• 过程内聚（顺序内聚）

• 通信内聚

• 顺序内聚

• 功能内聚

d. 模块耦合（从低到高）

• 数据耦合

• 标记耦合

• 控制耦合

• 外部耦合

• 公共耦合

• 内容耦合

• 第3节：测试

  1. 软件度量

a. McCabe 度量法：

• 环路复杂度：有向边数 m、节点数 n ，复杂度为 m-n + 2

• 环路复杂度：判定节点数 + 1

1. 动态测试： 通过运行程序发现错误

a. 黑盒测试法（等价类划分、边界值分析、错误推测、因果图）

• 等价类划分：把输入划分为若干个等价类

• 边界值分析：测试边界值

• 错误推测：根据经验推测错误

• 因果图：把输入和输出之间的关系表示成图

b. 白盒测试法（逻辑覆盖、循环覆盖、基本路径法）

c. 灰盒测试法

• 结合了黑盒和白盒测试

• 主要是对数据流进行测试

1. 静态测试

a. 桌前检査（桌面检查）、代码审查和代码走查

• 第4节：结构化程序设计

  1. 自顶向下，逐层分解

  2. 结构化方法分析模型的核心是数据字典，有三个层次的模型，分别是数据模型、功能模型和行为模型（也称为状态模型）

a. 使用E-R图表示数据模型

b. 用DFD表示功能模型

• DFD：数据流图，表示数据的流向和处理过程

• DFD 的基本元素包括：数据流、处理、存储、外部实体

• DFD 的层次结构：上下层之间的关系是分解关系，分解关系是自顶向下的

• DFD 的分解原则：每个处理都要有输入和输出，输入和输出的数据流要一致

c. 状态转换图表示行为模型

• 状态转换图：表示系统的状态和状态之间的转换关系

• 状态转换图的基本元素包括：状态、事件、动作、条件

• 状态转换图的分解原则：每个状态都要有输入和输出，输入和输出的事件要一致

第八章 UML

• 第1节 ： 面向对象的设计建模工具 UML

  1. 定义了14种图：

a. 结构图（静态图）包括：类图、 对象图、构件图、部署图、 制品图、 包图、 组合结构图

b. 行为图（动态图）包括：用例图、顺序图、通信图（协作图）、定时图、交互概览图、活动图、状态图

• 顺序图：

  • 用来描述对象之间的交互

  • 循环、选择等复杂交互使用【序列片段】表示

  • 对象之间的消息类型包括：同步消息、异步消息、返回消息、参与者创建消息、参与者销毁消息

• 活动图：

  • 描述的是对象活动的顺序关系所遵循的规则，它着重表现的是系统的行为，而非系统的处理过程

  • 活动图是面向对象的，而流程图是面向过程的，能够表示并发活动的情形

第九章 软件架构设计

• 第1节 ： 基础

  1. 软件架构设计主要关注软件构件的结构、属性和交互作用

  2. 软件设计包括四个既独立又相互联系的活动：数据设计、软件结构设计、人机界面设计和过程设计

  3. 结构化程序设计：仅用顺序、分支和循环三种基本的控制构件即能构造任何单入口单出口程序

  4. 软件架构风格：一个体系结构定义了一个词汇表和一组约束

  5. 基于软件架构的开发强调由商业、 质量和功能需求的组合驱动软件架构设计，采用【视角与视图】来描述软件架构； 采用【用例和质量场景】来描述需求

  6. 软件需求的三个层次

a. 业务需求：组织机构或客户对系统、产品高层次的目标要求

b. 用户需求：描述了用户使用产品必须要完成的任务，是用户对该软件产品的期望

c. 功能需求：也包括非功能需求，定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足业务需求

1. 复用

a. 机会复用：只要发现有可以复用的，就复用

b. 系统复用：开发之前进行规划，决定哪些需要复用

• 第2节：系统建模

  1. 面向对象系统建模

a. 用例关系包括：泛化、包含、扩展

• 泛化：父类和子类的关系

• 包含：一个类包含另一个类，一个类依赖于另一个类

• 扩展：一个类扩展另一个类，有先后顺序的

b. 类关系（UML类图关系）：关联、聚合、组合、依赖、泛化、实现。

• 关联：两个类之间的关系

• 聚合：整体和部分的关系，整体可以存在于多个部分中

• 组合：整体和部分的关系，整体只能存在于一个部分中

• 依赖：一个类依赖于另一个类

• 泛化：父类和子类的关系

• 实现：接口和实现类的关系

c. 构建用例模型经历4个阶段：识别参与者、合并需求获得用例、细化用例描述、调整用例模型

1. TLS软件架构【TODO】层次特点

• 第3节：系统质量属性

  1. 软件架构质量属性、质量属性效应树：运行期属性（性能、可用性、安全性、易用性、功能性、互操作性）、开发期属性（可修改性、可测试性）

  2. 质量属性场景：

a. 提供了一种结构化的方法来描述和分析系统的质量属性

b. 6 要素：刺激源（用户请求）、刺激（用户的需求）、环境、制品（系统）、响应（系统响应、处理能力）、响应度量（响应时间）

1. 敏感点：为了实现某种特定的质量属性，一个或多个系统组件具有的特性

2. 权衡点：影响多个质量属性的特性，是【多个】质量属性的敏感点

3. 风险点：某些做法有一些隐患可能导致一些问题

4. 非风险点：不会造成潜在问题的架构决策的关注点

5. 系统可靠性

a. 定义：系统在规定的时间内及规定的环境条件下，完成规定功能的能力，就是系统无故障运行的概率

b. 可靠性包括：成熟性、容错性、易恢复性和可靠性的依从性

c. 采用哪些技术：冗余技术、软件容错技术、双机容错技术、集群技术

1. 架构权衡评估方法（ATAM）：如何评估一个系统的质量

a. 描述和介绍阶段: 描述 ATAM 的方法、描述业务动机、描述架构

b. 调查和分析阶段：确定架构方法，生成质量属性效用树，分析架构方法

c. 测试阶段：讨论场景和对场景分级，分析架构方法

d. 最终阶段：描述评估结果

• 第4节：软件可靠性

  1. 基本原则

a. 软件可靠性设计是软件设计的一部分，必须在软件的总体设计框架中使用，并且不能与其他设计原则相冲突

b. 软件可靠性设计在满足提高软件质量要求的前提下，以提高和保障软件可靠性为最终目标

c. 软件可靠性设计应确定软件的可靠性目标，不能无限扩大，并且在功能、用户需求、开发费用之后考虑

1. 可靠性设计技术

a. 容错设计、检错设计、多版本（N版本）设计、恢复块设计、降低复杂度

• 恢复块：分为主块和多个后备块，错误检测需要进行验证测试程序，合格输出正确结果，不合格则走后备块，或进行异常处理；恢复策略为“反向恢复”，实时性差

• N版本：错误检测方法是表决；恢复策略是向前恢复，实时性好

1. 可靠性分析方法

a. 故障树分析方法

• 从软件系统不希望发生的事件开始，向下分析，直到找到导致该事件发生的基本事件

b. 失效模式与效应分析方法

• 在软件开发阶段的早期，通过识别软件失效模式，分析造成的后果，研究分析各种失效模式产生的原因，寻找消除和减少其有害后果的方法，以便尽早发现潜在的问题，并采取相应的措施，从而提高软件的可靠性和安全性

• 第5节：软件架构风格

  1. 面向对象架构

a. 将数据表示和基本操作封装在对象中

c. 对象维护自身表示的完整性，对象之间通过消息机制进行通信，对象交互时需要知道彼此的标识，通过对象之间的协作完成计算过程

d. 适合：有用户交互、事件驱动的场景

e. 设计类：

• 实体类：映射需求中的每个实体

• 边界类（或接口类）：用于封装在用例内、外流动的信息或数据流，比如一些页面

• 控制类：用于控制用例工作，由动宾结构的短语，比如:支付、备货

f. 面向对象的分析模型

• 由顶层架构图、用例、用例图、领域概念模型构成

• 设计模型

  • 包图表示的软件体系结构图

  • 交互图表示的用例实现图

  • 完整精确的类图

  • 针对复杂对象的状态图

  • 描述流程化处理过程的活动图

1. 控制环路架构

a. 将过程输出的指定属性维护在一个特定的参考值

b. 构件包括过程变量、被控变量、输入变量、操纵变量和设定点等

c. 通过收集实际和理想的过程状态信息，并能调整过程变量使得实际状态趋于理想状态

d. 适合：自动收集信息对系统状态进行持续调整

1. 面向服务的体系结构（SOA）

a. 定义：一种软件架构风格，允许通过网络将服务组合在一起

b. 关键原则：

• 服务是松散耦合的

• 服务是自治的

• 服务是可发现的

• 服务是可组合的

• 服务是标准化的

• 服务是可重用的

• 服务是可互操作的

• 服务是可扩展的

• 服务是可管理的

• 服务是可监控的

c. 适合：需要集成多个系统的场景

d. 关键技术：Web Service、RESTful、SOAP、WSDL、UDDI

• Web Service：基于 XML 的服务，使用 HTTP 协议进行通信

• RESTful：一种架构风格，使用 HTTP 协议进行通信，强调无状态和资源的表现形式

• SOAP：简单对象访问协议，基于 XML 的协议，用于交换结构化信息

• WSDL：Web 服务描述语言，用于描述 Web 服务的接口和实现

• UDDI：统一描述、发现和集成，用于注册和发现 Web 服务

1. 分布式微服务体系结构

a. 涵义：将应用程序构造为一组松散耦合的服务，微服务中单个应用程序由许多松散耦合且可独立部署的较小组件或服务组成

b. 关键原则：

• 每一个 URI 代表一种资源

• 客户端使用 HTTP Verb 表示操作方式的动词对服务端资源进行操作

• 通过操作资源的表现形式来操作资源

• 资源的表现形式是 XML 或 HTML

• 客户端与服务端之间的交互是无状态的，客户端每个请求必须包含理解请求所必需的所有信息

c. 优点：

• 每个微服务都很小，可以聚焦一个指定的业务功能或业务需求

• 可以被小团队单独开发

• 松耦合的，有功能意义的，在开发和部署阶段都是独立的

• 可以使用不同的语言开发

• 去中心化

d. 缺点

• 需要依赖分布式事务跨服务实现功能

• 测试复杂

• 部署复杂

• 需要团队之间紧密协作

• 第6节：采用基于架构的软件设计（ABSD）

  1. 三个基础

a. 对系统进行功能分解

b. 采用【架构风格】实现质量属性与商业需求

c. 采用【软件模板】设计软件结构

1. 6个主要活动（软件架构设计生命周期）

a. 架构需求分析：确定系统的关键需求，特别是非功能性需求

b. 架构设计：基于架构驱动因素，设计系统的高层次架构，选择适合的架构风格和设计模式

c. 架构复审（架构验证与评估）：对架构设计进行分析，确保其满足关键需求

d. 架构实现：架构设计转化为具体的实现方案

e. 架构演化：系统随着需求的变化而不断演进

f. 架构文档化：使用统一的文档标准记录架构设计，包括系统结构、组件关系、设计决策和权衡分析等。

• 架构文档要保持较新、及时更新，但不要随时保证文档最新，要保持文档的稳定性

• 主要输出结果是架构规格说明书、架构质量说明书

• 文档要从【使用者】的角度进行编写

• 每次架构文档修改都应该记录进行修改的原则

• 第7节：构建组装的过程中需要检测并解决【架构失配】问题

  1. 架构失配：在系统的不同部分之间存在不一致性或不兼容性

a. 失配的类型：

• 语义失配：不同组件之间的语义不一致

• 结构失配：组件之间的结构不一致

• 行为失配：组件之间的行为不一致

1. 解决架构失配的方法：

a. 使用适配器模式

b. 使用中介者模式

c. 使用桥接模式

d. 使用外观模式

• 第8节：特定领域的软件架构（DSSA）特定领域软件架构

  1. 定义：专用于一类特定类型的任务(领域)的、在整个领域中能有效地使用的、为成功构造应用系统限定了标准的组合结构的软件构件的集合

  2. 特点：

a. 一个严格定义的问题域和解决域

b. 具有普遍性，可以用于领域中某个特定领域的应用和开发

c. 对整个领域有合适程度的抽象

d. 具备该领域固定的典型开发过程中的可重用元素

1. 形成由【领域参考模型、参考需求、参考架构】等组成的开发基础架构

2. 基本活动包括：

a. 领域分析：获得领域模型，从而描述领域需求

b. 领域设计：获得DSSA（特定领域软件架构），描述领域模型中表示需求的解决方案

c. 领域实现：对基础软件架构进行实现

1. 角色：领域专家、领域分析人员、领域设计人员、领域实现人员

2. 三个层次：

a. 领域开发环境

b. 领域特定应用开发环境

c. 应用执行环境

1. 建立过程是并发的、递归的和反复进行的

a. 不同阶段（如领域分析、体系结构设计、验证等）通常需要交替进行，反复优化以适应领域需求。

1. 定义领域特定元素的阶段重点是：确定领域的通用功能和特定需求

2. 定义领域模型和体系结构的阶段目标是：抽象出领域内通用的模型和体系结构

• 第9节：设计模式

  1. MVC：模型、视图、控制器；模板引擎技术

  2. MVVM：模型、视图、视图模型；双向数据绑定

  3. 组合模式：

a. 对象组合成树形结构以表示“部分一整体”的层次结构，使得用户对单个对象和组合对象的使用具有一致性

b. 适用于：希望用户忽略组合对象与单个对象的不同

1. 外观(Facade)模式

a. 子系统中的一组接口提供一个一致的界面

b. 外观模式定义了一个高层接口，使得子系统更易使用

1. 享元(Flyweight)模式

a. 通过共享对象来支持大量细粒度的对象，对象的大多数状态都可变为外部状态

b. 享元模式使用共享技术有效地支持大量的细粒度对象

c. 适用于：系统中有大量相似对象，且这些对象的状态大部分可以外部化

1. 装饰器模式

a. 动态地给一个对象添加一些额外的职责

b. 装饰器模式提供了比继承更灵活的替代方案

c. 适用于：需要扩展类的功能，或给类添加责任

1. 工厂方法

a. 定义一个用于创建对象的接口，但由子类决定要实例化的类

b. 工厂方法使一个类的实例化延迟到其子类

c. 适用于：一个类不知道它所必须创建的对象的类

1. 观察者模式

a. 定义了一种一对多的依赖关系，使得当一个对象改变状态时，所有依赖于它的对象都得到通知并被自动更新

b. 适用于：一个对象的改变需要同时改变其他对象，且不知道有多少个对象有待改变

1. 中介者模式

a. 用一个中介对象来封装一系列的对象交互

b. 中介者使得各对象不需要显式地相互引用，从而使得耦合松散，而且可以独立地改变它们之间的交互

c. 适用于：对象之间有复杂的相互引用关系，导致难以独立地改变它们之间的交互

• 第10节：典型软件架构

  1. 分层架构

a. 定义：将系统分为多个层次，每个层次都有不同的功能和职责

b. 优点：

c. 缺点：性能开销、层次之间的耦合

d. 安全：层次之间依赖性强，某层出现问题会影响整体链路

e. 性能：层次之间的通信、调用会增加性能开销

1. 客户端-服务器架构（C/S架构）

a. 定义：将系统分为客户端和服务器两部分，客户端负责用户界面和用户交互，服务器负责数据存储和处理

b. 优点：

c. 缺点：性能开销、网络延迟、安全性问题

d. 安全：客户端容易存在安全隐患，网络开放性，有被攻击的风险

1. 微服务架构

a. 定义：将系统分为多个小的、独立的服务，每个服务负责一个特定的功能

b. 优点：

c. 缺点：开发复杂

d. 安全：需要设计额外的通信机制处理局部故障

1. 浏览器-服务器架构（B/S架构）

a. 定义：将系统分为浏览器和服务器两部分，浏览器负责用户界面和用户交互，服务器负责数据存储和处理

b. 优点：

c. 缺点：性能开销、网络延迟、安全性问题

1. 事件驱动架构

a. 定义：将系统分为多个事件源和事件处理器，事件源负责产生事件，事件处理器负责处理事件

b. 优点：

c. 缺点：容易发生死循环、难处理高并发问题

1. 微内核架构

a. 定义：将系统分为核心和插件，核心负责基本功能，插件负责扩展功能

b. 优点：

c. 缺点：进程间通信开销大

第十章 案例分析的答题方法

• 第1节 ： 问优点

  1. 多源、分布式相关: 提高了数据存储和处理效率

  2. 扩展性: 扩展性好，可以根据需要增加字段、数据源，使信息更加丰富

  3. 为何选择xxx？

a. 兼容性：能够接收处理现有的xxx数据

b. 可伸缩性：可以线性扩展，适用不断增长的xxx

c. 高吞吐量、可以削峰填谷

d. 低延迟：满足xxx对时间的需求

e. 持久化

f. 生态

g. 发布-订阅模式：多消费者独立、不相互影响

1. 共同点和差异

a. 从使用场景、资源、成本、软硬件依赖、数据存储等

b. 从题目着手，在xxx 和 xxx 两个方面的差异，那就说谁比谁好

• 第2节：系统建模

  1. 系统的参与者不仅仅是人，时间、打印机等物体也算

• 第3节：软件架构

  1. 特点：就是把题目的需求挨个说一下好处

  2. 各层内涵：根据设计的每一层，说一下匹配的需求

  3. 分布式架构和集中式架构：向外扩展（数据复制、切分、缓存）、向上扩展（升级硬件、增加硬件数量）

  4. 数据库的实现：读写分离（数据复制）、分布式数据库、多热备份、多数据缓存

  5. 关系型数据库和 nosql 数据库

a. 扩展性：

• 关系型数据库：垂直和有限水平扩展

• nosql 数据库：线性扩展

b. 适用

• 关系型数据库：适合复杂查询、事务

• nosql 数据库：大量高并发写入

1. 分布式文件系统 HDFS

a. 数据可靠性：数据冗余存储（三副本）和自动容错机制（如数据块复制、心跳检测和数据块扫描等）

b. 伸缩性：可以添加节点来进行线性扩展，能够支持 PB 级数据存储

c. 性能方面：优化读写路径以及利用硬件特性（磁盘并行读写）

• 第4节：系统的差异

  1. 实时性：硬实时系统、实时系统（Linux）

  2. 安全性：任务间无隔离保护、进程间隔离保护

• 第5节：故障

  1. 硬件故障：CPU、存储、定时器等

  2. 应用软件故障：数值越界、除0、溢出、异常、超时等

  3. 操作系统故障：越权访问、死锁、资源不足、调度超时等

  4. 故障滤波算法：门限算法、递减、递增、周期滤波算法

  5. 故障容错算法：N+1备份、冷备、温备、热备

十一. 论文

• 第1节：摘要

  1. 202x 年 x 月，我参与了某公司xxx平台项目的建设，该系统包含xxx、xxx、xxx几大功能模块，能够xxx，从而可以在xxx，在该项目中我担任系统架构设计师，负责整体系统架构设计工作。

  2. 本文以该xxx项目为例，主要讨论了“题目”在该项目中的具体应用，该项目历时 x 个月，与xxx 日交付成功上线，获得了用户的一致好评。

• 第2节：正文

  1. 项目背景：为什么要做这个项目

  2. 项目的功能和技术介绍

  3. 回应子题目并过渡到主体

a. 经历 xxx 个月的项目开发，该xxx系统顺利投入使用，协助客户xxx，运行至今客户反馈良好，该系统由于xxx等原因，建设过程困难重重，但由于笔者及项目团队成员十分重视项目的“题目”，最终保证了该项目的按质按量顺利交付。

b. 当然，在本项目中，还有一些不足，比如xxxx，在后续的学习和工作中，我将不断和同行进行交流，提升自己的专业技术水平，更好的完成系统架构设计工作。