{"name":"可用性","id":"软件工程-架构-系统设计-可用性","content":"# 可用性\n\n> **可用性是一种系统能力 + 组织能力的综合结果**\n\n## 可用性的第一性原理\n\n### 不可违背的客观事实\n\n1. **故障一定会发生**\n\n   * 硬件会坏\n   * 软件必然有 Bug\n   * 网络一定不可靠\n   * 人一定会犯错\n\n2. **网络分区不可避免**\n\n   * 分布式系统无法获得全局一致视图\n   * 状态判断永远存在不确定性\n\n3. **状态决策不可能 100% 正确**\n\n   * 主备切换、多主选举一定存在误判\n   * 所谓\"正确\"只是概率更高\n\n4. **可用性是概率，不是确定性**\n\n   * 高可用 ≠ 不宕机\n   * 高可用 = 快速恢复 + 可控影响\n\n5. **人是系统的一部分**\n\n   * 既是修复者\n   * 也是最大的不稳定源\n\n> **高可用的本质，是与不确定性共存，而不是消灭它**\n\n### 高可用设计的核心权衡\n\n| 权衡 | 来源 |\n| ---- | ---- |\n| 一致性 vs 可用性 | 网络分区不可避免、状态决策不可能100%正确 |\n| 成本 vs 风险 | 越高的可用性，价格越贵——每提升一个9，成本指数增长，但风险降低边际递减 |\n| 自动化 vs 可控性 | 人是系统的一部分，也是最大不稳定源 |\n| 复杂度 vs 收益 | 过度设计引入新风险——只在必要处投入复杂度，追求适度复杂而非消灭所有不确定性 |\n\n### 高可用设计7大核心原则\n\n| 原则 | 核心思想 | 实践要点 |\n| ---- | -------- | -------- |\n| **少依赖原则** | 能不依赖就不依赖，越少越好 | 系统间有依赖就有风险传递，应优先考虑无依赖设计 |\n| **弱依赖原则** | 强依赖转化为弱依赖 | 异步化、解耦、设置合理超时；如积分服务故障不影响交易核心链路 |\n| **分散原则** | 鸡蛋不放一个篮子，分散风险 | 避免全局只有一份，数据/服务多副本部署 |\n| **均衡原则** | 均匀分散风险，避免不均衡 | 负载均衡权重合理，避免某台机器过载 |\n| **隔离原则** | 控制故障不扩散、不放大 | 代码/线程/进程/读写/数据隔离，隔离级别越高容灾能力越强 |\n| **无单点原则** | 有冗余有退路，快速切换能力 | 冗余设计、快速止血（切换/回滚/扩容），单点限制整体可靠性 |\n| **自我保护原则** | 少流血，牺牲一部分保护核心 | 限流、降级等主动保护机制，极端情况下可控损失 |\n\n## 核心概念与指标体系\n\n### 核心属性\n\n| 概念                | 本质          | 关注点   |\n| ----------------- | ----------- | ----- |\n| 可靠性（Reliability）  | 持续无故障运行的概率  | 宕机次数  |\n| 可用性（Availability） | 系统可被使用的时间比例 | 宕机时长  |\n| 稳定性（Stability）    | 行为一致性与退化趋势  | 抖动、劣化 |\n\n三者共同构成系统的持续服务能力\n\n| 关系 | 说明 |\n| ---- | ---- |\n| 可靠性 → 可用性 | 可靠性是前置条件：频繁故障必然累积宕机时长，MTBF 缩短直接拉低可用性 |\n| 稳定性 → 可靠性 | 性能抖动、逐步劣化意味着 MTBF 缩短，系统趋近故障边缘而不自知 |\n| 高可靠性 ≠ 高可用性 | 系统从不宕机，但恢复耗时过长 → 可用性仍低 |\n| 高可用性 ≠ 高可靠性 | 快速恢复能力掩盖了频繁小故障的本质，可靠性仍然差 |\n\n> **可靠性**解决\"少坏\"，**稳定性**解决\"少抖\"，**可用性**是最终结果——但任一者的短板都会拖累整体\n\n### 核心指标\n\n* MTBF：平均故障间隔\n* MTTR：平均恢复时间\n\n```\nAvailability = MTBF / (MTBF + MTTR)\n```\n\n业务维度：\n\n* RTO：允许的最大恢复时间\n* RPO：允许的数据丢失量\n\n### 服务级别体系\n\n| 概念 | 全称 | 作用 | 视角 |\n|------|------|------|------|\n| **SLI** | Service Level Indicator | 实际测量的指标 | 度量 |\n| **SLO** | Service Level Objective | 目标值 | 内部目标 |\n| **SLA** | Service Level Agreement | 对外承诺/合同 | 外部承诺 |\n\n```\nSLI（实际测量） → SLO（目标值） → SLA（对外承诺）\n    ↓                ↓              ↓\n  我实际怎样      我要达到什么      我保证什么\n```\n\n**与 RTO/RPO 的区别：**\n\n* RTO/RPO：灾难恢复视角，偏极端场景\n* SLO：日常运行视角，持续性目标\n\n## 可用性能力分层模型\n\n```\nL5 组织与治理能力（文化、流程、演练）\nL4 业务连续性能力（RTO / RPO）\nL3 系统级可用性（MTTR）\nL2 组件级可靠性（MTBF）\nL1 基础设施可靠性\n```\n\n> **越往上，越偏人和组织；越往下，越偏技术**\n\n## 架构性手段（设计期：降低故障概率）\n\n### 冗余（Availability 的基础）\n\n* 计算冗余：无状态 → 易冗余\n* 存储冗余：有状态 → 一致性困难\n\n**关键认知：**\n\n> 冗余并不能保证高可用，只是提供\"选择权\"\n\n#### 状态决策的三种模式\n\n* 互连式\n* 中介式\n* 探测式\n\n**本质问题：**\n\n> 状态信息本身也是不可靠的\n\n### 隔离（控制故障影响面）\n\n#### 隔离的目标\n\n* 限制资源争抢\n* 阻断故障扩散\n* 防止\"滚雪球效应\"\n\n#### 隔离能力树\n\n```\n隔离能力\n├─ 资源隔离\n│  ├─ 线程\n│  ├─ 进程\n│  └─ 机器\n├─ 流量隔离\n│  ├─ 正式 / 压测\n│  ├─ 爬虫\n│  └─ 链路\n├─ 数据隔离\n│  ├─ 读写分离\n│  └─ 多中心\n├─ 机房隔离\n│  ├─ 同城\n│  ├─ 异地\n│  └─ 跨国\n```\n\n### 存算分离（复杂度转移）\n\n> **让计算节点无状态，是提升可用性的关键简化手段**\n\n* 计算失败 → 重试 / 迁移\n* 状态集中 → 一致性成本集中化\n\n## 运行时控制手段（故障发生时）\n\n### 限流 / 熔断 / 降级的角色划分\n\n| 手段 | 保护对象  | 本质   |\n| -- | ----- | ---- |\n| 限流 | 服务提供方 | 资源保护 |\n| 熔断 | 服务调用方 | 自我保护 |\n| 降级 | 系统整体  | 有损服务 |\n\n### 降级的业务哲学\n\n* 降级更多地是一种**业务决策**\n* 距离用户越近，用户体验损失越小\n* 核心目标：**用户无感或弱感知**\n\n#### 降级类型抽象\n\n```\n降级策略\n├─ 数据降级（默认值 / 静态值 / 缓存）\n├─ 功能降级（关闭非核心）\n├─ 流量降级（限流）\n├─ 写降级（异步 / 延迟）\n├─ 前端降级（静态化）\n```\n\n### 其他运行时手段\n\n| 手段 | 时机 | 本质 |\n| ---- | ---- | ---- |\n| **切换（Failover）** | 故障后 | 主备/多活自动切换，提供备选路径 |\n| **扩容（弹性伸缩）** | 故障中 | 增加处理能力扛住流量 |\n| **重试（Retry）** | 故障中 | 失败请求自动重试，指数退避避免雪崩 |\n\n## 变更与治理（人为风险控制）\n\n### 变更是最大风险源\n\n> **大部分事故不是系统设计错误，而是变更失控**\n\n#### 变更生命周期\n\n* 变更前：评估 + 回滚计划\n* 变更中：分级发布 + 监控\n* 变更后：指标回归验证\n\n### 数据逻辑保护\n\n数据变更是不可逆风险最高的操作\n\n* 审核链路：DBA → PO → Dev\n* 防错优于修复\n* 备份必须可恢复（定期演练）\n\n## 容灾与业务连续性（极端场景）\n\n### 容灾的层次\n\n* 基础设施容灾\n* 数据容灾\n* 应用容灾\n* 业务容灾\n\n### DRP / BCP 的本质\n\n> 容灾不是技术方案，而是**组织应急能力**\n\n* 预案\n* 演练\n* 角色\n* 决策链路\n\n## 可观测性与健康治理\n\n### 监控的四个维度\n\n* 资源\n* 系统\n* 异常\n* 业务\n\n### 架构健康的三大对象\n\n```\n架构健康\n├─ 应用健康\n├─ 环境健康\n└─ 依赖健康\n```\n\n目标不是\"零问题\"，而是：\n\n> **问题可预期、可发现、可处理**\n\n## 评估与持续演进\n\n### FMEA：事前失败分析\n\n* 从\"功能\"视角，而非\"组件\"视角\n* 关注业务影响而非技术优雅\n\n### SRE 文化\n\n* 混沌工程\n* 可用性评估\n* 持续演进而非一次性设计\n\n## 适用边界\n\n**可用性是成本函数，不是越高越好**\n\n每提升一个9，成本指数增长。超出业务需求的可用性是资源浪费。\n\n**服务必须分级，资源必须差异化投放**\n\n核心与非核心不等量齐观。有限资源优先保障核心链路。\n\n**低价值场景不需要高可用**\n\n内部工具、后台系统、一次性任务等非用户Facing服务，应允许中断。\n\n**过度设计的危害不亚于低可用**\n\n用微服务架构支撑小业务、用5个9保护可容忍中断的系统，这是另一种风险。\n\n**业务中断损失是决策基准**\n\n可用性目标应由业务中断损失决定，而非技术洁癖。算清账再投入。\n\n**生存期优先于可用性**\n\nPMF阶段，活着比什么都可用重要。过早的高可用设计会拖死产品。\n\n## 关联内容（自动生成）\n\n- [/软件工程/架构/系统设计/可观测性.md](/软件工程/架构/系统设计/可观测性.md) 可观测性是实现高可用系统的重要手段，通过监控、日志和追踪实现问题的快速发现和处理\n- [/软件工程/架构/系统设计/分布式/分布式系统.md](/软件工程/架构/系统设计/分布式/分布式系统.md) 分布式系统设计与可用性密切相关，涉及故障处理、容错机制和一致性权衡\n- [/软件工程/架构/系统设计/缓存.md](/软件工程/架构/系统设计/缓存.md) 缓存设计是提升系统可用性的重要手段，通过减轻后端压力和提供降级能力保障服务可用\n- [/软件工程/架构/系统设计/网关.md](/软件工程/架构/系统设计/网关.md) 网关承担着限流、熔断、降级等保障系统可用性的关键职责\n- [/软件工程/架构/系统设计/高并发.md](/软件工程/架构/系统设计/高并发.md) 高并发系统设计与可用性密切相关，涉及流量控制、资源隔离和系统稳定性保障\n- [/软件工程/微服务/服务治理/服务容错.md](/软件工程/微服务/服务治理/服务容错.md) 服务容错机制是保障系统可用性的核心技术，包括熔断、降级、限流等手段\n- [/软件工程/架构/系统设计/流量控制.md](/软件工程/架构/系统设计/流量控制.md) 流量控制与限流/熔断共同构成运行时保护体系\n- [/软件工程/架构/系统设计/故障管理.md](/软件工程/架构/系统设计/故障管理.md) 故障发现→定位→恢复的完整流程是可用性治理的核心环节\n- [/软件工程/架构/系统设计/混沌工程.md](/软件工程/架构/系统设计/混沌工程.md) 混沌工程通过主动注入故障来验证系统韧性，是 SRE 文化的重要实践\n- [/软件工程/架构/系统设计/伸缩性.md](/软件工程/架构/系统设计/伸缩性.md) 弹性扩缩容是应对故障和峰值压力的重要手段\n- [/软件工程/架构/系统设计/云原生.md](/软件工程/架构/系统设计/云原生.md) 云原生架构通过容器、微服务等技术为系统可用性提供新的解决方案\n- [/计算机网络/rpc.md](/计算机网络/rpc.md) RPC框架的容错与失败处理机制是保障分布式系统可用性的关键技术\n","metadata":"tags: ['软件工程', '数据库', '计算机系统', '分布式系统']","hasMoreCommit":false,"totalCommits":1,"commitList":[{"date":"2026-06-11T22:56:06+08:00","author":"MY","message":"feat(cache): 添加缓存装饰器自定义键支持并优化缓存策略","hash":"ceec5426ef50ec3fe0b850b4975a7e3c8a930927"}],"createTime":"2026-06-11T22:56:06+08:00"}