在Spring Cloud中如果已经实现了服务的注册和服务发现。当启动某个服务的时候,可以通过HTTP的形式将信息(服务IP,端口等)注册到注册中心,并且可以通过SpringCloud提供的工具获取注册中心的服务列表。但是服务之间的调用还存在很多的问题,比如如何更加方便的调用微服务,多个微服务的提供者【集群】如何选择,如何负载均衡等。 为了解决这些问题,Ribbon技术应运而生。
Ribbon概述
Ribbon是 Netflix 发布的一个负载均衡器,有助于控制 HTTP 和 TCP客户端行为。在 SpringCloud 中, Eureka一般配合Ribbon进行使用,Ribbon提供了客户端负载均衡的功能,Ribbon利用从Eureka中读取到的服务信息,在调用服务节点提供的服务时,会合理的进行负载。在SpringCloud中可以将注册中心和Ribbon配合使用,Ribbon自动的从注册中心中获取服务提供者的列表信息,并基于内置的负载均衡算法,请求服务 。
Ribbon的主要作用
服务调用
基于Ribbon实现服务调用, 是通过拉取到的所有服务列表组成(服务名-请求路径的)映射关系。借助 RestTemplate 实现最终的服务调用
负载均衡
当有多个服务提供者时,Ribbon可以根据负载均衡的算法自动的选择需要调用的服务地址
Ribbon的使用
不论是基于Eureka的注册中心还是基于Consul的注册中心,Spring Cloud Ribbon统一进行了封装,所以对于服务调用,两者的方式是一样的
坐标依赖
在 Spring Cloud 提供的服务发现的jar中以及包含了Ribbon的依赖。所以这里不需要导入任何额外的坐标
修改消费者
在创建RestTemplate的方法上添加 @LoadBalanced 注解,并使用RestTemplate完成服务调用
/**
* 基于Ribbon的服务调用与负载均衡
*/
@LoadBalanced
@Bean
public RestTemplate getRestTemplate() {
return new RestTemplate();
}
Ribbon的负载均衡策略
Ribbon内置了多种负载均衡策略
- 顶级接口为
com.netflix.loadbalancer.IRule
- 默认实现类是 ZoneAvoidanceRule,根据 zone 选择服务列表,然后轮询
IRule 实现类如下
AbstractLoadBalancerRule (com.netflix.loadbalancer)
ClientConfigEnabledRoundRobinRule (com.netflix.loadbalancer)
// 最佳策略。遍历所有的服务实例,过滤掉故障实例,并返回请求数小的实例返回
BestAvailableRule (com.netflix.loadbalancer)
PredicateBasedRule (com.netflix.loadbalancer)
// 可用过滤策略。过滤掉故障和请 求数超过阈值的服务实例,再从剩下的实力中轮询调用
AvailabilityFilteringRule (com.netflix.loadbalancer)
ZoneAvoidanceRule (com.netflix.loadbalancer)
RandomRule (com.netflix.loadbalancer) // 随机策略
RetryRule (com.netflix.loadbalancer) // 重试策略
RoundRobinRule (com.netflix.loadbalancer) // 以轮询的方式进行负载均
ResponseTimeWeightedRule (com.netflix.loadbalancer)
// 权重策略。会计算每个服务的权重,越高的被调用的可能性越大
WeightedResponseTimeRule (com.netflix.loadbalancer)
负载均衡自定义方式
- 代码方式:配置灵活,但修改时需要重新打包发布
- 配置方式:直观,方便,无需重新打包发布,但是无法做全局配置
##需要调用的微服务名称
shop-service-item:
ribbon:
NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RandomRule
饥饿加载【默认懒加载】
- 开启饥饿加载
- 指定饥饿加载的微服务名称
ribbon:
eager-load:
enabled:true # 开启饥饿加载
clients: # user-service # 指定对 user-service 这个服务饥饿加载
- user-service
- order-service
策略选择:
- 如果每个机器配置一样,则建议不修改策略 (推荐)
- 如果部分机器配置强,则可以改为 WeightedResponseTimeRule