高可用

高可用是系统非功能性需求的一大重点，它描述了系统全年可用时间，用多个9来表述，如99.99%说明系统全年仅52.56分钟系统是不可用的。目前导致系统不可用的有以下几种情况：

1. 硬件故障；

2. 软件BUG；

3. 系统发布；

4. 并发压力；

5. 网络攻击；

6. 外部灾害。

应对故障方案

硬件故障

通常系统中的每个服务节点不能是单点，需要做冗余，也就是最少两个服务节点。

系统从上往下，依次有网络应用层，常用nginx做负载均衡或者反向代理，作为整个系统的入口，是必须要做冗余；往后是网关层，该层作为业务服务的入口，也必须做多节点，一冗余备份，二是分摊流量提升系统处理能力；其次是业务服务器，这一层中会有不同业务的服务节点，每个服务都需要多节点，同样的一冗余备份，二是分摊流量提升系统处理能力；接着系统会有中间件层，常用的有各种缓存、分布式协调器和消息中间件，不同的中间件有不同的高可用方案，例如redsi缓存采用哨兵+主备模式、zookeeper使用多节点+leader选举模式、rabbitmq使用镜像模式；最后的是数据存储层，对于常用的mysql来说，常使用VIP + 一主多从模式。

软件BUG

这个应该是最常见的故障原因了，而在其中NullException最是常见。

系统发布

系统发布一有代码，二有配置文件。

应对代码发布，需要有清晰的版本管理流程，对于配置文件的修改，应该有独立的配置管理服务。

并发压力

随着使用用户量增加，导致服务的资源耗尽，比如CPU使用率居高不下、内存使用过高、load average数值大，此时，当前的业务服务中的一部分节点宕机，从而整个业务服务宕机，更加严重的会导致整个系统不可用。

应对这种情况，网络应用层和业务层可以通过水平扩展来提升性能，中间件层需要看具体的中间件使用方式，比如redis缓存如果是哨兵模式，就无法做到水平扩展，需要重新做成Cluster 集群，对于存储层的水平扩展需要考虑数据分片，也就是数据该写到哪一个分片，又该从哪一个分片中查询到。同时对于核心业务需要做限流 + 熔断 + 降级操作，来保障在超出系统能够承受流量下或者边缘服务故障下，系统不跨，在限流下，一个滑动窗口时间内的请求数超过阈值的部分将触发降级操作，也就是一个fallback方法；同样的在熔断器关闭的情况下，一个滑动窗口时间内请求异常的比例超过阈值，那就会触发熔断器打开，随后的请求将走降级业务——fallback方法，在一段时间后，熔断器将会放一个请求过去，从请求的结果来判断熔断是否继续。

网络攻击

最常见的就是XSS和SQL注入还有令人不安的DDOS攻击。

外部灾害

这个故障一般就是机房级别的了，通常都会采用异地多活，同城双备来应对。

监控

上面提到的都是事前准备，然而该故障是一定会发生的，所以在发生故障后能够快速解决也是提高可用性的重要因素，那么采用监控——尤其是微服务下的调用链监控就尤为重要。