10.0、springcloud--负载均衡 以及 11.0、Ribboncrm开发定制负载均衡的实现
Ribbon是什么?
·Spring Cloud Ribbon 是基于 Netflix Ribbon crm开发定制实现的一套crm开发定制客户端负载均衡的工具
·简单的说,Ribboncrm开发定制是发布的开源项目,crm开发定制主要功能是提供客户端crm开发定制的软件负载均衡算法,将NetFlixcrm开发定制的中间层服务连接在一起。
Ribboncrm开发定制的客户端组件提供一系crm开发定制列完整的配置项,如:连接超时、重试等等。简单地说,就是在配置文件中列出 LoadBalancer(简称LB:负载均衡)后面所有的机器,Ribbon会自动的帮助你基于某种规则(如简单轮询,随机连接等等)去连接这些机器。
我们也很容易使用Ribbon实现自定义的负载均衡算法!
轮询是啥?
轮询算法是最简单的一种负载均衡算法。
它的原理是把来自用户的请求轮流分配给内部的服务器:从服务器1开始,直到服务器N,然后重新开始循环。 算法的优点是其简洁性,它无需记录当前所有连接的状态,所以它是一种无状态调度
举个例子就是:假如我们有10台服务器,那么第一个用户进来就让他访问第一台服务器,第二个用户进来就让他访问第二个......直到第10个用户进来让他访问第10个服务器,当第11个用户进来的时候就让他访问第1个服务器【也就是轮回第一个服务器】
Ribbon能干嘛?
·LB,即负载均衡(Load Balance),在微服务或分布式集群中经常用的一种应用
·负载均衡简单的说就是将用户额请求平摊的分配到多个服务器上,从而达到系统的HA(高可用)
·常见的负载均衡软件有Nginx、Lvs等等【Nginx是服务端的负载均衡】
·dubbo、springcloud中均给我们提供了负载均衡,springcloud的负载均衡算法可以自定义
·负载均衡简单分类:
集中式LB
即在服务的 消费方 和 提供方 之间 使用独立的LB设施,如Nginx,由该设施负责把访问请求通过某种策略转发至服务的提供方
进程式LB:
将LB逻辑 集成到 消费方,消费方从服务注册中心获知有哪些地址可用,然后自己在从这些地址中选出一个合适的服务器
Ribbon就属于进程式LB,他只是一个类库,集成与消费方进程,消费方通过他来获取到服务提供方的地址
第一步:在消费者模块的 pom.xml 文件中导入相关依赖,如下:
- <!--导入eureka依赖-->
- <dependency>
- <groupId>org.springframework.cloud</groupId>
- <artifactId>spring-cloud-starter-eureka-server</artifactId>
- <version>1.4.6.RELEASE</version>
- </dependency>
第二步:在 application.yaml 中配置 eureka ,使得访问服务的时候,能够从 7001、7002、7003 三个注册中心里随机选取一个去访问服务,这样就实现了负载均衡。
配置如下:
- server:
- port: 80
-
- #Eureka配置
- eureka:
- client:
- register-with-eureka: false
- service-url:
- defaultZone: http://localhost:7001/eureka/,http://localhost:7002/eureka/,http://localhost:7003/eureka/
第三步:在启动类加上 @EnableEurekaClient注释,开启Eureka即可
第四步:在之注入好的java配置类中的RestTemplate上加上 @LoadBalanced 注释开启 ribbon 负载均衡即可,【这里注意 @loadbalance 注解要写在 @bean 下面】,代码如下:
- package com.hkl.springcloud.config;
- import org.springframework.cloud.client.loadbalancer.LoadBalanced;
- import org.springframework.cloud.netflix.ribbon.RibbonClient;
- import org.springframework.context.annotation.Bean;
- import org.springframework.context.annotation.Configuration;
- import org.springframework.web.client.RestTemplate;
-
- @Configuration
- public class ConfigBean {
- //配置负载均衡实现RestTemplate
- @Bean
- @LoadBalanced //Ribbon 默认为轮询算法
- public RestTemplate getRestTemplate() {
- return new RestTemplate();
- }
- }
第五步:在之前写好的DeptConsumerController类中,修改一下之前写死的访问端口号8001,将它改成服务的名字,这样消费者就不是直接从服务者端口去访问了,而是会随机通过7001、7002、7003的其中一个注册中心的服务名字去间接的访问服务,
代码如下:
- package com.hkl.springcloud.controller;
-
- import com.hkl.springcloud.pojo.Dept;
- import org.springframework.beans.factory.annotation.Autowired;
- import org.springframework.web.bind.annotation.PathVariable;
- import org.springframework.web.bind.annotation.RequestMapping;
- import org.springframework.web.bind.annotation.RestController;
- import org.springframework.web.client.RestTemplate;
-
- import java.util.List;
-
- @RestController
- public class DeptComsumerController {
-
- //理解:消费者不应该有service层~
- //RestTemplate ... 供我们直接调用就可以了 手动注册到Spring中
- //(url,参数,返回类型)
- @Autowired
- private RestTemplate restTemplate;
-
- // private static final String REST_URL_PREFIX = "http://localhost:8001";
- private static final String REST_URL_PREFIX = "SPRINGCLOUD-PROVIDER-DEPT";
-
- @RequestMapping("/consumer/dept/add")
- public boolean add(Dept dept) {
- System.out.println("dept.dname="+dept.getDname());
- return restTemplate.postForObject(REST_URL_PREFIX+"/dept/add",dept,boolean.class);
- }
-
- @RequestMapping("/consumer/dept/get/{id}")
- public Dept queryById(@PathVariable("id") Long id) {
- return restTemplate.getForObject(REST_URL_PREFIX+"/dept/get/{id}",Dept.class,id);
- }
-
- @RequestMapping("/consumer/dept/list")
- public List<Dept> queryAll() {
- return restTemplate.getForObject(REST_URL_PREFIX+"/dept/list",List.class);
- }
- }
启动provider、7001、7002、7003、consumer这五个服务器,
然后访问localhost:80//consumer/dept/list,成功获取到数据库的数据算是成功【数据库啥的在前面搭建环境的时候写过了】
11.0、用Ribbon实现负载均衡
在springcloud项目下再创建两个maven服务者模块,分别为
springcloud-provider-dept-8002 和 springcloud-provider-dept-8003
内容和 springcloud-provider-dept-8001 一样,记得修改相关8001的配置改成8002和8003,
再创建两个数据库分别为 db02 和 db03 数据库数据和db01一样
可以看到每次访问同样的服务,数据库都在变化,说明这里用到了轮询算法实现负载均衡,不会一直访问同一个服务器和数据库。
总结一下:
首先消费者去访问一个服务,这时候先随机访问一个注册中心,然后根据和这个服务的名字找到这个服务【可以发现这个服务名字下面有三个服务器】,这时候就会以随机或轮询的方式去访问其中一个服务器,这样一来就不会出现所有的访问都指向同一个服务器从而导致崩盘的情况了