如何实施异构服务器的负载均衡与过载保护？.pdfVIP

如何实施异构服务器的负载均衡及过载保护？ ⼀、需求缘起 第⼀篇⽂章“⼀分钟了解负载均衡”和⼤家share 了互联⽹架构中反向代理层、站点层、 服 层、数据层的常⽤负载均衡⽅法。 第⼆篇⽂章“lvs为何不能完全代替DNS轮询”和⼤家share 了互联⽹接⼊层负载均衡需要 解决的问题及架构演进。 在这两篇⽂章中，都强调了“负载均衡是指，将请求/数据 【均匀】分摊到多个操作单 元上执⾏，负载均衡的关键在于 【均匀 ” 。 然⽽，后端的service有可能部署在硬件条件不同的服务器上： 1）如果对标最低配的服 器“均匀”分摊负载，⾼配的服 器的利⽤率不⾜； 2 ）如果对标最⾼配的服 器“均匀”分摊负载，低配的服 器可能会扛不住； 能否根据异构服 器的处理能⼒来动态、⾃适应进⾏负载均衡及过载保护，是本⽂要 讨论的问题。 ⼆、service层的负载均衡通常是怎么做的 “⼀分钟了解负载均衡” 中提到，service层的负载均衡，⼀般是通过service连接池来实 现的，调⽤⽅连接池会建⽴与下游服 多个连接，每次请求“随机”获取连接，来保证 service访问的均衡性。 “RPC-client实现细节” 中提到，负载均衡、故障转移、超时处理等细节也都是通过调⽤ ⽅连接池来实现的。 这个调⽤⽅连接池能否实现，根据service的处理能⼒，动态+ ⾃适应的进⾏负载调度 呢？ 三、通过“静态权重”标识service的处理能⼒ 调⽤⽅通过连接池组件访问下游service ，通常采⽤“随机”的⽅式返回连接，以保证下 游service访问的均衡性。 要打破这个随机性，最容易想到的⽅法，只要为每个下游service设置⼀个“权重” ，代 表service的处理能⼒，来调整访问到每个service的概率，例如： 假设service-ip 1，service-ip2 ，service-ip3的处理能⼒相同，可以设置weight 1= 1， weight2= 1，weight3= 1，这样三个service连接被获取到的概率分别就是1/3 ，1/3 ，1/3 ， 能够保证均衡访问。 假设service-ip 1的处理能⼒是service-ip2 ，service-ip3的处理能⼒的2倍，可以设置 weight 1=2 ，weight2= 1，weight3= 1，这样三个service连接被获取到的概率分别就是 2/4 ，1/4 ，1/4 ，能够保证处理能⼒强的service分别到等⽐的流量，不⾄于资源浪费。 使⽤nginx做反向代理与负载均衡，就有类似的机制。 这个⽅案的优点是：简单，能够快速的实现异构服 器的负载均衡。 缺点也很明显：这个权重是固定的，⽆法⾃适应动态调整，⽽很多时候，服 器的处 理能⼒是很难⽤⼀个固定的数值量化。 四、通过“动态权重”标识service的处理能⼒ 提问：通过什么来标识⼀个service的处理能⼒呢？ 回答：其实⼀个service能不能处理得过来，能不能响应得过来，应该由调⽤⽅说了 算。调⽤服 ，快速处理了，处理能⼒跟得上；调⽤服 ，处理超时了，处理能⼒很 有可能跟不上了。 动态权重设计 1）⽤⼀个动态权重来标识每个service的处理能⼒，默认初始处理能⼒相同，即分配给 每个service的概率相等； 2 ）每当service成功处理⼀个请求，认为service处理能⼒⾜够，权重动态+ 1； 3 ）每当service超时处理⼀个请求，认为service处理能⼒可能要跟不上了，权重动 态-1 （权重下降会更快）； 4 ）为了⽅便权重的处理，可以把权重的范围限定为[ , 1 ] ，把权重的初始值设为6 分。 举例说明： 假设service-ip 1，service-ip2 ，service-ip3的动态权重初始值 weight 1=weight2=weight3=6 ，刚开始时，请求分配给这3台service的概率分别是 6 / 18 ，6 / 18 ，6 / 18 ，即负载是均衡的。 随着时间的推移，处理能⼒强的service成功处理的请求越来越多，处理能⼒弱的 service偶尔有超时，随着动态权重的增减，权重可能变化成了weight 1= 1 ， weight2=6 ，weight3=4 ，那么此时，请求分配给这3台service的概率分别是1 /2 ， 6 /2 ，4 /2 ，即处理能⼒强的service会被分配到更多的流量。