Spring Cloud Ribbon客户端负载均衡（四）

序言

Ribbon 是一个客户端负载均衡器（Nginx 为服务端负载均衡），它赋予了应用一些支配 HTTP 与 TCP 行为的能力，可以得知，这里的客户端负载均衡也是进程内负载均衡的一种。它在 Spring Cloud 生态内是一个不可缺少的组件，少了它，服务便不能横向扩展，这显然是有违云原生12要素的。此外 Feign 与 Zuul 中已经默认集成了 Ribbon，在我们的服务之间凡是涉及调用的，都可以集成它并应用，从而使我们的调用链具备良好的伸缩性。
附带拓展福利，云原生12要素：https://12factor.net/zh_cn/

Ribbon是Netflix公司开源的一个负载均衡的项目，它属于上述的第二种，是一个客户端负载均衡器，运行在客户端上。它是一个经过了云端测试的IPC库，可以很好地控制HTTP和TCP客户端的一些行为。 Feign已经默认使用了Ribbon。

• 负载均衡
• 容错
• 多协议（HTTP，TCP，UDP）支持异步和反应模型
• 缓存和批处理

ribbon：https://github.com/Netflix/ribbon

Feign集成Ribbon示例 

@RestController
@RequestMapping(value = "/Promotion",method = RequestMethod.GET)
public class PromotionController implements PromotionFacade {
    @Value("${server.port}")
    String port;
    @Value("${spring.profiles.active}")
    String environment;
    @Override
    @RequestMapping(value = "/delete")
    public String releasePromotion(@RequestParam int orderID){
        try {
            if ("local".equals(environment)) {
                Thread.sleep(200L);
            }
            return port;
        }
        catch (Exception ex)
        {
            return  port+"---"+ex.getMessage();
        }
    }
} 

注册服务如下 

上述trade-promotion服务，有2个站点部署，feign调用他们如下。

@FeignClient(name = "trade-promotion")
public interface PromotionClient {
    @RequestMapping(value = "/Promotion/delete", method = RequestMethod.GET)
    String releasePromotion(@RequestParam int orderID);
}

默认情况下，调用结果是：8085，8082，8085，8082，8085，8082，8085，8082... 这样轮询调用执行。

原因就是默认集成啦Ribbon,可以通过spring-cloud-starter-openfeign这个依赖看下他的父依赖中，就有spring-cloud-starter-netflix-ribbon这个包的依赖。

Ribbon的负载均衡策略

• RandomRule （随机策略）： 随机选择 Server
• RoundRobinRule （轮训策略）： 按顺序循环选择 Server
• RetryRule （重试策略）： 在一个配置时问段内当选择 Server 不成功，则一直尝试选择一个可用的 Server
• BestAvailableRule （最低并发策略）： 逐个考察 Server，如果 Server 断路器打开，则忽略，再选择其中并发连接最低的 Server
• AvailabilityFilteringRule （可用过滤策略）： 过滤掉一直连接失败并被标记为 circuit tripped 的 Server，过滤掉那些高并发连接的 Server（active connections 超过配置的网值）
• ResponseTimeWeightedRule （响应时间加权策略）： 根据 Server 的响应时间分配权重。响应时间越长，权重越低，被选择到的概率就越低；响应时间越短，权重越高，被选择到的概率就越高。这个策略很贴切，综合了各种因素，如：网络、磁盘、IO等，这些因素直接影响着响应时间
• ZoneAvoidanceRule （区域权衡策略）： 综合判断 Server 所在区域的性能和 Server 的可用性轮询选择 Server，并且判定一个 AWS Zone 的运行性能是否可用，剔除不可用的 Zone 中的所有 Server

默认为轮询策略

全局策略设置

@Configuration
public class RibbonConfig {
    /**
     * 随机规则
     */
    @Bean
    public IRule ribbonRule() {
        return new RetryRule();
    }
}

配置文件配置

#trade-promotion：这个是eureka中的被调用的服务名称

trade-promotion.ribbon.NFLoadBalancerRuleClassName=com.netflix.loadbalancer.RandomRule

note：第一个new的对象与上面的轮询规则匹配，第二个配置文件最后的词语也是与轮询规则匹配

Ribbon 超时与重试

针对单个服务的重试与超时配置：

#负载均衡策略
trade-promotion.ribbon.NFLoadBalancerRuleClassName=com.netflix.loadbalancer.RandomRule
#http建立socket超时时间,毫秒
trade-promotion.ribbon.ConnectTimeout=2000
#http读取响应socket超时时间
trade-promotion.ribbon.ReadTimeout=5000
#同一台实例最大重试次数,不包括首次调用
trade-promotion.ribbon.MaxAutoRetries=0
#重试负载均衡其他的实例最大重试次数,不包括首次server
trade-promotion.ribbon.MaxAutoRetriesNextServer=2
# 是否所有操作都重试，POST请求注意多次提交错误。
# 默认false，设定为false的话，只有get请求会重试
trade-promotion.ribbon.OkToRetryOnAllOperations=true

全局服务的重试与超时配置

#http建立socket超时时间,毫秒
ribbon.ConnectTimeout=2000
#http读取响应socket超时时间
ribbon.ReadTimeout=5000
#同一台实例最大重试次数,不包括首次调用
ribbon.MaxAutoRetries=0
#重试负载均衡其他的实例最大重试次数,不包括首次server
ribbon.MaxAutoRetriesNextServer=2
# 是否所有操作都重试，POST请求注意多次提交错误。
# 默认false，设定为false的话，只有get请求会重试
ribbon.OkToRetryOnAllOperations=true

Ribbon脱离Eureka进行负载

ribbon.eureka.enabled=false
trade-promotion.ribbon.listOfServers:http://localhost:8085,http://localhost:8082

Ribbon饥饿加载

ribbon.eager-load.enabled=true
ribbon.eager-load.clients=trade-promotion,trade-order

总结

多看文档，多翻资料