【springcloud学习(dalston.sr1)】Ribbon负载均衡（七）

该系列项目整体介绍及源代码请参照前面写的一篇文章【springcloud学习(dalston.sr1)】项目整体介绍（含源代码）（一）

（一）Ribbon 负载均衡的理解

ribbon是一种客户端的负载均衡。类似于比如我们在火车站窗口买票，通常情况下，会有多个火车站售票窗口，如果人比较多的情况下，肯定需要排队，我们通常会选择排队人比较少的窗口，这样就不至于客户都集中扎堆在同一个窗口进行买票，如果都扎堆，也增加了那个窗口的访问压力。

类似的，如果有多台服务端可以访问的话，我们会选择这个请求通过访问次数相对少的那个服务端来完成服务。我们通过restTemplate来访问服务端，如果做了ribbon负载均衡，那么客户端会自行决定来访问哪台服务端。比较常见的算法有3种，默认的是轮询算法，比如第1个请求，访问第1台，下一个请求访问第2台，再下一个请求访问第3台，依此类推。另外还有随机算法、重试算法。

接下来会有1个消费者项目（microservicecloud-consumer-80），3个提供者项目（microservicecloud-provider-8001、microservicecloud-provider-8002、microservicecloud-provider-8003），1台eureka服务端项目（microservicecloud-eureka-7001）。这几个项目的创建，在前面几篇文章都有提到。

（二）接下来我们需要验证下通过microservicecloud-consumer-80来调用服务提供者（microservicecloud-provider-8001、microservicecloud-provider-8002、microservicecloud-provider-8003）的接口。因为采用了负载均衡（在restTemplate加上@LoadBalanced注解，如下图），且其默认算法是轮询算法。所以理想的情况是我们第1次请求，比如是通过8001来提供，第2次请求，是通过8002来提供，第3次请求是通过8003来提供。

为了便于区分数据是从哪里来自哪里，我认为设置了下返回数据，即8001返回的数据增加了数据库1,8002返回的数据增加了数据库2，8003返回的数据增加了数据库3。通过在mapper中增加相关内容来实现，如下：

另外还需要注意的是，这3个项目，除了mapper.xml文件不一样，端口不一样，eureka客户端实例ID不一样。其他的基本是一样的，尤其是配置文件中的spring.application.name应用名称配置都是microservicecloud-goods，表示这3个提供者提供的 是同一类服务。

（三）按照以下顺序，分别启动以下总共5个模块。

1台eureka服务端项目（microservicecloud-eureka-7001）

3个提供者项目（microservicecloud-provider-8001、microservicecloud-provider-8002、microservicecloud-provider-8003）

1个消费者项目（microservicecloud-consumer-80）

然后我们访问消费者项目（microservicecloud-consumer-80）的接口

http://localhost/consumer/goods/list/applicationName

在浏览器中输入上面地址，访问页面，并刷新后再访问，观察页面返回的数据。可以看到返回结果中稍微有些差别（分别是3个提供者项目（microservicecloud-provider-8001、microservicecloud-provider-8002、microservicecloud-provider-8003）返回的数据），这样就证明了ribbon负载均衡做好了。