架构设计【高可用】

一、简介 高可用(HA)是系统架构设计中必须考虑的,是指系统所能提供无故障服务的一种能力。即避免因为服务器宕机导致的服务不可用的情况。 二、衡量

一、简介

       高可用(HA)是系统架构设计中必须考虑的,是指系统所能提供无故障服务的一种能力。即避免因为服务器宕机导致的服务不可用的情况。

二、衡量

       可用性 = 平均故障间隔/(平均故障间隔 + 故障恢复平均时间)

三、如何设计高可用

       想要高可用就要避免使用单点,你想想看你的单台服务器再强应用优化的再极致,只要它宕机,就啥都凉凉了,所以需要多台机器也就是需要集群,方法论中叫冗余。只是有了集群是不能完全满足复杂业务的高可用的,我们要让系统在当前节点宕机的情况下,自己进行切换到好的节点去,这即所谓的故障转移。所以我们现在设计高可用系统的目标明确了。关键字:冗余、故障转移

       大部分互联网公司的系统架构:

        

            2.1、上图会出现的问题和解决办法

                     1、  从客户端到反向代理Nginx这块,这个1台nginx是会可能发生故障的,所以这里可以再冗余一台Nginx,可以利用linux的 keeplived进行探测可用性,当一台Nginx挂了之后,则会自动转移到另一台Nginx机器上来,从而保证高可用。

        

                 2、从反向代理到后端服务service这块,反向代理这块,目前最受欢迎的是nginx,性能方面表现也很好,nginx能够自动探测后端服务的可用性,只需在nginx,config配置多台后端服务就行了。

               

                 3、后端服务到缓存这块,缓存这块推荐使用redis主从同步方案来达到高可用,redis主从同步加上sentine哨兵机制来自动探活redis实例。

 

                     

              4、从后端服务到写数据库这块,这里可以采用双主机制,一台给线上使用,另一台冗余,当线上那台挂了才会阶梯过来使用写功能,同样是通过linux的keepalived进行自动探活。

               

           5、从后端服务到读数据库这块,这里同样是将读库部署多台,例如部署2台,通过代码段增加连接池组件进行路由读库和探活。

                 

 

 四、延伸思路

        在编码的时候除了故障转移方案,同样需要考虑很多东西来保证系统的可用性,主要想体现在,超时机制、降级、限流等。

        4.1、超时             

                 系统调用三方接口,而这个三方接口一般是合作公司的或者是公司其他部门提供的,我们并不清楚对方接口的性能情况,有些接口在并发稍大一点的情况下会出现返回很慢,一直占用当前资源,使得我们大量的请求阻塞等。所以这块我们需要对此进行设置合理的超时时间,来快速结束这些慢请求,来保证我们系统的可用性。

                有个业务发生过类似的事件,对方接口在我们一定并发的时候经常很慢很慢才会出现结果,最后造成我们OOM(Out Of Memory 内存耗尽),最终发现是这个业务程序员没有合理设置超时时间造成的。

               超时时间如何设置,需要根据自己的业务以及接口情况加上多次分析线上时间,来合理设置,可以不停的对其设置直到业务愉快的进行。

       4.2、降级

                降级也是互联网中老生常谈的话题,那么我们使用降级方案如何来保证系统的可用性呢,分析自己的业务,在面对流量剧增的时候,例如,秒杀,大促等这些剧增的大流量,可以将不影响本次业务的流程也砍掉,不去调用了,直接走核心业务。其实各大电商都是采取这种方案来保证系统的可用性的。

      4.3、限流

              本来系统只能抗住10万并发,然后现在我运营搞了什么牛逼的大促,搞的来了10倍的流量,那么系统就把瞬间不能处理的流量给截断,直接返回给用户,用户可以待会儿再试。所以限流就是为了保证系统的高可用而限制住大流量的情况发生。

 

 

 

 

       

您可能有感兴趣的文章
大型项目前端架构设计

六种常见的系统架构

为什么软件项目需要架构设计?

架构设计学习(一)

整个技术架构结构设计