今天完成的事情：

服务降级：向客户端返回一个友好提示，不让客户端等待，fallback。总的来说相当于是一个兜底的方法。

哪些情况下会发生服务降级：

1.程序运行异常。

2.超时。

3.服务熔断触发服务降级。

4.线程池/信号量打满导致服务降级。

服务降级可以用在服务端，也可以用在客户端，不过一般常用于客户端。

具体实现：

导入依赖：

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

配置yml文件；

在主启动类上添加@EnableHystrix注解。

然后在conroller方法上添加@HystrixCommand注解：

@HystrixCommand(fallbackMethod = "portHandler")
@GetMapping(value = "/clientB/port")
public String port(){
    return feignStudentService.port();
}

public String portHandler(){
    return "请稍后重试";
}

相当于如果请求/clientB/port出错后使用portHandler方法。

测试：

由于只启动了8081端口的服务端，所以当轮询到8080端口时请求会出错，于是便服务降级到portHandler方法，返回提示。

还可以在注解上添加commandProperties属性来设置返回时间：

如图所示当请求超过1500ms时就直接服务降级。

服务熔断：达到最大服务访问后，直接拒绝访问，然后调用服务降级的方法返回友好提示。类似保险丝。

服务降级——进而熔断——>恢复调用链路

熔断机制可以在检测节点微服务调用响应正常后，恢复调用链路。

服务熔断使用很简单，只需要在服务降级命令的基础上加一些代码即可。

服务限流：秒杀等高并发操作，严禁一窝蜂的过来拥挤，一秒钟N个有序进行。

使用nginx代理两台web：

如果其中一台service挂了，并不影响另一台的使用，如果随机到挂了的那一台，会有友好提示：

将整个项目部署到服务器：

测试没问题：

提交任务了。

收获：学会使用Hystrix服务降级与服务熔断。

明天计划完成的事情：深度思考，准备复盘。