【系统架构师案例题-知识点】可靠性与安全性设计
阅读这篇时，可以按三个层次把握：先理解系统为什么会失效、为什么会被攻击，再理解不同设计手段各自保什么，最后把这些概念翻译成案例题里的标准答法。
一、先建立整体认识
很多人学这一章时，会把“可靠性”和“安全性”当成两堆互不相关的名词。其实它们都在回答同一个更大的问题：系统出了问题时，还能不能继续被正确、安全地使用。
只不过两者关注的风险来源不同：
- 可靠性更关注故障、异常、组件失效、软件缺陷
- 安全性更关注攻击、越权、泄露、篡改、滥用
放到真实系统里看，这两类问题几乎总是同时存在。
- 支付系统最怕服务挂掉，这属于可靠性问题
- 支付系统也怕账户被盗刷、报文被篡改，这属于安全性问题
- 电商在大促时要防止服务雪崩，这是可靠性问题
- 电商在大促时也要防止恶意刷接口、撞库和越权，这是安全性问题
所以，这一章真正要掌握的不是“术语定义”，而是下面几类能力：
- 系统出故障时，如何尽量不停机或尽快恢复
- 一个方案出错后，系统如何继续给出可信结果
- 数据传输和存储时，如何防止泄露和篡改
- 用户访问系统时，如何确认身份并控制权限
二、可靠性到底在保什么
1. 为什么可靠性会成为架构问题
当系统只有一台机器、一个进程、一个数据库时，很多问题还不明显。一旦系统规模扩大，故障就会从偶发事件变成必然事件。
常见场景包括：
- 机器宕机，服务实例不可用
- 网络抖动，调用超时或重试风暴
- 软件缺陷在特定条件下被触发
- 外部依赖响应过慢，拖垮主链路
- 人工误操作导致配置错误或服务中断
所以，可靠性不是“系统永远不出错”，而是系统在规定条件和规定时间内，仍然能完成规定功能的能力。
2. 常见指标怎么理解
| 指标 | 含义 | 更直观的理解 |
|---|---|---|
MTTF(Mean Time To Failure) | 平均无故障时间 | 一次故障发生前，系统平均能稳定运行多久 |
MTTR(Mean Time To Repair) | 平均修复时间 | 出故障后，平均多久能修好 |
MTBF(Mean Time Between Failures) | 平均故障间隔时间 | 一次故障到下一次故障之间的平均间隔，MTBF = MTTF + MTTR |
| 可用度 | A = MTTF / (MTTF + MTTR) | 系统从总体上有多少时间处于可正常服务状态 |
怎么理解：
MTTF越大，说明系统越不容易坏MTTR越小，说明系统坏了也能更快恢复- 可用度越接近
1，系统整体越稳定
在工程上，提升可靠性往往不是只靠“少出故障”，还要靠“出故障后尽快恢复”。
3. 提高可靠性的常见思路
| 思路 | 典型手段 | 解决什么问题 |
|---|---|---|
| 冗余 | 主备、双机、多副本、多路径 | 某个部件坏了还能切走 |
| 检错 | 校验、超时检测、断言、心跳 | 尽快发现异常 |
| 容错 | 恢复块、N 版本、冗余切换 | 出错后仍能继续产出结果 |
| 异常处理 | 重试、降级、熔断、补偿 | 把故障限制在可控范围 |
| 监控与告警 | 健康检查、日志、指标、链路追踪 | 及时发现和定位问题 |
一句话记忆：可靠性设计既要考虑“怎么少出错”，也要考虑“出了错怎么别扩大”。
三、软件可靠性和硬件可靠性为什么不一样
这是案例题高频对比点，关键不是死记表格，而是看清两者为什么不同。
题目如果要求比较软硬件可靠性，不要只背“软件不会老化”。更好的答法是：硬件故障更多来自物理损耗，软件故障更多来自设计和实现缺陷，因此两者的失效规律、维修方式和预警特征都不同。
1. 差异的根源
硬件是物理实体，会老化、磨损、损坏；软件是逻辑实体，本身不会像硬件那样因使用时间增长而自然磨损，但软件中的缺陷会在特定条件下被触发。
2. 常见对比
| 维度 | 硬件可靠性 | 软件可靠性 | 怎么理解 |
|---|---|---|---|
| 失效率变化 | 常呈浴盆曲线 | 通常不因“用久了”自然升高 | 软件没有物理磨损 |
| 是否会闲置老化 | 会 | 不会 | 只要介质不坏，软件逻辑本身不会氧化 |
| 维修后的状态 | 更换零件可恢复 | 改代码可能引入新缺陷 | 软件维护本身也是风险源 |
| 失效前征兆 | 常有退化迹象 | 往往突然触发 | 软件 Bug 常在特定输入或并发条件下暴露 |
四、恢复块与 N 版本程序设计
1. 为什么要有软件容错
有些系统不能接受“一错就停”。比如航空控制、工业控制、金融清算、关键监测系统，一次错误结果可能就会造成非常高的代价。
这时就会引出软件容错思路：不是假设程序永远不会错，而是承认它可能出错，并提前设计好出错后的收敛方式。
2. 恢复块怎么理解
恢复块可以理解为“一个方案失败了，就回退并尝试另一个方案”。
它通常包含：
- 主块：优先执行的版本
- 后备块：功能等价但实现不同的备选版本
- 验证测试：判断当前结果是否可接受
- 异常处理：所有版本都失败时的兜底措施
它的典型流程是：
- 先执行主块
- 用验证测试判断结果是否正确
- 如果不正确，则回退到执行前状态
- 再执行后备块
- 直到某个版本通过验证，或最终走异常处理
关键特征：
- 更像顺序重试
- 依赖验证测试程序
- 采用反向恢复思路
- 实时性通常较差，因为可能要多次尝试
3. N 版本程序设计怎么理解
N 版本程序设计可以理解为“让多个独立实现同时算，再通过表决选结果”。
它的核心做法是：
- 由多个团队独立开发多个功能等价的版本
- 多个版本并行运行
- 通过表决器选出多数一致的结果
关键特征：
- 更像并行冗余
- 依赖表决机制
- 采用向前恢复思路
- 实时性通常更好，因为不需要一次次回退重试
4. 两者怎么对比
| 维度 | 恢复块 | N 版本程序设计 |
|---|---|---|
| 执行方式 | 顺序尝试 | 并行执行 |
| 检测方法 | 验证测试 | 表决 |
| 恢复策略 | 反向恢复 | 向前恢复 |
| 资源开销 | 相对较低 | 相对较高 |
| 实时性 | 较差 | 较好 |
| 实现难点 | 验证测试难设计 | 多版本独立开发成本高 |
5. 怎么考，怎么答
如果题干强调“单个方案失败后回退、换后备方案继续执行”，优先想到恢复块；如果题干强调“多个版本并行执行、最后投票选结果”，优先想到 N 版本程序设计。
答题时最好把“运行方式、检测方法、恢复策略、实时性”四个维度一起写出来，这样更像标准答案。
五、安全设计先看系统到底怕什么
1. 安全不是“加密一下”这么简单
很多人一提安全，第一反应就是加密。但真实系统里的安全设计远不止如此。
一个系统可能同时面临：
- 数据被偷看
- 数据被篡改
- 服务被打挂
- 账号被冒用
- 权限被越权提升
- 操作过程无法追溯
所以安全设计首先要回答的是：系统最怕什么风险，哪些资产最值得保护。
2. CIA 三要素怎么理解
| 要素 | 含义 | 更像什么风险 |
|---|---|---|
机密性(Confidentiality) | 信息不被未授权访问 | 数据泄露、窃听、拖库 |
完整性(Integrity) | 信息不被非法篡改 | 篡改报文、伪造数据、中间人攻击 |
可用性(Availability) | 合法用户能正常使用系统 | DDoS、资源耗尽、恶意刷接口 |
怎么理解：
- 机密性解决“别人不该看见却看见了”
- 完整性解决“数据被偷偷改了”
- 可用性解决“系统本该能用却被打挂了”
3. 常见安全机制
| 机制 | 作用 | 更像解决什么问题 |
|---|---|---|
| 认证 | 确认你是谁 | 防止冒名登录 |
| 授权 | 确认你能做什么 | 防止越权访问 |
| 加密 | 保护数据内容 | 防止窃听和泄露 |
| 审计 | 记录谁做了什么 | 便于追责与追踪 |
| 访问控制 | 对资源访问设置规则 | 把权限真正落到系统里 |
4. 安全设计原则怎么记更容易
| 原则 | 直观理解 |
|---|---|
| 最小权限 | 只给完成任务所需的最少权限 |
| 纵深防御 | 不把安全压在一层上，要多层拦截 |
| 默认拒绝 | 没明确放行的，默认不允许 |
| 安全失败 | 出问题时宁可拒绝服务，也不要放开敏感数据 |
| 公开设计 | 安全不应依赖“别人不知道实现细节” |
六、加密、摘要、数字签名怎么分工
1. 对称加密为什么常用于传输大量数据
对称加密的特点是加密和解密使用同一个密钥。它的最大优势是快，所以非常适合大量数据加密。
| 算法 | 特点 | 工程上的常见判断 |
|---|---|---|
| AES | 主流对称加密标准 | 实际系统最常见 |
| DES | 密钥太短 | 已不安全 |
| 3DES | 比 DES 强，但更慢 | 已逐步被 AES 取代 |
2. AES 为什么常考
因为它是现实工程里最典型的对称加密方案，考试也喜欢围绕它出细节题。
常见要点包括：
- AES 分组大小固定为128 位，也就是16 字节
- 密钥长度可以是
128 / 192 / 256位 - 明文超过一个分组时，需要分块处理
- 最后一块不足时要填充
- 工作模式决定分组之间如何组织
前面几条是在说明 AES 这个算法本身的基本特征，但真实系统里很少只加密“一个分组”。一旦数据超过 16 字节，就会涉及“多个分组怎么串起来加密”的问题，这就是为什么这里会继续讲工作模式。
可以把它理解成：AES 负责“单个分组怎么加密”，工作模式负责“多个分组整体怎么组织、怎么加密，以及是否顺便考虑防篡改”。
工程上常见的理解方式是：
ECB(Electronic Codebook)
这里Electronic可以理解成“电子方式的”，Codebook可以理解成“密码本”。它的意思接近“每个明文分组都像拿去查同一本密码本，独立变成密文”。因为每一块都是各算各的，所以相同明文块会得到相同密文块，容易暴露数据规律，一般不推荐CBC(Cipher Block Chaining)
这里Cipher是“密文/加密”，Block是“分组”，Chaining是“链接、串起来”。它的核心意思是“当前分组不要单独算，而是和前一个分组串起来再加密”。这样就能避免ECB那种重复明文直接暴露重复密文的问题，但要正确处理IV（Initialization Vector，初始化向量）CTR(Counter Mode)
这里Counter是“计数器”，Mode是“模式”。它的做法可以理解成“不断递增计数器，生成一串密钥流，再和明文结合”，所以它在使用体验上更像流式处理。它的好处是实现灵活、性能较好，也更适合并行处理GCM(Galois/Counter Mode)
这里Counter还是计数器模式，前半部分Galois指的是伽罗瓦域上的数学运算，主要用来做完整性校验。可以把它粗略理解成“CTR 模式 + 防篡改校验”。所以它不仅能加密，还能校验数据有没有被改动，也就是同时兼顾机密性和完整性，因此现代系统里更常推荐
3. 非对称加密解决什么问题
非对称加密使用一对密钥，通常是公钥和私钥。它最大的价值不是速度，而是解决密钥分发难题。
它的核心原理可以先这样理解：这两个密钥是成对生成的，数学上彼此关联，但作用不同。你可以把公钥理解成“可以公开的锁”，把私钥理解成“只有持有者自己保管的钥匙”。
- 用公钥加密的数据，原则上只能用对应的私钥解开
- 用私钥处理过的数据，可以用对应的公钥验证
所以它和对称加密最大的区别在于：对称加密最怕“双方怎么安全地提前共享同一个密钥”，而非对称加密里，公钥本来就是可以公开发给别人的，真正需要保密的只有私钥。
再往工程上翻译，就是：
- 接收方先公开自己的公钥
- 发送方用这个公钥加密一个临时会话密钥，发给接收方
- 只有持有私钥的接收方才能把这个会话密钥解出来
- 后续双方再用这个会话密钥做对称加密传输大量数据
这样就解决了“对称密钥一开始怎么安全送过去”的问题。这也是为什么非对称加密常用于密钥交换和身份建立，而不常直接拿来加密大批量业务数据。
| 算法 | 特点 |
|---|---|
RSA(Rivest-Shamir-Adleman) | 经典、常见、基于大数分解难题 |
ECC(Elliptic Curve Cryptography) | 同等安全性下密钥更短、性能更好 |
工程上的常见组合：非对称加密负责安全交换会话密钥，对称加密负责后续的大量数据传输。这也是 HTTPS/TLS 中最经典的分工。
4. 哈希不是加密
哈希的核心特点是把任意长度输入映射成固定长度摘要，而且不可逆。它不是用来“保密”的，而是用来做完整性校验、签名基础和密码存储等。
| 算法 | 说明 |
|---|---|
| MD5 | 已不安全 |
| SHA-1 | 已不推荐 |
| SHA-256 | 目前更主流 |
一个很重要的区分：
- 加密解决“别人看不懂”
- 哈希解决“内容有没有变化”
5. 数字签名到底保什么
数字签名不是为了保密，而是为了证明“这份内容确实是某人发的，而且没被改过”。
典型过程是：
- 发送方先对数据做摘要
- 再用自己的私钥对摘要签名
- 接收方用发送方公钥验证签名
它通常提供三类保证：
- 完整性：数据没有被篡改
- 身份认证：能确认发送方身份
- 不可否认性：发送方事后不能否认自己签过名
七、访问控制模型怎么选
1. 访问控制在解决什么问题
认证只能说明“你是谁”，并不能说明“你能不能做这件事”。真正把权限管起来，靠的是访问控制模型。
2. 常见模型
| 模型 | 特点 | 更像什么场景 |
|---|---|---|
DAC(Discretionary Access Control) | 自主访问控制，资源拥有者自行决定授权 | 个人文件共享、弱中心化场景 |
MAC(Mandatory Access Control) | 强制访问控制，系统基于安全标签强制控制 | 军事、涉密、强等级保护场景 |
RBAC(Role-Based Access Control) | 基于角色的访问控制，通过角色组织权限 | 企业系统、后台管理、SaaS 平台 |
ABAC(Attribute-Based Access Control) | 基于属性的访问控制，根据用户、资源、环境等属性动态决策 | 复杂策略、细粒度控制、多租户场景 |
3. RBAC 为什么最常考
因为大多数业务系统里，最自然的权限组织方式就是“用户 -> 角色 -> 权限”。
例如：
- 管理员可以管理用户和系统配置
- 审计员只能看日志和报表
- 普通用户只能查看和操作自己的数据
RBAC 的核心不是“直接给用户发一堆权限”，而是先定义角色，再把权限赋给角色，再把用户关联到角色。这样更适合管理，也更容易扩展。
4. ABAC 为什么更灵活
ABAC 不只看“你是谁”，还可以看：
- 资源属于谁
- 请求发生在什么时间和地点
- 当前网络环境是否可信
- 数据是否属于当前租户
所以它更适合细粒度、动态化、安全规则复杂的系统，但实现和治理成本也更高。
八、怎么考，怎么答
1. 可靠性题
题干如果强调“平均故障间隔时间、修复时间、可用度”，通常是在考可靠性指标；如果强调“主备切换、容错、监控、降级”，通常是在考如何提升可靠性。
2. 恢复块与 N 版本题
题干如果出现“后备版本、验证测试、回退重试”，优先想到恢复块；如果出现“多个版本并行运行、表决器、多数投票”，优先想到 N 版本程序设计。
3. 安全机制题
题干如果问“如何证明身份”，写认证；如果问“如何限制操作范围”，写授权或访问控制；如果问“如何防篡改”，写完整性校验、摘要或数字签名；如果问“如何防泄露”，写加密。
4. 加密方案题
题干如果是“大量数据传输”，优先想到对称加密；如果重点是“安全分发密钥”或“建立信任”，优先想到非对称加密；如果重点是“校验内容是否被改”，优先想到哈希或数字签名。
九、答题模板
1. 可靠性定义题
可靠性是指软件系统在规定条件和规定时间内完成规定功能的能力。提高系统可靠性通常可采用冗余、检错、容错、异常处理和监控告警等手段。
2. 软硬件可靠性对比题
硬件可靠性受物理磨损和老化影响，失效率通常呈浴盆曲线；软件不存在物理磨损，不会因闲置而老化，但软件修改可能引入新的缺陷，因此两者在失效规律和维护方式上存在明显差异。
3. 恢复块 / N 版本题
恢复块采用顺序执行和验证测试机制，在主块失败后回退并尝试后备块，属于反向恢复；N 版本程序设计采用多个独立版本并行执行，通过表决器输出结果，属于向前恢复，实时性通常更好，但资源成本更高。
4. 安全三要素题
安全性通常从机密性、完整性和可用性三个方面考虑。机密性防止未授权访问，完整性防止数据被非法篡改，可用性保证合法用户能持续访问系统资源。
5. 加密方案题
对称加密适合大量数据加密，非对称加密适合密钥交换和身份建立，摘要算法适合完整性校验，数字签名适合验证身份、完整性和不可否认性。工程上通常将多种机制组合使用，而不是只依赖单一算法。