Ribbon负载均衡（自己总结的）

Ribbon负载均衡

负载均衡解决的问题

首先Ribbon负载均衡配合Eureka注册中心一块使用。

在SpringCloud中为什么会有负载均衡？以及它解决的主要是什么问题？
负载均衡主要解决的问题是如何把请求高效地分发到多个服务实例上，以及如何保证服务的高可用性和弹性。

注意这里的服务实例不是指Eureka服务器注册中心，而是指Eureka注册中心的微服务，比如下图：

怎么理解这里的spring.application.name和instance-id？那个才表示一个具体单位的微服务？
Instance-id表示一个微服务，而spring.application.name表示一个微服务大类，里面可以包含多个具体的微服务实例。比如cloud-payment-service就表示提供者payment的一个微服务大类，这个大类里面有多个微服务实例，每个微服务实例除了端口号不同，其它的东西都是相同的。
因为我们idea里面的每个微服务模块在注册到Eureka注册中心的时候，spring.application.name微服务的名字，也就是serviceid是可以一样的，但是每个微服务的instace-id实例id是不可以一样的。

然后我们开头说的服务实例，指的就是Eureka注册中心中每个instance-id实例id所代表的微服务。

Ribbon负载均衡作用：

• 避免单点故障造成的程序崩溃。比如如果我们的Cloud-payment-service微服务大类中只写了一个微服务实例payment8001，那么如果这个微服务崩溃之后，我们的整个程序就会崩溃了，但是如果我们写了多个微服务实例（这些微服务实例除了端口号其他都是相同的），比如我们又写了一个微服务实例payment8002，那么既便微服务实例payment8001崩溃了，我们的程序也不会崩溃，因为通过负载均衡我们可以去访问payment8002微服务实例。
• 可以处理更多的客户端请求。如果客户端请求非常多，但我们只有一个payment8001微服务实例，那么我们处理的请求个数就有限。但如果我们想要提高请求的处理能力该怎么办呢？我们可以新加一个相同的微服务实例比如说payment8002。

不要把Ribbon负载均衡和Eureka-Server服务器集群搞混了

刚开始的时候我还以为负载均衡指的是每次请求来了之后，我把这些请求分发给不同的Eureka-Server注册中心；其实不是的，我们的多个请求来了还是给一个Eureka-Server服务器，但是我们会把这些请求分发给一个spring.application.name微服务大类里面的多个instance-id微服务实例，以减轻多个请求如果都给同一个instance-id微服务实例造成的负担。

那么Eureka-Server服务器集群有什么功能呢？其实很简单，你可以理解成是一个Eureka注册中心的备份，当一个Eureka注册中心崩了之后，我们可以去读取Eureka-Server服务器集群中另外一个Eureka注册中心的微服务，这样就可以保证我们的程序正常的运行下去。

Eureka-Server服务器集群中所有的Eureka注册中心中注册的微服务都是相同的。

Ribbon负载均衡代码怎么写

Ribbon负载均衡一般都是配合RestTemplate一块使用。
首先写RestTemplate配置类，如下图：

然后写负载均衡配置类（注意不能被@ComponentScan注解扫描到，因此不能和主启动类放到同一个包中），如下图：

负载均衡的规则可以是随机，可以是按照顺序，可以是加权，直接返回相关的对象即可。

然后在启动类上写@RibbonClient负载均衡注解，如下图：

上面的name表示我们会负载均衡调用cloud-payment-service微服务大类下面的每个instance-id微服务实例。

ribbon负载均衡依赖是怎么引入的？

可以发现我们只是引入了eureka-client依赖，但是并没有明确引入ribbon负载均衡相关的依赖，那么为什么可以使用@RibbonClient负载均衡的注解呢？因为在eureka中已经包含了ribbon负载均衡依赖了，如下图：