高可用系统常用解决手段浅述

上篇下篇

高可用系统常用解决手段浅述

2020年02月08日 21:59:21 ⁄ IT架构 ⁄ 共 2770字 ⁄ 暂无评论 ⁄ 被围观 2,501次

所谓可用性，是指某系统能够提供正常服务的特性。

可用性的高低是使用不可用时间占总时间的比例来衡量。不可用时间是从故障发生到故障恢复的时间。比如，可用性4个9的系统（99.99%），它一年宕机时间不能超过53分钟(=365*24*60*(1-0.9999))。做到高可用系统，需要尽可能的减少故障发生次数和缩短故障持续时间。

系统可用性%	宕机时间/年	宕机时间/月	宕机时间/周	宕机时间/天
90% (1个9)	36.5 天	72 小时	16.8 小时	2.4 小时
99% (2个9)	3.65 天	7.20 小时	1.68 小时	14.4 分
99.9% (3个9)	8.76 小时	43.8 分	10.1 分钟	1.44 分
99.99% (4个9)	52.56 分	4.38 分	1.01 分钟	8.66 秒
99.999% (5个9)	5.26 分	25.9 秒	6.05 秒	0.87 秒

出现系统不可用的原因，一种是人为的，比如发布了有bug的代码、不规范的发布流程导致的宕机，或者网站访问量过载造成的雪崩等；另一种则是非人为的，由于外部系统和环境的变化造成的，比如硬盘故障、机房断电、电缆中断等。我们需要在复杂的外部环境下保证系统的高可用。以下总结了常用的高可用解决手段。

1.拆分

这类解决手段不是以减少不可用时间为目的，而是以缩小故障影响面为目的。因为一个大的系统拆分成了几个小的独立模块，一个模块出了问题不会影响到其他的模块，从而缩小故障的影响面。手段包括：

1.1 水平拆分

系统水平拆分成三层：接入层，服务层和数据存储层。将有状态和无状态的划分开来，接入层和服务层设计成无状态的，存储层是有状态的。无状态层的服务可以平行扩展，请求落到哪台服务器都没有关系。平行扩展也有利于系统容量的扩充，快速扩容应对突然爆发流量的冲击。

1.2 垂直拆分

根据功能垂直划分，拆成相对独立的模块。有的仅是服务层做了拆分，存储层共用。更为彻底的是，拆分与该系统的业务领域模型关联，一个领域模型划分成一个模块。在数据库层面，还可以分库分表拆分，这样一个库的损坏，不会影响到其他库。分库分表需要增加路由逻辑，及保证路由规则的一致性。

1.3 读写分离

也属于垂直拆分的一种。写请求的依赖主库，读请求的依赖备库。这样做，当出现故障的时候，可以只有读请求的流量，写服务暂时关闭，从而减少了故障的影响面。但需要关注数据一致性的问题。

2.降级

这类手段不是为了防止故障的发生，而是当故障发生后，怎么减小故障所造成的损失。比如，系统正常时提供的服务能力是100%，出现系统故障后，我们有措施能让系统服务能力不直接降到了0，而是还能提供部分（比如50%）的服务能力。

2.1 限流

限流，流量控制。当请求量超过系统的最大容量后，访问延迟就会增加，超过峰值的流量会拖累整个系统，出现宕机。因此，需要提前流量控制，对于超过峰值的流量，可以直接拒绝掉或者选择随机拒绝。限流结合业务自定义配置，优先保证核心服务的正常响应，非核心服务可直接关闭。

2.2 异步调用

系统进行拆分之后，会分成多个模块。模块之间的依赖有强弱之分。如果是强依赖的，那么如果依赖方出问题了，也会受到牵连出问题。这时可以梳理整个流程的调用关系，做成弱依赖调用。弱依赖调用通过消息中间件的方式来实现。

异步调用不关心返回结果，不会传递依赖方的错误，进而避免造成更大规模的不可用。

2.3 同步调用合理设置超时时间

对于不能异步化的，采用同步调用，需要注意设置合理的超时时间。过长的超时，会延迟结果等待时间，导致整体的链路调用时间延长，降低整体的QPS。

经验值：超时时间设置成平均响应延迟的2倍。

2.4 失败重试

要区分调用失败的类型。有些失败是短暂偶然的（比如网络抖动），进行重试即可。而有些失败是确定，那么重试反而会造成调用请求量的放大，加重对调用系统的负担。

经验值：重试的次数一般设为3次，再多次的重试没有好处。

2.5 兜底方案

在系统真的出现了不可用的时候，需要有兜底方案。比如一些提示安抚用户，或者设置跳转链接以转移用户的请求。

3.冗余

冗余，目的是避免单点故障。比如对于接入层和服务层，可以平行扩展机器部署，这样一台机器宕机，可以将请求转移到其他机器。数据层的冗余比较复杂，增加一份备份数据，需要考虑一致性的问题。按照分布式系统的CAP理论三者不可用同时满足的原理，为了满足可用性和分区容错性，就必须牺牲一致性，因此考虑使用弱一致性、最终一致性的解决方案来解决(此类文章很多，略)。

冗余备份有全量和增量之分，有热备和冷备之分。冗余可以是两台机器的主备冗余，可以是多机的集群式冗余。从部署来看，可以是跨机架、跨机房到跨城的备份。多机复制部署，上层调用采用负载均衡策略，还需要注意负载均衡设备的单点问题。

失败通知和失败切换

当集群机器某台机器出现了故障，或者某个进程挂了，能够快速的发现，并且告警通知出来。路由选择器能快速的切除掉这台机器，当恢复后又能自动的加入回来。

4.灰度发布

有个观点，单点和发布是可用性最大的敌人。线网出现了故障，查故障的原因，一个常用的办法就是追查下最近是否有发过版本，比较下发布前后的代码。

使用灰度发布策略，发布并且验证没问题后再全量发布。灰度发布的策略，包括搭建预发布环境，有专用的预发布机器；或者路由策略先摘除灰度发布的机器，验证正常后再加入该机器；或者采用UIN取模灰度策略，验证没问题后再取消灰度策略。尽量采用自动化发布，减少人为发布的流程。尽量选择在访问量低峰时段升级，减小影响用户群。

回滚机制

出现问题后，能有有效的回滚机制。涉及到数据修改的，发布后会引起脏数据的写入，需要有可靠的回滚流程，保证脏数据的清除。

除了发布流程外，还应该在其他开发流程上做规范，比如代码控制，集成编译、自动化测试、静态代码扫描等。

5.切换

切换之前需要做好监控。监控应该是贯穿于上述所有手段的。比如业务某个模块访问量要监控，依赖的调用方出问题要监控，某个机房故障了要监控，发布了服务要监控等。监控既包括系统层面的（比如CPU、内存、网络、IO、进程），还包括业务层面的（请求量、错误率、耗时）。监控的间隔需要支持到分钟级甚至到秒级的。

监控不是目的，监控没法保证高可用，切换才是目的，从故障的系统切换到正常的系统才能保证可用性。比如监控到某台机器的硬盘出问题了，那么告警要出来，然后使用一台新的机器替换。切换可以是自动的，也可以是人工的。人工切换会有延迟恢复的问题，但能做到准确。自动切换，会比较快速，但必须要确保切换源是正常的，否则可能会引起更加严重的事故。切换后，要有实时的效果反馈。