8、服务调用-Ribbon

系列文章目录

1、父工程创建
2、支付模块构建和热部署
3、消费者订单模块
4、服务注册中心-Eureka
5、zookeeper没学习
6、服务注册中心-Consul
7、Eureka、Consul异同
8、服务调用-Ribbon
9、服务调用-OpenFeign

10、服务降级-Hystrix
11、服务降级-Hystrix（二）
12、服务熔断-Hystrix
13、服务网关-Gateway
14-17 在git上做配置中心，没有学习
17、请求链路跟踪-Sleuth
18、Spring Cloud Alibaba-Nacos注册中心与配置中心
19、Spring Cloud Alibaba-Nacos集群和持久化配置
20、Sentinel流控
21、Sentinel熔断降级、热点key限流
22、SentinelResource配置
23、Sentinel 服务熔断与持久化

---

1. Ribbon介绍

基于客户端的负载均衡的工具 ，目前进入了维护模式。

1.1负载均衡(LB)：

简单的说就是将用户的请求平摊的分配到多个服务上，从而达到系统的高可用。常见的负载均衡有软件Nginx等

• 集中式LB
  即在服务的消费方和提供方之间使用独立的LB设施(如nginx)，由该设施负责把访问请求通过某种策略转发至服务的提供方;

• 进程内LB
  将LB逻辑集成到消费方，消费方从服务注册中心获知有哪些地址可用，然后自己再从这些地址中选择出一个合适的服务器。Ribbon就属于进程内LB，它只是一个类库，集成于消费方进程，消费方通过它来获取到服务提供方的地址。

1.2 Ribbon与Nginx负载均衡的区别

Rinbbon本地负载均衡与Nginx服务端负载均衡的区别？

• Nginx是服务器负载均衡，客户端所有请求都交给Nginx，由nginx实现转发请求，即负载均衡是由服务端实现的

• Ribbon本地负载均衡，在调用微服务接口的时候，会在注册中心上获取注册信息服务列表之后缓存在JVM本地，从而在本地实现RPC远程服务调用技术

2. 负载均衡演示

Ribbon在工作时分成两步：

1. 先选择EurekaServer ,它优先选择在同一个区域内负载较少的server。
2. 根据用户指定的策略，在从server取到的服务注册列表中选择一个地址。

其中Ribbon提供了多种策略：比如轮询、随机和根据响应时间加权

3. 再说RestTemplate

在引入eureka的依赖其实已经引入了ribbon依赖，所以使用Ribbon不需要在引入依赖。
ribbon= 负载均衡+RestTemplate

getForObject() / getForEntity() - GET请求方法

• getForObject()：返回对象为响应体中数据转化成的对象，基本上可以理解为Json。
• getForEntity()：返回对象为ResponseEntity对象，包含了响应中的一些重要信息，比如响应头、响应状态码、响应体等

	//PostForEntity()
    @GetMapping("/create")
    public CommonResult<Payment> createEntity(Payment payment){
        ResponseEntity<CommonResult> responseEntity = restTemplate.postForEntity(PAYMENT_URL + "/payment/create", payment, CommonResult.class);
        if(responseEntity.getStatusCode().is2xxSuccessful()){
            return responseEntity.getBody();
        }
        return new CommonResult<>(2333,"操作失败");
    }

	//getForEntity()
    @GetMapping("/get/{id}")
    public CommonResult<Payment> getPaymentEntity(@PathVariable("id") Long id){
        ResponseEntity<CommonResult> responseEntity = restTemplate.getForEntity(PAYMENT_URL + "/payment/get/"+id, CommonResult.class);
        if(responseEntity.getStatusCode().is2xxSuccessful()){
            return responseEntity.getBody();
        }
        return new CommonResult<>(2333,"操作失败");
    }

4. Ribbon的核心组件IRule

IRule:根据特定算法从服务列表中选取一个要访问的服务

• RoundRobinRule 轮询
• RandomRule 随机
• RetryRule 先按照RoundRobinRule的策略获取服务，如果获取服务失败则在指定时间内会进行重试，获取可用的服务。
• WeightedResponseTimeRule 对RoundRobinRule的扩展，响应速度越快的实例选择权重越大，越容易被选择
• BestAvailableRule 会先过滤掉由于多次访问故障而处于断路器跳闸状态的服务，然后选择一个并发量最小的服务
• AvailabilityFilteringRule 先过滤掉故障实例，再选择并发较小的实例
• ZoneAvoidanceRule 默认规则,复合判断server所在区域的性能和server的可用性选择服务器

4.1 如何替换负载均衡算法

4.1.1 修改cloud-consume-order80

4.1.2 细节部分

注意配置细节，自定义配置类不能放在@componentScan所扫描的当前包及其子包下，否则我们自定义的这个配置类会被所有Ribbon客户端所共享，达不到特殊定制化目的了（就是不要把这个配置类跟主启动类放在同一个包下）

4.1.3 新建packge

package com.atguigu.myrule，这样这个包不会被扫描

4.1.4 MyselfRule类

在新建的包下新建MyselfRule类

/**
 * @author lwd
 * @description 负载均衡配置类
 * @create 2021/07/16
 */
@Configuration
public class MyselfRule {

    @Bean
    public IRule myRule(){
        return  new RandomRule();
    }
}

4.1.5 添加注解

主启动类添加@RibbonClient，告诉启动之后使用哪个方法

//name:这个名称是eureka中服务端的服务名
@RibbonClient(name = "CLOUD-PAYMENT-SERVICE",configuration = MyselfRule.class)

4.1.6 测试

先开启Eureka微服务，在启动其他微服务。
浏览器-输入http://localhost/consumer/get/20
返回结果中的serverPort出现8001和8002不再像以前是交替出现的了。

5. 负载均衡算法

1. 默认的负载轮训算法原理
   rest接口的第几次请求数%服务器集群总数量 = 实际调用服务器下标，每次服务重启后rest接口计数从1开始
   会根据服务注册中心的的服务端的服务名查询实际服务地址组成的列表，使用取余的下标到列表中取值