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 "对不起，网络太拥挤了！";
}
要注意，因为熔断的降级逻辑方法必须跟正常逻辑方法保证：相同的参数列表和返回值声明。
这样，这个服务降级功能就完成了
