负载平衡是指,将请求/数据分摊到多个操作单元上执行,关键在于平衡。

然而,后端的服务器有可能硬件条件差别:

  • 若是对标低配的服务器“平均”分摊负载,高配的服务器利用率会不足
  • 若是对标高配的服务器“平均”分摊负载,低配的服务器会扛不住

能否凭据异构服务器的处置能力来动态、自适应举行负载平衡,以及过载珍爱呢?

负载平衡通常是怎么做的?


service层的负载平衡,一样平常是通过service毗邻池来实现的,挪用方毗邻池会确立与下游服务多个毗邻,每次请求“随机”获取毗邻,来保证接见的平衡性。

负载平衡、故障转移、超时处置等细节也都是通过挪用方毗邻池来实现的。

挪用方毗邻池能否,凭据service的处置能力,动态+自适应的举行负载调剂呢?

方案一:可以通过“静态权重”标识service的处置能力。


最容易想到的方式,可以为每个下游service设置一个“权重”,代表service的处置能力,来调整接见到每个service的概率,如上图所示:

(1) 假设ip1,ip2,ip3的处置能力相同,可以设置weight1=1,weight2=1,weight3=1,这样三个service毗邻被获取到的概率划分就是1/3,1/3,1/3,能够保证平衡接见;

(2) 假设ip1的处置能力是ip2,ip3的处置能力的2倍,可以设置weight1=2,weight2=1,weight3=1,这样三个service毗邻被获取到的概率划分就是2/4,1/4,1/4,能够保证处置能力强的service分到等比的流量,不至于资源虚耗;

Nginx就具备类似的能力。

方案优点:简朴粗暴,能够快速的实现异构服务器的负载平衡。

方案瑕玷:权重是牢固的,无法自适应动态调整,而许多时刻,服务器的处置能力是很难用一个牢固的数值量化。

方案二:通过“动态权重”标识service的处置能力。

若何来标识一个service的处置能力呢?
服务能不能处置得过来,该由挪用方说了算:

  • 挪用服务,快速处置,处置能力跟得上
  • 挪用服务,处置超时,处置能力很有可能跟不上了

若何来设计动态权重?
可以这么玩:
(1) 用一个动态权重,来标识每个service的处置能力,默认初始处置能力相同,即分配给每个service的概率相等;
(2) 每当service乐成处置一个请求,以为service处置能力足够,权重动态+1;
(3) 每当service超时处置一个请求,以为service处置能力可能要跟不上了,权重动态-10;
画外音:
权重下降,会比权重上升更快。
为了利便权重的处置,可以把权重的局限限定为[0, 100],把权重的初始值设为60分。

举例说明:
假设service-ip1,service-ip2,service-ip3的动态权重初始值:

  • weight1=60
  • weight2=60
  • weight3=60
    刚开始时,请求分配给这3台service的概率划分是60/180,60/180,60/180,即负载是平衡的。

随着时间的推移:

,

以太坊高度数据

www.326681.com采用以太坊区块链高度哈希值作为统计数据,联博以太坊统计数据开源、公平、无任何作弊可能性。联博统计免费提供API接口,支持多语言接入。

,
  • 处置能力强的service乐成处置的请求越来越多
  • 处置能力弱的service偶然有超时

随着动态权重的增减,权重会发生变化:

  • weight1=100
  • weight2=60
  • weight3=40
    那么此时,请求分配给这3台service的概率划分是100/200,60/200,40/200,即处置能力强的service会被分配到更多的流量。

那什么是过载珍爱?


如上图所示,若是没有过载珍爱:

  • 随着外部负载的不停升高,系统现实处置负载会增添
  • 外部负载升高到一个临界值,系统会被压垮,现实处置能力会降为0
    画外音:这就是所谓的“掉底”。

过载珍爱,是指当外部负载跨越系统处置能力时,系统会举行自我珍爱,依然能对外提供有损的稳固服务。

如上图所示,若是举行了过载珍爱:

  • 随着外部负载的不停升高,系统现实处置负载会增添
  • 外部负载纵然跨越一个临界值,系统不会被压垮,而能保持一定的处置能力
    画外音:外部负载无限大,系统也不会“掉底”。

那若何举行过载珍爱?

方案一:可以通过“静态权重”标识service的处置能力。

这是最浅易的方式,服务端设定一个负载阈值,跨越这个阈值的请求压过来,所有甩掉。
画外音:这个方式不是稀奇优雅。

方案二:借助“动态权重”来实行过载珍爱。

犹如异构服务器负载平衡,仍然通过:

  • 乐成处置加分(+1)
  • 处置超时扣分(-10)
    这种动态权重,来标识后端的处置能力。
    画外音:仍然是在毗邻池层面实现的。

当一个服务端频频处置超时,权重不停降低时,毗邻池只要实行一些计谋,就能够对“疑似过载”的服务器举行降压,而不用服务器“甩掉请求”这么粗暴的实行过载珍爱。

应该实行什么样的计谋,来对“疑似过载”的服务器举行降压珍爱呢?

可以这么玩:
(1) 若是某一个服务器,延续3个请求都超时,即延续-10分三次,就可以以为,服务器处置不外来了,得给这个服务器喘一小口吻,于是设定计谋:接下来的若干时间内,例如1秒,负载不再分配给这个服务器;
画外音:休息1秒后,再分给它。

(2) 若是某一个service的动态权重,降为了0(休息了3次还超时),就可以以为,服务器完全处置不外来了,得给这个服务器喘一大口吻,于是设定计谋:接下来的若干时间内,例如1分钟,请求不再分配给这个服务器;
画外音:凭据履历,此时服务器一样平常在fullGC,差不多1分钟能回过神来。

这样的话,不只能借助“动态权重”来实行动态自适应的异构服务器负载平衡,还能在客户端层面更优雅的实行过载珍爱,在某个下游服务器快要响应不外来的时刻,给其喘息的机遇。

过载珍爱要注意什么问题?

要防止过载珍爱引起服务器的雪崩,若是“整体负载”已经跨越了“服务器集群”的处置能力,怎么转移请求也是处置不外来的。这时,照样得通过甩掉请求来实行自我珍爱。

总结

  • 负载平衡、故障转移、超时处置通常是毗邻池层面来实行的
  • 异构服务器负载平衡,最简朴的方式是静态权重法,瑕玷是无法自适应动态调整
  • 动态权重法,可以动态的凭据服务器的处置能力来分配负载,需要有毗邻池层面的细小改动
  • 过载珍爱,是在负载过高时,服务器为了珍爱自己,保证一定处置能力的一种自救方式
  • 动态权重法,还可以用做服务器的过载珍爱

架构师之路-分享可落地的技术文章
相关推荐:
《GFS架构启示》
《Google MapReduce解决什么问题?》
《Google MapReduce巧妙优化思绪?》
《程序员养女儿的四大要点!》

听说,配图值得转。