关于负载均衡

负载均衡一般分为 服务端负载均衡 和 客户端负载均衡。

服务端负载均衡

比如Nginx，请求到达服务器之后由Nginx负载均衡器根据一定的算法将请求路由到目标服务器处理。
image.png

客户端负载均衡

比如Ribbon，服务消费者客户端会有一个服务器地址列表，调用方在请求前通过一定的负载均衡算法选择一个服务器进行访问，负载均衡算法的执行时在请求客户端进行的。
Ribbon是Netflix发布的负载均衡器。Eureka一般配合Ribbon进行使用，Ribbon利用从Eureka中读取服务信息，在调用服务提供者提供的服务时，会根据一定的算法进行负载。
image.png

Ribbon高级应用

引入依赖

微服务引入的依赖 eureka-client 中，已包含了Ribbon相关的jar包，所以无需引入额外的jar坐标。

添加注解

  1. @Bean
  2. @LoadBalanced // Ribbon负载均衡
  3. public RestTemplate getRestTemplate() {
  4.      return new RestTemplate();
  5. }

Ribbon负载均衡

Ribbon内置了多种负载均衡策略，内部负责负载均衡的顶级接口为 com.netflix.loadbalancer.IRule 。
类树如下：
image.png

负载均衡策略分类

负载均衡策略 描述
RoundRobinRule：轮询策略 默认超过10次获取到的server都不可用，会返回一个空的server
RandomRule: 随机策略 如果随机到server为null或不可用的话，会while不停的循环选取
RetryRule：重试策略 一定时限内循环重试。默认继承RoundRobinRule，也支持自定义注入。RetryRule会在每次选取之后，对选举的Server进行判断，是否为null，是否alive，并且在500ms内不停的选取判断。
RoundRobinRule失效策略是超过10次。
RandomRule是没有失效时间的概念，只要serverList没都挂。
BestAvailableRule：最小连接数策略 遍历serverList，选取出可用的并且连接数最小的一个server。
该算法里面有一个LoadBalancerStats的成员变量，会存储所有server的运行状况和连接数。
如果选取到的server为null，就会调用RoundRobinRule重新选取。
AvailabilityFilteringRule：可用过滤策略 扩展了轮询策略，会先通过默认的轮询选取一个server，再去判断该server是否超时可用，当前连接数是否朝鲜，都成功再返回。
ZoneAvoidanceRule：区域权衡策略（默认策略） 扩展了轮询策略，继承了2个过滤器：ZoneAvoidancePredicate和AvailabilityPredicate，除了过滤超时和链接数过多的server，还会过滤不符合要求的zone区域里面的所有节点。AWS-ZONE在一个区域/机房内的服务实例中轮询。

修改负载均衡策略

  1. #针对的被调⽤⽅微服务名称,不加就是全局⽣效
  2. service-resume:
  3.    ribbon:
  4.            NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RandomRule #负载策略调整

Ribbon工作原理

请求负载流程图

image.png
重点：Ribbon给restTemplate添加了一个拦截器。

Ribbon负载流程处理

当我们访问 http://service-resume/resume/openstate 的时候，ribbon会根据服务名 service-resume 获取到该服务实例列表并按照一定的负载均衡策略从实例列表中获取一个实例Server，并且最终通过RestTemplate进行请求访问。

Ribbon细节结构图

（1）获取服务实例列表
（2）从实例列表中选择一个server
image.png
图中核心是 负载均衡管理器LoadBalancer（总协调者，相当于大脑，协调四肢）。

  • IRule：是在选择实例的时候的负载均衡策略对象；
  • IPing：是用来向服务发起心跳检测的，通过心跳检测来判断该服务是否可用；
  • ServerListFilter：根据一些规则过滤传入的服务实例列表；
  • ServerListUpdater：定义了一系列的对服务列表的更新操作。