老司机眼中的高可用：「英方周末」第十九期

在之前的文章中，我讲述了我这么多年来一直在关注的技术领域，其中我多次提到了工业级的软件。我本以为会有很多人会问我怎么定义工业级，以及如何构建高可用性软件系统，既然没有人提问，那我就来聊聊这个话题。

在各类技术讨论中，很多人只聚焦各家的技术方案，但高可用系统不单单是技术方案，还涉及大量其他维度，很多人对此理解并不全面。

理解高可用系统

高可用英文为 High Availability，目标是让软硬件计算环境实现全天候可用。设计层面需要做好三点：

• 软硬件冗余，消除单点故障，部署一套或多套备用standby系统；
• 故障检测与故障转移failover，检测故障并由备用节点接管业务；
• 保障负载均衡、域名解析等难以做冗余的交叉节点（CrossOver）可靠运行。

看似简单，但细节充满难点。对于有状态节点，最大挑战是数据复制与一致性保障；无状态节点的冗余实现相对简单。

• 异步镜像：故障切换failover时容易出现主备数据差异；
• 同步镜像：冗余节点越多，整体系统性能下降越明显。

高可用需要结合业务做取舍：银行余额这类状态型数据，冗余必须保证强一致性；订单记录属于追加型数据，故障切换后备机直接追加写入即可。很多企业宣传的异地双活，实际上无法真正实现状态型数据的双活。

高可用设计核心原理：

• 想要数据不丢失，必须做好数据持久化；
• 想要服务高可用，必须拥有应用或数据副本；
• 只要存在数据复制，就一定会面临数据一致性难题；
• 不存在100%高可用，只能追求不同等级SLA，也就是大家常说的“几个9”。

高可用系统的技术解决方案

下图来自Google App Engine联合创始人Ryan Barrett在Google I/O 2009演讲《Transaction Across DataCenter》。

这张图是主流高可用解决方案的基础：M/S主从、MM多主实现难度低但存在不少缺陷；2PC两阶段提交性能较差；Paxos协议能力强，但实现复杂度极高。

• 最终一致性：宕机场景下，存在数据同步不完全，主备出现数据差异的风险；
• 强一致性：要么使用性能偏弱XA两阶段提交，要么使用实现复杂的Paxos协议。

注：以上为软件层面方案，昂贵硬件方案本文不做探讨。

不少缓存、消息队列、开源数据库自带复制、持久化能力，具备基础高可用，但开源软件普遍很难达到高级别SLA，选型需要留意。

高可用技术方案的示例（MySQL）

图片来源：MySQL High Availability Solutions。方案的“9”越多，整体实现复杂度越高：

• MySQL Replication：异步/半同步复制，可用性不到2个9；
• MySQL Fabric：分片+主从读写分离，可用性可达99%；
• DRBD：底层磁盘镜像RAID1模式，可用性不到3个9；
• Solaris Clustering/Oracle VM：全栈监控硬件、操作系统、网络、数据库，结合心跳、SAN存储、虚拟机迁移，接近4个9；
• MySQL Cluster：NDB完全同步复制集群，接近5个9。

高可用性的SLA的定义

SLA即服务等级协议 Service Level Agreement，用来量化高可用等级，也就是行业常说的“几个9”。业界主流以故障发生到恢复的不可用时长作为衡量标准。

举例：99.999%（5个9），全年只允许5.26分钟服务不可用。反观很多团队，故障处理动辄1‑3小时，完全达不到对外宣称的SLA指标。

影响高可用性的因素

系统可用性受软件、硬件、第三方运营商网络、外部意外事件等多重因素影响。SLA不只是技术参数，更是服务商和客户之间的契约。宕机分为无计划宕机与有计划宕机两类。

无计划的宕机原因

• 系统故障：主机、操作系统、中间件、数据库、网络、电源、外设硬件；
• 数据与介质故障：人员误操作、硬盘损坏、数据损坏；
• 外部事件：自然灾害、供电故障、人为破坏。

有计划的宕机原因

• 日常操作：备份、容量规划、账号安全管理、批处理任务；
• 周期性维护：数据库、应用、中间件、操作系统、网络运维；
• 版本升级：硬件、操作系统、数据库、中间件、应用、网络升级改造。

真正决定高可用系统的本质原因

想要实现5个9，代表故障发生后必须在5分钟内完成业务恢复，仅仅依靠技术架构远远不够。高可用建立在整套工程体系之上：

• 软件设计、编码、测试、上线、配置管理能力；
• 工程师团队技术能力；
• 自动化运维体系与运维管理水平；
• 数据中心运营管理；
• 对第三方依赖服务的管控。

更深层是对软件工程的尊重：技术态度、工程文化、管理层对工程的重视程度。评估一套系统高可用能力，不能只看技术方案，更要看企业整体工程实力。

其它

高可用就如同汽车工业，高可靠性不是依靠零散技工修补，而是整套严谨工业化体系。很多人误以为开发网站、APP只是写代码，只有遭遇故障的时候，才会意识到工程体系的价值。

Code Review、自动化测试、自动化运维、持续集成，这些看似枯燥的流程，恰恰是工业级系统的基础。不少技术人员缺少这方面意识，这和过往项目经历息息相关。