SpringCloud及其五大常用组件之Feign、Ribbon和Hystrix

1.Feign

我们已经将Eureka和Zuul开发完毕，而且上面注册了两个微服务，现在我们实现两个微服务之间的调用。

String baseUrl = "http://127.0.0.1:10010/user-service/user/";

User user = this.restTemplate.getForObject(baseUrl + id, User.class)

这样虽然能访问到，但是这样的代码不太优雅，这里使用了spring提供的RestTemplate,已经简化了操作，如果使用远程的httpclient，那更是怀疑人生，怎么实现优雅的访问呢？答案是Feign

Feign的英文含义假装，伪装

为什么叫伪装？

Feign可以把Rest的请求进行隐藏，伪装成类似SpringMVC的Controller一样。你不用再自己拼接url，拼接参数等等操作，一切都交给Feign去做。

下面为我们的demo加上feign：

1.在consumer-demo中导入依赖

<dependency>

    <groupId>org.springframework.cloud</groupId>

    <artifactId>spring-cloud-starter-openfeign</artifactId>

</dependency>

2.开发feign的客户端，其实就是一个接口

@FeignClient("user-service") //声明这是一个Feign客户端，同时通过value属性指定服务名称

public interface UserClient {

    @GetMapping("/user/{id}")  //这里的返回结果和 url地址一定要和提供方保持一致

    User queryById(@PathVariable("id") Long id);

}

注意：访问路径和返回结果一定要与服务端的提供方一致，因为feign会根据这个路径为我们生成代理对象

3.在启动类上开启feign的功能

@SpringCloudApplication

@EnableFeignClients // 开启Feign功能

public class ConsumerDemoApplication {

    public static void main(String[] args) {

        SpringApplication.run(UserConsumerDemoApplication.class, args);

    }

}

4.现在就可以使用feign的方式进行访问了

@RestController

@RequestMapping("/consumer")

public class ConsumerController {

    @Autowired

    private UserClient userClient;

    @GetMapping("{id}")

    public User queryById(@PathVariable("id") Long id){

        return userClient.queryById(id);

    }

}

到这里feign的功能就已经实现了，单独看controller是看不出使用了远程调用的，这就是feign的作用

最后强调：Feign中本身已经集成了Ribbon依赖和自动配置，不用再次引入依赖，就可以直接配置ribbon相关的参数

2.ribbon

说完了feign，可以知道，feign是通过服务在Eureka上的serviceId来找寻服务的，也就是user-service,那么如果我们现在有两个user-service的服务：

user-service: 192.168.100.1

user-serivice: 192.168.100.2

那么feign怎么知道你要请求的是哪个服务器呢？

这Ribbon就派上用场了。Ribbon就是专门解决这个问题的。它的作用是负载均衡，会帮你在每次请求时选择一台机器，均匀的把请求分发到各个机器上

Ribbon的负载均衡默认使用的最经典的Round Robin轮询算法。这是啥？简单来说，就是如果订单服务对库存服务发起10次请求，那就先让你请求第1台机器、然后是第2台机器、第3台机器、第4台机器、第5台机器，接着再来—个循环，第1台机器、第2台机器。。。以此类推

我们也可以通过配置文件更改它默认的负载均衡算法：

#这是将算法更改为了随机

user-service:

  ribbon:

    NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RandomRule

3.Hystrix

首先我们来了解一下什么是雪崩问题：

服务器支持的线程和并发数有限，请求一直阻塞，会导致服务器资源耗尽，从而导致所有其它服务都不可用，形成雪崩效应。

解决这个问题，我们就需要来学习一下hystrix

3.1 线程隔离

Hystrix为每个依赖服务调用分配一个小的线程池，如果线程池已满调用将被立即拒绝，

解释一下，假如现在有两个服务：user-service和order-service,现在hystrix会为这两个服务分配两个小的线程池，如果user-service宕机会导致它的线程池所有的线程都被卡着，但是并不会影响到order-service的线程池，这两就不会出现雪崩问题了。

3.2 服务熔断

在线程隔离中讲到，如果user-service宕机会导致它的线程池所有的线程都被卡着，每次对user-service的访问都会失败，既然都会失败，就不要再走网络请求了，这就用到了Hystrix的服务熔断机制：

假如5s中之内访问一个服务20次都失败了，那么这5s之内再去访问这个服务就直接给熔断了，也就是不再请求，直接判定失败，5秒20次是Hystrix的默认值

我们可以通知配置文件修改这些参数

circuitBreaker:

 requestVolumeThreshold: 10

 sleepWindowInMilliseconds: 10000

 errorThresholdPercentage: 50

解读：

requestVolumeThreshold：触发熔断的最小请求次数，默认10
sleepWindowInMilliseconds：休眠时长，默认是10000毫秒
errorThresholdPercentage：触发熔断的失败请求最小占比，默认50%

3.3 服务降级

熔断之后直接判定失败，直接返回时不太好的，总的做的什么操作吧，这就是降级服务，也就是失败之后执行的一个方法，在这个方法中可以去记录请求的信息，也可以返回一些友好的提示

我们在consumer-demo中的试一下：

1.导入依赖

<dependency>

    <groupId>org.springframework.cloud</groupId>

    <artifactId>spring-cloud-starter-netflix-hystrix</artifactId>

</dependency>

2.开启熔断

将启动类上的注解换成@SpringCloudApplication

@SpringCloudApplication

public class ConsumerApplication {

    // ...

}

3.编写降级逻辑

这里我们的降级逻辑，就返回一个提示好了

@GetMapping("{id}")

@HystrixCommand(fallbackMethod = "queryByIdFallBack")

public String queryById(@PathVariable("id") Long id){

    @Autowired

    private UserClient userClient;

    @GetMapping("{id}")

    public User queryById(@PathVariable("id") Long id){

        return userClient.queryById(id);

    }

}

public String queryByIdFallBack(Long id){

    log.error("查询用户信息失败，id：{}", id);

    return "对不起，网络太拥挤了！";

}

要注意，因为熔断的降级逻辑方法必须跟正常逻辑方法保证：相同的参数列表和返回值声明。

这样，这个服务降级功能就完成了