第 11 周作业:高可用

用户头像
行下一首歌
关注
发布于: 2020 年 09 月 01 日
第11周作业:高可用

高可用

高可用是系统非功能性需求的一大重点,它描述了系统全年可用时间,用多个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攻击。

外部灾害

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

监控

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

发布于: 2020 年 09 月 01 日 阅读数: 22
用户头像

行下一首歌

关注

还未添加个人签名 2017.10.30 加入

半壁山房待明月,一盏清茗酬知音。

评论

发布
暂无评论
第11周作业:高可用