springcloud学习---Ribbon 学习记录01

整合ribbon很简单，添加依赖即可，也可以不用添加，eureka中已经引入。

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-ribbon</artifactId>
</dependency>

改造服务提供者

1.修改服务提供者application.yml文件，添加两个端口，相当于两个项目，其他的不变

---    ##可以看作是不同的配置文件
server:
  port: 8081

spring:
  profiles: ribbonTest1
---
server:
  port: 8082

spring:
  profiles: ribbonTest2

2.修改controller,为了看出效果，添加端口

@Value("${server.port}")
private String port;

@RequestMapping("getData")
public String getData(){
    return "hello world!  当前端口：" + port;
}

分别启动
java –jar a.jar –spring.profiles.activr=ribbonTest1
java –jar a.jar –spring.profiles.activr=ribbonTest2

启动成功如图所示：

继续在消费者服务中访问接口，效果如下：

填坑记录

问题描述：
整合ribbon之后，第一次访问会很快，但是后面的每次访问都会延迟，效果很不好，BD说：使用Ribbon或Feign实现服务调用的时候，ribbon进行客户端负载均衡的Client并不是在服务启动的时候就初始化好的，而是在调用的时候才去创建相对应的cient,所以第一次耗时不仅仅包含发送http请求的时间，还包含创建RibbonClient的时间，这样以来创建时间比较慢，同时设置的超时时间比较大短的话，就会出现上面的情况，而Feign是基于Ribbon实现的，也会出现同样的情况。
解决办法：在消费者服务配置中添加如下：

ribbon:
  eager-load:
    ## 开启饿汉式加载
    enabled: true
    ## 需要加载的实例或服务
    clients: lfq-provide-8081

通过LoadBalancerClient获取服务提供者的信息

@Autowired
private LoadBalancerClient loadBalancerClient;

@RequestMapping("getProvideInfo")
public Object getProvideInfo(){
    return loadBalancerClient.choose("LFQ-PROVIDE-8081");
}

结果如下：

Ribbon负载策略，默认轮询

Ribbon重试机制：

由于Eureka是基于AP原则的，牺牲了数据的一致性，每个Eureka都会保存注册的服务信息，但有一个Eureka挂掉时，任然存留注册的服务信息，这个时候客户端拿到的就是失效的服务信息，这样请求就会失败。
解决办法1：
利用ribbon的自带的重试机制，只需要指定某个服务的负载策略为重试策略即可：

ibbon.NFLoadBlanacerRuleClassName=com.netflix.loadbalancer.RetryRule

解决办法2：
Spring Retry重试

<!--重试机制-->
<dependency>
    <groupId>org.springframework.retry</groupId>
    <artifactId>spring-retry</artifactId>
</dependency>

ribbon: 
##请求连接的超时时间
  connectTimeout: 30000
  ##请求处理的超时时间
  readTimeout: 60000
  ##对当前实力的重试次数
  maxAutoRetries: 1
  ##切换实例的重试次数
  maxAutoRetriesNextServer: 3
  #对所有操作都进行重试
  okToRetryOnAllOperations: true