可用性是系统的命脉。 追求高可用，本质上是在成本与风险之间寻找平衡，通过架构设计来对抗不可避免的系统性故障。本文将从指标、架构、数据、容灾、确定性保障、监控与观测、组织与流程七个方面拆解高可用体系。其中，个人认为架构高可用、数据高可用、监控与观测是支撑高可用性的三大核心支点。

指标

核心时间指标

这是衡量运维响应与修复能力最直观的三个指标：

MTBF (Mean Time Between Failures)： 平均故障间隔时间。衡量系统的可靠性，MTBF 越长，说明系统越稳。

MTTR (Mean Time To Repair)： 平均修复时间。从发现故障到业务恢复的时间。这个值越小，说明你的应急预案和自动化恢复越强。

MTTD (Mean Time To Detection)： 平均检测时间。从故障发生到监控报警的时间。这考量的是监控系统的灵敏度。

数据与业务连续性指标

在发生灾难性故障（如机房断电、地震）时，仅看时间是不够的，还要看数据保得住保不住：

• RTO (Recovery Time Objective)： 恢复时间目标。即企业能忍受多长时间的业务中断。
• RPO (Recovery Point Objective)： 恢复点目标。即企业能忍受多长时间的数据丢失。比如每 10 分钟备份一次，RPO 就是 10 分钟。

可用率百分比

这是最通用的行业标准，通常用 “几个9” 来表示系统在一年内可正常服务的时间占比。

总结来说：单纯追求“5个9”会带来成本的指数级上升。一般来说：非核心业务 追求 3个9，侧重于快速手动恢复。核心业务 追求 4个9，系统必须具备自动切换和冗余部署。只有极端核心才会追求 5个9，做多地多中心架构。

架构

如果把系统比作一辆车，高可用架构的影响就在于：它不只是把零件堆在一起，而是设计了一套冗余与自愈机制——当一个轮胎爆了，备胎能秒级自动换上（冗余）；当发动机过热，它能自动降速而不至于自燃（限流降级）；即便电路短路，也只影响车灯而不影响刹车（故障隔离）。

简而言之，架构决定了系统在面对不可避免的硬件故障、网络波动或流量洪峰时，是整体停服，还是能维持核心功能的持续运行。

负载均衡

负载均衡不仅分发了流量，同时也增加了水平扩展性、消除单点故障。

无状态化

指服务端不保存请求的上下文信息，高可用架构追求的是“将状态抽离”，使其业务服务器保持无状态。

负载均衡器

根据应用场景，常见的负载均衡器可以分为软件负载均衡、硬件负载均衡、云原生负载均衡这三类。其中软件负载均衡是最常用的，灵活性高。负载均衡高可用方案架构表如下：

流量治理与容错设计

超时重试： 避免一个响应缓慢的下游服务占满整个系统的线程池。

熔断降级： 当某个服务故障率达到阈值，直接切断对它的调用，返回降级数据，防止雪崩效应。

服务限流： 保护系统不被突发洪峰流量压垮。

异步解耦： 使用消息队列平滑峰值流量，即使下游暂时不可用，消息也会堆积在队列中，等恢复后再处理。

故障检测与自动切换

当服务的主节点挂掉时，系统必须能自动识别并切换。

• 健康检查： 健康检查是数据高可用的第一步，它负责实时监控服务节点是否处于“存活”且“可用”的状态。
• 流量无感切换：利用 VIP（虚拟 IP）漂移或 HAProxy存量代理层，完成主从切换，对业务透明。
• 分布式选主：当原有的“主节点”挂掉后，剩下的“从节点”需要通过某种机制选出新的老大。

数据

应用挂了可以重启，数据丢了或乱了则是灾难。数据高可用的核心挑战在于：如何实现有效的数据冗余，以及如何维持数据一致性。

数据冗余

没有冗余就没有可用性。必须确保数据在物理空间上有多个副本。

• 主从复制 最基础的模式。主库负责写，从库负责读或作为备份。
• **多活部署 ** 在不同地理位置（机房或城市）部署多个对等的数据库节点，不仅容灾，还能就近提供服务。
• 分片 将大数据集拆分到不同物理机器上。虽然分片主要是为了性能，但通过限制故障域（即一个分片挂了，只影响部分数据），也间接提升了系统的整体可用性。

数据一致性

在分布式环境下，CAP 定理（一致性、可用性、分区容错性）是绕不开的，数据复制方案就是在CP和AP之间做取舍。

• 同步复制：主库写完，从库也写完，才返回成功。优点是不丢数据，缺点是延迟高（受网络影响大）。
• 异步复制：主库写完立刻返回，后台慢慢传给从库。性能好，但主库宕机时可能丢失少量还没传完的数据。
• 半同步复制：折中方案。主库确保至少一个从库收到了数据就返回。

示例

以Mysql为例，在数据冗余的复杂性与数据一致性带来的延迟之间进行权衡取舍，常见的实现方案如下：

容灾

容灾是是应对“黑天鹅”事件（如地震、光缆被挖断）的终极手段，是保证可用性的最后一层防线，不到万不得已，没人愿意启动容灾切换，因为异地容灾通常涉及 DNS 改向、数据状态核对、甚至部分业务降级。类似于楼道里的应急灯，只要主电源还能抢救一下，就绝不会希望整栋楼进入“应急模式”。

冷备、温备、同城双活、异地双活、两地三中心

冷备

定义： 只有数据备份，没有运行中的计算资源。

• 实现方式： 定期将数据库备份（Dump文件）传送到异地存储（如云端的 OSS/S3 或物理磁带库）。
• 切换流程： 灾难发生后，临时购买/启动服务器 -> 安装环境 -> 下载备份 -> 恢复数据库 -> 切换 DNS。
• 适用场景： 非核心业务（如内部行政系统、历史档案库）。
• 优缺点： 成本极低，但 RTO 极长（通常以天为单位），RPO 较大（丢失上次备份后的所有数据）。

温备

定义： 备份机房有现成的服务器和环境，数据在后台异步同步，但平时不承载任何实际业务流量。

实现方式： 主机房（Active）全量在线；备机房（Passive）的应用处于待机或仅维持最小规模运行。数据库通过异步主从复制保持同步，但备库通常处于只读或挂起状态。

切换流程： 监控发现主机房挂了 -> 人工或脚本触发 -> 提升备机房数据库为主库 -> 开启/扩容应用实例 -> 修改 DNS 或负载均衡指向备机房。

适用场景： 对成本有一定控制，且能容忍分钟级中断的中型企业核心业务。

优缺点：

• 优点： 恢复速度比冷备快得多，环境一致性高。
• 缺点： 存在明显的资源浪费（备用机房常年“空转”烧钱），且切换瞬间可能存在少量数据丢失。

热备

定义： 备份机房不仅环境就绪、数据同步，且平时就分担一部分业务流量，处于“随时顶上”的状态。

实现方式： 主备机房（或多机房）同时在线。负载均衡器按照比例（如 70:30）将请求分发到两个机房。数据库通常采用近乎同步的复制技术，应用层保持活跃。

切换流程： 监控发现 A 机房挂了 -> 自动化流量调度（如健康检查自动剔除 IP） -> 剩余流量瞬间全部涌入 B 机房 -> B 机房根据压力自动弹性扩容。

适用场景： 对可用性要求极高、不能接受业务中断的大型互联网服务或金融交易系统。

优缺点：

• 优点： RTO 趋近于零，切换无感知；资源利用率高（因为备机房也在干活）。
• 缺点： 架构复杂（需要解决双机房访问的延迟问题），对负载均衡和流量分发技术要求极高。

同城双活

定义： 同一城市内的两个机房（距离 < 100km）同时承担业务。

• 实现方式： 通过高速光纤专线互联，通常采用强一致性同步。对于用户来说，流量被平均分配到两个机房。
• 关键技术： * 存储层： 采用分布式存储或数据库的同步复制，确保数据在两个机房完全一致。
• 适用场景： 对数据一致性要求极高的金融、支付业务。
• 优缺点： 数据零丢失，切换极快。缺点是无法防御地震、洪水等城市级灾难。

异地双活

定义： 在不同城市（如北京、上海）部署多个全功能机房，同时对外提供服务。

• 核心挑战： 光速是有限的，跨城延迟（30ms+）会导致传统同步复制失效。
• 实现逻辑
  • 流量切分： 根据用户 ID 把用户划分为不同的“单元”。比如南方用户访问广州机房，北方用户访问北京机房。
  • 数据同步： 采用异步复制。如果某地机房损毁，通过流量重定向将用户切到另一地。
  • 冲突处理： 必须处理微小概率的数据冲突（如用户在切换瞬间的并发写入）。
• 适用场景： 顶级互联网大厂（阿里、腾讯、字节）。
• 优缺点： 高可用性上限，资源利用率 100%。缺点是技术极其复杂，成本巨大。

两地三中心

定义： 容灾界的“终极堡垒”，结合了同城和异地的优势。

• 架构组成：
  1. 同城机房 A（生产）： 正常干活。
  2. 同城机房 B（灾备）： 与 A 强同步，应对机房级故障（如断网）。
  3. 异地机房 C（灾备）： 与 A 异步同步，应对城市级灾难（如地震）。
• 逻辑： 局部出事切 B，全城出事切 C。
• 适用场景： 银行、证券、电力等国家关键基础设施。

方案选型

以下是 可用性指标与容灾方案选型表 要求的可用性越高，方案越贵。

在实际选型过程中中，有一个通用的指导原则：

• 核心支付/金融业务： 必须追求 **99.999%**，采用同城双活或两地三中心。
• 核心互联网应用（电商/社交）： 通常追求 **99.99%**，采用热备或异地多活。
• 企业内部 OA/测试环境： 99% - 99.9% 即可，采用温备或定期冷备以节省成本。

冷知识： 很多公司宣称自己做到了“5个9”的可用性，如果它没有异地容灾方案，这个承诺在物理层面是非常脆弱的。一旦挖掘机挖断了机房的主光缆，再完美的高可用集群也会瞬间离线。

确定性保障

再好的系统也会被错误的配置或代码击垮。

变更确定性

要求做到可观测、可灰度、可回滚

• 可观测： 变更前后的指标对比必须清晰。
• 可灰度： 按照 1% -> 10% -> 100% 的比例切分，确保影响范围确定。
• 可回滚： 任何变更必须具备“一键回撤”的能力，且回滚时间必须是确定的。

流量确定性

如果无法预测流量，高可用就是空中楼阁。通过流控手段，将后端压力维持在安全水位线。

• 精细化限流： 基于令牌桶或漏桶算法，对不同租户、不同接口设定确定性的 QPS 上限。
• 自适应熔断： 当错误率达到阈值时，自动切断请求，避免级联故障。
• 全链路压测： 这是获取确定性的唯一实操手段。通过模拟真实流量，测算出系统在不同负载下的拐点。

模拟异常

监控与观测

看不见的系统是无法维护的。

基础设施层

这是最底层的监控，确保运行代码的“土壤”没有出问题。常见指标有：

计算资源： CPU 利用率、负载（Load）、上下文切换。

内存资源： 内存使用率、Swap 分区占用、OOM（内存溢出）事件。

存储资源： 磁盘 IOPS、读写延迟、磁盘空间剩余。

网络资源： 带宽占用、丢包率、重传率、TCP 连接数。

服务层

性能指标：延迟（响应时间）、流量（QPS）、错误。

运行时监控： JVM的GC 频率与时长、线程池状态、堆内存分布等。

中间件监控： 数据库连接池是否耗尽、消息队列的堆积量、缓存的命中率等。

链路追踪层

在微服务架构中，单体监控无法发现“谁慢”的问题。

全链路追踪 (Distributed Tracing)： 通过 Trace ID 串联起请求从网关到数据库的每一个环节。

拓扑分析： 自动生成服务依赖图，直观观察哪一个节点成为了性能瓶颈。

依赖强弱发现： 识别哪些是核心链路，哪些是非核心链路（以便在极端情况下实施降级）。

端侧层

有时候后端监控全绿，但用户依然无法访问，这就是端侧监控的意义。

RUM (Real User Monitoring)： 监控真实用户的页面加载时间、JS 错误、APP 闪退率。

拨测 (Synthetic Monitoring)： 从全球不同地区模拟用户请求，监控 DNS 解析、CDN 加速、跨境网络稳定性。

业务转化监控： 比如“下单成功率”下降，可能预示着即使系统没挂，逻辑也出了问题。

告警层

监控不只是看，更要在出事时能“喊人”并“自愈”。

告警降噪： 将成百上千个相似的报错聚合为一个告警，避免告警风暴。

分级通知： 根据故障等级（P0/P1…）通过电话、钉钉、邮件通知不同的负责人。

自动预案触发： 比如监控到 CPU 持续 90% 时，自动触发扩容；或检测到依赖服务超时时，自动开启熔断。

组织与流程

高可用不仅是技术问题，更是企业文化。

• SRE 文化： 责任共担，消除开发（Dev）与运维（Ops）之间的鸿沟。
• 故障复盘机制： 总结错误报告，坚持“对事不对人”，挖掘流程上的缺陷而非寻找替罪羊。
• 值班体系： 如何建立高效的 On-call 流程和分级响应机制。