架构设计之高可用

发布时间:2018-01-10 18:25:21编辑:丝画阁阅读(435)

接入层

端到接入层,最好通过域名,而不是ip直连。当提供服务的ip,不可用时,可以通过切换dns更换入口。

接入层冗余部署,nginx通过统一的ip(虚拟ip)对外服务,多台Nginx采用keepalive检测,当对外提供服务的nginx挂了,通过把ip切换给备用机器,实现故障转移。

接入层到ui层

接入层到ui层也是通过部署冗余的ui层服务实现,接入层nginx上配置失败检测和转移,当nginx发现某个ui层机器挂了,自动将失败请求转移别的ui机器,并且隔离失败的机器。

UI层到服务层

部署冗余的服务层,ui层每次请求随机请求其中一个服务,并且在失败的情况转移到其他服务,请求种可异步统计每个服务的响应时间,服务可用率,可以设置阈值,当请求平均耗时比如超过100毫秒时,认为这个机器已经超载,减少权重,减少到该机器的流量,当连续失败次数达到一定值认为服务不可用,隔离该服务。

服务层到存储层

redis可以部署集群,利用哨兵机制实现高可用,也可以部署codis集群实现高可用。

mysql可以部署mha或者类似的高可用服务,当主卦了,会自动提升有最新数据的从作为主,当有从服务不可用时自动隔离。

多机房冗余

单机房无论多么冗余,多么牛逼,当施工队靠近,自然灾害发生,还是面临不可用,这时我们需要部署多机房高可用,服务多机房同活很容易,但是对于需要持久化的存储层则需要采用光纤直连,设置保证分布式多机房的情况,至少保证其中两个机房事务已经落盘,才返回给用户成功。当然会牺牲部分速度。

总结

高可用是架构设计上必须考虑的问题,主要是指减少系统因为某些不可抗拒原因带来的不可用时间。方法论:冗余部署+自动故障转移+自动服务降级+自动服务隔离等

架构设计之高可用

关键字