1、背景

面试官问这个，主要想考察 是否思考过系统架构？ 程序员不止业务与编码 进一步考察你是否对工作中的系统自上而下、从左到右进行思考与总结等等。要想学问大，就要多读、多抄、多写。

1.1、可用性

可用性是在某个考察时间，系统能够正常运行的概率或时间占有率期望值。考察时间为指定瞬间，则称瞬时可用性；考察时间为指定时段，则称时段可用性；考察时间为连续使用期间的任一时刻，则称固有可用性。它是衡量设备在投入使用后实际使用的效能，是设备或系统的可靠性、可维护性和维护支持性的综合特性。

1.2、衡量可用性

业界一般用几个9去衡量系统的可用性，当出现生产事故时，计算系统的可用性指标去定级，进而进行惩罚等。可用性的高低是使用不可用时间占总时间的比例来衡量。不可用时间是从故障发生到故障恢复的时间。

比如，可用性5个9的系统（99.999%），它一年宕机时间不能超过5.256分钟( = 365 * 24 * 60 * (1 - 0.99999))。

做到高可用系统，需要尽可能的降低故障发生的次数 和减少故障持续的时间。

1.3、不可用原因

出现系统不可用的原因，可以归纳为以下两点：

人为的，比如发布了有BUG的代码、不规范的发布流程导致的宕机或者网站访问量过载造成的雪崩等；非人为的，由于外部系统和环境的变化造成的，比如硬盘老化造成的故障、机房断电、电缆中断等。

我们需要在复杂的外部环境下保证系统的高可用。以下总结了常用的高可用解决手段。

2、解答2.1、拆分

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

2.1.1、水平拆分

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

2.1.2、垂直拆分

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

2.1.3、读写分离

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

2.2、降级

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

2.2.1、限流

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

2.2.2、异步调用

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

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

2.2.3、同步调用合理设置超时时间

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

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

2.2.4、失败重试

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

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

2.2.5、兜底方案

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

2.3、冗余

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

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

失败通知和失败切换

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

2.4、灰度发布

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

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

回滚机制

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

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

2.5、切换

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

监控不是目的，监控没法保证高可用，切换才是目的，从故障的系统切换到正常的系统才能保证可用性。比如监控某台机器硬盘出问题了，那么会告警出来，然后使用一台新的机器替换。

切换可以是自动的，也可以是人工的。人工切换会有延迟恢复的问题，但能做到准确。自动切换，会比较快速，但必须要确保切换源是正常的，否则可能会引起更加严重的事故。切换后，要有实时的效果反馈。

3、最后

本文只具有理论指导意义，实际实现高可用的系统，需要结合实际业务场景和所使用的开发框架来完成。