高可用架构设计

1. 引言

软件系统有三个追求：高性能、高并发、高可用，俗称三高。三者既有区别也有联系，门门道道很多，本篇讨论高可用

高可用技术的重要性在于保证系统的连续可用性，提高系统的稳定性和可靠性。它可以应对高并发和大规模负载，支持持续交付和快速迭代。实际应用场景涵盖了各个行业和领域，关乎到企业的业务运营和发展。

2. 高可用性概述

2.1. 定义

高可用性是指系统能够在面对故障、意外事件或负载增加时保持稳定运行，持续提供可用的服务的能力，是现代系统设计和架构中的一个重要目标。

2.2. 重要性

高可用性是现代系统设计中的一个重要目标，它能够保障业务连续性、提高用户体验、确保数据安全性，并增强企业的品牌声誉和用户的信任。在竞争激烈的市场中，高可用性对于现代系统的重要性不可忽视。

举个例子：用户面对2个系统，一个全年不停机、无故障；另一个隔三差五出线上事故、宕机，用户肯定选择前者，

3. 衡量指标

3.1.1. 系统可用性（Availability）

可用性是衡量系统能够正常运行并提供服务的程度。常用的可用性指标是系统的正常运行时间与总运行时间的比例（通常以百分比表示），例如，99.99%的可用性表示系统每年只有不到1小时的停机时间

其中，

MTTF 是 Mean Time To Failure，平均故障前的时间，即系统平均能够正常运行多长时间才发生一次故障。系统的可靠性越高，MTTF 越长。（注意：从字面上来说，看上去有 Failure 的字样，但其实是正常运行的时间。）

MTTR 是 Mean Time To Recovery，平均修复时间，即从故障出现到故障修复的这段时间，这段时间越短越好。

业界衡量系统可用性的方式主要有2种：

时间纬度的系统可用性。
请求纬度的系统可用性。

3.1.1.1. 时间纬度的系统可用性（常用）

Availability = 程序正常运行时间 / (程序正常运行时间 + 系统故障时间)

时间维度的系统可用性，就是我们经常提起的X个9

X个9表示以年/月/日等为单位，在指定的时间范围内，系统可以正常使用时间与总时间之比。例如，我们以1年为时间单位，可以得出：

3个9：(1-99.9%)36524=8.76小时，表示该系统在连续运行1年时间里最多可能的业务中断时间是8.76小时。
4个9：(1-99.99%)36524=0.876小时=52.6分钟，表示该系统在连续运行1年时间里最多可能的业务中断时间是52.6分钟。
5个9：(1-99.999%)36524*60=5.26分钟，表示该系统在连续运行1年时间里最多可能的业务中断时间是5.26分钟。

根据如上的定义，我们可以总结出一张表格：

可用性等级	故障时间（以年为单位）	故障时间（以月为单位）	故障时间（以日为单位）
90%	(1-90%)*365天 = 36.5天	(1-90%)30天 24小时 = 72小时	(1-90%)*24小时= 2.4小时
99%	(1-99%)*365天 = 3.65天	(1-99%)30天 24小时 = 7.2小时	(1-99%)24小时 60分钟= 14.4分钟
99.9%	(1-99.9%)365天 24小时= 8.76小时	(1-99.9%)30天 24小时 * 60分钟= 43.8分钟	(1-99.9%)24小时 60分钟= 1.44分钟
99.99%	以此类推	...	...
99.999%	...	...	...

3.1.1.2. 请求纬度的系统可用性：

Availability = 成功请求数量 / 请求总数量

3.1.2. 容错性（Fault Tolerance）

容错性是指系统能够在出现组件故障或异常情况时继续正常运行的能力。评估容错性的指标可以是系统的恢复时间（Recovery Time Objective，RTO），即系统从故障到完全恢复正常运行所需的时间

3.1.3. 可恢复性（Recoverability）

可恢复性是指系统能够在故障后迅速恢复到正常运行状态的能力。评估可恢复性的指标可以是系统的恢复点目标（Recovery Point Objective，RPO），即系统从故障点到数据和服务完全恢复的时间和数据损失程度。

4. 考虑的因素

4.1. 成本

系统可用性越高，对你的系统要求也越高，那么你付出的成本和代价也会越高。对于可用性越高的系统，那么对于你服务器的存储、网络、软件等要求也就越高。而对于一些服务并不需要达到那么高的可用性，因此就可以为这些服务设置较低的可用性目标。

4.2. 业务容忍度

系统可用性也需要考虑业务的容忍度。

对于金融行业服务来说，任何一个请求的失败都有可能带来资金的损失，因此对于这类的服务，对于错误的容忍度是比较低的，也就要求系统可用性较高。

对于常用的社交软件而言，例如我们使用的评论区功能/弹幕功能，对于这些应用来说，即使请求一次失败也是可以接受的，下次再请求成功就可以了。因此对于这些业务来说，业务容忍度较高，系统可用性不要求一定要很高。

高可用架构设计需要在成本和业务容忍度中取得一个"平衡"

5. 核心设计思想

做好研发规范，系统都是研发人员设计和编码写出来的，因此首先要对研发层面有一个规范和标准
做好容量规划和评估，主要是让开发人员对系统要扛住的量级有一个基本认知，方便进行合理的架构设计和演进。
做好服务层面的高可用，主要是负载均衡、弹性扩缩容、异步解耦、故障容错、过载保护等。
做好存储层面的高可用，主要是冗余备份（热备、冷备）、故障转移（确认，转移，恢复）等。
做好运维层面的高可用，主要是发布测试、监控告警、容灾、故障演练等。
做好产品层面的高可用，主要是兜底策略。
做好应急预案，主要是在出现问题后怎么快速恢复，不至于让我们的异常事态扩大。

6. 常见技术手段介绍

常见的实技术手段包括负载均衡、冗余备份、故障转移、监控和告警和容错设计

6.1. 负载均衡

6.1.1. 简介

将系统的流量均匀地分散到多个服务器或节点上，确保每个服务器的负载均衡，避免单一节点过载，提高系统的性能和可靠性

6.1.2. 负载均衡算法

算法名称	描述	适用场景
轮询 (Round Robin)	请求依次分发给每个服务器，按照顺序循环轮询	服务器性能相近、请求量均匀分布
加权轮询 (Weighted Round Robin)	根据权重比例分发请求给服务器	服务器性能不均衡、某些服务器处理能力更强
最少连接 (Least Connection)	将请求发送到当前连接数最少的服务器上，确保请求在服务器上的分布均衡	每个连接的处理时间不同
IP哈希 (IP Hash)	根据客户端的IP地址将请求分发给特定的服务器，保持会话的连续性	需要保持会话状态或会话一致性的应用程序
最短响应时间 (Least Response Time)	将请求发送到响应时间最短的服务器上，根据服务器的平均响应时间选择最快的服务器处理请求	服务器处理能力不同、响应时间差异较大
随机 (Random)	随机选择一个服务器处理请求	请求分布均匀，不需要考虑服务器负载差异
哈希 (Hash)	根据请求的特定属性（如URL、Cookie等）进行哈希计算，将相同哈希值的请求分发给同一台服务器，保持请求的一致性	需要特定请求的一致性，如会话保持
加权最小连接 (Weighted Least Connection)	结合权重和连接数，选择连接数最少且权重最高的服务器处理请求	服务器性能不均衡且每个连接的处理时间不同
最短预测延迟 (Least Predicted Delay)	根据服务器的预测延迟选择最快的服务器处理请求	服务器响应时间具有预测性，可以根据历史数据进行预测

这些负载均衡算法根据不同的需求和条件，提供了各种选择。在设计高可用架构时，需要根据系统的特点和负载分布选择合适的负载均衡算法，以实现负载的均衡和优化系统的性能。

6.1.3. 常见负载均衡技术

基于硬件的负载均衡：这种技术使用专门的硬件设备（如负载均衡器）来分发流量。负载均衡器通常位于网络前端，通过监控服务器的负载情况和性能指标，在多个服务器之间均匀地分配请求。硬件负载均衡器具有高性能、高可靠性和高并发处理能力，适用于大型系统和高流量环境。
基于软件的负载均衡：这种技术使用软件来实现负载均衡功能。常见的软件负载均衡器包括Nginx、HAProxy和Apache等。软件负载均衡器可以在应用层或传输层进行负载均衡，根据不同的算法（如轮询、最少连接数或响应时间）来分配请求。它们通常具有灵活的配置选项和易于扩展的特点。
基于DNS的负载均衡：这种技术通过DNS来实现负载均衡。当客户端发起请求时，DNS服务器返回一个与请求相对应的服务器IP地址。通过将多个IP地址与同一域名关联，DNS负载均衡可以将请求分发到不同的服务器上。DNS负载均衡具有简单和易于实现的优点，但缺点是无法动态调整负载分配。
内容分发网络（CDN）：CDN是一种分布式的负载均衡解决方案，通过将静态和动态内容缓存在全球各地的边缘节点上来分发流量。当用户请求内容时，CDN会根据用户的位置选择最近的边缘节点来提供内容。CDN可以大大减少延迟和带宽使用，提高系统的性能和可用性。

6.2. 数据备份

6.2.1. 简介

采用备份服务器、热备份或冷备份等方法，将系统的数据和功能复制到备份系统，当主系统发生故障时，可以快速切换到备份系统，保证系统的连续性和可用性

6.2.2. 具体方案

在高可用性架构中，常见的数据备份方式包括热备份和冷备份

热备份（Hot Backup）：
热备份是在系统正常运行期间进行的数据备份。它基于实时或定期的备份策略，将数据实时复制到备用存储设备中，确保数据的冗余性和可靠性。在系统故障或灾难发生时，可以快速切换到备份设备，并迅速恢复数据，减少系统的停机时间和数据丢失风险。
冷备份（Cold Backup）：
冷备份是在系统停机或处于非活动状态时进行的数据备份。它涉及到备份整个系统或关键数据，通常在系统维护窗口期间进行。冷备份能够提供完整和一致的备份数据，但恢复时间较长，需要系统重启和数据导入。

相对于热备份而言，冷备份的备份过程对正常的数据源操作有较小的影响。当主要数据源发生故障时，需要将备份数据还原到备用设备上，然后再将服务切换到备用设备上，因此冷备份的恢复过程可能需要一些时间。

6.3. 故障转移

6.3.1. 简介

在高可用架构设计中，故障转移技术起着至关重要的作用。它可以帮助系统实现快速的故障检测和转移，从而减少系统停机时间，提高系统的可用性和可靠性

6.3.2. 常见的故障转移技术

心跳监测：心跳监测是一种基本的故障检测和转移机制。它通过周期性发送心跳信号来监测主节点的可用性。备用节点会监听这些心跳信号，一旦检测到主节点失效，就会接管主节点的工作负载。这种机制通常用于主备模式的故障转移。
故障切换：故障切换是一种手动或自动触发的故障转移机制。当主节点发生故障时，管理员可以手动切换到备用节点。自动故障切换则是通过监控和自动化工具实现的，当监测到主节点故障时，自动将工作负载迁移到备用节点上。
负载均衡器：负载均衡器是一种常用的故障转移技术。它通过将请求分发到多个服务器上，以均衡系统的负载。当某个服务器发生故障时，负载均衡器会自动将请求重定向到其他可用服务器上，确保服务的连续性和可用性。
数据复制和同步：数据复制和同步是一种常见的故障转移技术，特别适用于数据库和存储系统。通过将数据实时或定期复制到备用设备上，并保持同步，一旦主节点发生故障，备用节点可以接管数据服务，保证数据的可用性和一致性。
容器编排技术：容器编排技术，如Kubernetes，提供了故障转移和容灾功能。它可以自动监测和管理容器集群中的节点和服务，一旦发现节点故障或服务失效，会自动转移工作负载到其他健康节点，确保应用的连续运行。

6.4. 监控和告警

6.4.1. 简介

监控和告警是保障高可用性的守护者，它们可以无时无刻地监测系统的脉搏，发现潜在的问题和异常情况，并在关键时刻发出警报，以便及时采取行动，确保系统始终保持稳定和可用。

6.4.2. 具体方案

定义关键指标和阈值：确定系统的关键指标和性能指标，如服务器负载、响应时间等，并为每个指标设置适当的阈值。阈值应该根据系统需求和性能标准进行定义，超过阈值时触发告警。
选择合适的监控工具和系统：根据系统的特点和需求，选择适合的监控工具和系统。常见的监控工具包括Prometheus、Nagios、Zabbix等。确保监控工具能够实时收集和展示关键指标的数据，并提供告警功能。
配置监控项和告警规则：在监控工具中配置监控项和告警规则。设置监控项以收集系统指标和性能数据，同时设置告警规则，根据阈值和异常条件触发相应的告警通知。
设置告警通知方式：选择适当的告警通知方式，确保相关人员能够及时收到告警信息。常见的告警通知方式包括电子邮件、短信、即时通讯工具等。确保告警通知能够及时传达给相关人员，以便他们能够快速响应和处理问题。
告警响应和故障处理：设立明确的告警响应流程，确保接收到告警后能够及时响应和处理。指定责任人和相应的行动计划，确保故障能够在最短的时间内得到处理和解决。
持续优化和演进：定期回顾和评估监控和告警系统的效果，并根据实际情况进行调整和优化。根据系统的演化和需求变化，不断改进监控策略和配置，以确保系统的高可用性和稳定性。

6.5. 容错设计

6.5.1. 简介

任何服务，一定会存在失败的情况，不可能有 100% 的可用，服务在线上运行过程中，总会遇到各种各样意想不到的问题会让你的服务出现状况。为此，我们的设计建议遵循"design for failure"的设计原则，设计出一套可容错的系统，需要做到尽早返回、自动修复

6.5.2. 核心思想

遵循 fail fast 原则
Fail fast 原则是说，当我们的主流程的任何一步出现问题的时候，应该快速合理地结束整个流程，尽快返回错误，而不是等到出现负面影响才处理。
具备自我保护的能力
当我们依赖的其他服务出现问题的时候，要尽快的进行降级、兜底等各种异常保护措施，要避免出现连锁反应导致整个服务完全不可用。比如当我们依赖的数据存储出现问题，我们不能一直重试从而导致数据完全不可用