SpringCloud入门教程 (三) 客户端负载均衡Ribbon

前言

目前Spring Cloud官网已经不推荐使用Ribbon作为负载均衡工具使用进入了维护模式，而是推荐使用Spring Cloud LoadBalancer去代替它，但是由于目前市面上还有很多公司在使用Ribbon，此处做简短介绍。

如果希望使用LoadBalancer，替换步骤：

1. 将spring.cloud.loadbalancer.ribbon.enabledproperty 的值设置为false
2. 在Eureka启动程序中排除功能区相关的依赖项（本身就做了集成）

一、客户端负载均衡和服务端负载均衡区别

负载均衡分类：

1. 服务端负载均衡
2. 客户端负载均衡

服务端负载均衡又可以分为硬件负载均衡和软件负载均衡。

1. 硬件负载均衡：通过在服务器节点之间按照专门用于负载均衡的设备，如F5等
2. 软件负载均衡：通过在服务器按照一些具有负载均衡功能模块的软件来实现请求分发的工作，如Nginx

服务端负载均衡特点：
      无论是软负载均衡还是硬负载均衡都会维护一个下挂可用的服务端清单，通过心跳检测来剔除故障的服务端节点，以确保清单中都是可以正常访问的的服务端节点，当客户端发送请求到负载均衡设备时，通过某种算法从维护的可用服务清单中取出一台服务端的地址然后进行转发。

客户端负载均衡特点：
      同服务端设计思想类似，客户端的负载均衡中也需要心跳去维护服务端清单的健康性，只是这个步骤需要和服务注册中心配合完成，在Spring CLoud的服务治理框架中会默认创建针对各个服务治理框架的Ribbon自动化整合配置
      Spring Cloud Ribbon就是客户端负载均衡实现的一种

区别：
      服务端负载均衡和客户端负载均衡最大的区别在于维护的服务清单所存在的位置。

• 在客户端负载均衡中，所有的客户端节点都维护着自己要访问的服务端清单，而这些服务端清单来自于服务注册中心例如Eureka服务端。
• 服务端负载均衡是由统一的负载均衡设备维护服务清单

二、Spring Cloud Ribbon

2.1 简介

1. 简述：Spring Cloud Ribbon是基于Netflix Ribbon实现的一套基于HTTP和TCP的客户端负载均衡器。
2. 部署方式：Spring CLoud RIbbon并不是向服务注册中心或配置中心一样需要单独部署，其存在于每一个Spring Cloud构建的微服务和基础设施中，在微服务之间的调用、API网关的请求转发等，都是通过Ribbon进行实现，以及Fegin也是基于Ribbon实现的工具。
3. 如何使用的 当Ribbon与Eureka联合使用时，ribbonServerList会DiscoveryEnabledNIWSServerList重写，扩展成从Eureka注册中心中获取服务实例列表。同时它也会用NIWSDiscoveryPing来取代IPing，它将职责委托给Eureka来确定服务端是否已经启动。
4. 具体细节：通过Spring Cloud的封装，我们可以将面向服务调用的Rest模板请求自动转换未客户端的负载均衡的服务调用。后续会介绍如何实现的。

2.2 如何在微服务架构中使用客户端负载均衡调用服务

基于Spring cloud Ribbon的封装，只需要两步便可以使用：

1. 服务提供者只需要启动多个服务实例注册到注册中心，并且配置了相同的服务名称
2. 服务消费者直接调用被@Balanced注解修饰过的RestTemplate来实现面向服务的接口调用

2.3 负载均衡选择策略有哪些

只是浅显的了解，原理不清楚

2.4 如何切换负载均衡选择策略

官方文档：负载均衡配置

官网指出：自定义配置类不能定义在@ComponentScan所扫描的包及当前子包下，否则我们自定义的配置类就会被所有的Ribbon客户端所共享，也就达不到特殊化定制目的了。

Tips：关于默认的包扫描问题可以参考Spring Boot的默认包扫描策略，源码级别已经做了规定。

图示：参考阳哥视频
通过个性化配置，在配置类上开启注解，指定服务采用特定的负载均衡策略。

2.5 Ribbon容错机制

三、Rest Template介绍

参考：详解 RestTemplate 操作

四、源码解析

问题分析：RestTemplate本身是Spring自身提供是如何跟Ribbon的客户端负载均衡配合使用的？

浅析：从@LoadBalanced注解出发，该注解用来给Rest Template做标记，以使用负载均衡的客户端LoadBalancerClient配置。

主要作用：从负载均衡器中选择一个对应的服务器实例，使用负载均衡器选出的实例执行请求内容。

原理：rest接口的第几次请求数%服务集群数量 = 实际调用服务实例的下标。每次服务重启之后，rest接口计数从1开始

五、总结

• 关于Ribbon的容错机制方面还未深刻理解，需要以Debug方式查看底层实现，Ribbon的容错和EurekaServer端的服务剔除等注意事项。
• 负载均衡策略底层算法实现如何