尚硅谷阳哥SpringCloud第二季学习笔记（二）

2.3 OpenFeign的超时控制

OpenFeign默认等待时间是1秒钟，超时即报错。如果服务提供方因为某种原因出现网络延迟，超时时间超过1秒钟，那么在用OpenFeign调用服务的时候就会出现超时报错。

解决方法是在yml中配置OpenFeign的超时时间

#设置feign客户端超时时间(OpenFeign默认支持ribbon)
ribbon:
#指的是建立连接后从服务器读取到可用资源所用的时间
ReadTimeout: 5000
#指的是建立连接所用的时间，适用于网络状况正常的情况下,两端连接所用的时间
ConnectTimeout: 5000


2.4 OpenFeign日志打印功能

2.4.1 是什么

Feign提供了日志打印功能，我们可以通过配置来调整日志级别，从而了解Feign中Http请求的细节。

2.4.2 日志级别

1. NONE：默认的，不显示任何日志；
2. BASIC：仅记录请求方法、URL、响应状态码及执行时间；
3. HEADERS：除了BASIC中定义的信息之外，还有请求和响应的头信息；
4. FULL：除了HEADERS中定义的信息之外，还有请求和响应的正文及元数据。

2.4.3 使用步骤

1. 写配置类

   @Configuration
public class FeignConfig {
@Bean
Logger.Level feignLoggerLevel(){
return Logger.Level.FULL;
}
}


2. 修改yml文件

   添加以下内容

   logging:
level:
#feign日志以什么级别监控哪个接口
com.jg.springcloud.service.PaymentFeignService: debug


3.1 概述

3.1.1 分布式系统面临的问题

复杂分布式体系结构中的应用程序有数十个依赖关系，每个依赖关系在某些时候将不可能避免的失败。

所以，通常当你发现一个模块下的某个实例失败后，这时候这个模块依然还会接收流量，然后这个有问题的模块还调用了其他的模块，这样就会发生级联故障，或叫雪崩。

3.1.2 Hystrix是什么

Hystrix是一个用于处理分布式系统的延迟和容错的开源库，在分布式系统里，许多依赖不可避免的会调用失败，比如超时、异常等，Hystrix能够保证在一个依赖出问题的情况下，不会导致整体服务失败，避免级联故障，以提高分布式系统的弹性。

“断路器”本身是一种开关装置，当某个服务单元发生故障之后，通过断路器的故障监控（类似熔断保险丝），向调用方返回一个符合预期的、可处理的备选响应（FallBack），而不是长时间的等待或者抛出调用方无法处理的异常，这样就保证了服务调用方的线程不会被长时间、不必要的占用，从而避免了故障在分布式系统中的蔓延，乃至雪崩。

3.1.3 能干嘛

1. 服务降级
2. 服务熔断
3. 接近实时的监控
4. 限流
5. 隔离

3.1.4 官网

地址

3.2 Hystrix重要概念

3.2.1 服务降级

所谓服务降级，简单来说就是当服务器忙或者服务不可用的时候，不让客户端等待并立刻返回一个友好提示，fallback。此时并不是说服务就直接挂掉了。

哪些情况会触发降级

1. 程序运行异常
2. 超时
3. 服务熔断触发服务降级
4. 线程池/信号量打满也会导致服务降级

3.2.2 服务熔断

当达到某个服务的最大访问量的时候，为了保证自己不会挂掉，会直接拒绝访问，然后调用服务降级的方法并返回友好提示。

3.2.3 服务限流

当有秒杀高并发等操作，可能会导致一瞬间或者一段时间内访问流量暴增，为了防止所有的流量都一起打过来，会进行一个排队机制，规定一定时间内放行几个，这就是服务限流。

3.3 Hystrix案例

3.3.1 构建服务提供方

创建module–>cloud-provier-hystrix-payment8001

导入依赖




org.springframework.cloud
spring-cloud-starter-netflix-hystrix



org.springframework.cloud
spring-cloud-starter-netflix-eureka-client



org.springframework.boot
spring-boot-starter-web


org.springframework.boot
spring-boot-starter-actuator


com.jg.springcloud
cloud-api-commons
${project.version}


org.springframework.boot
spring-boot-devtools
runtime
true


org.projectlombok
lombok
true


org.springframework.boot
spring-boot-starter-test
test




yml

server:
port: 8001
spring:
application:
name: cloud-provider-hystrix-payment
eureka:
client:
register-with-eureka: true
fetch-registry: true
service-url:
# 集群环境
# defaultZone: http://eureka7001.com:7001/eureka,http://eureka7002.com:7002/eureka
defaultZone: http://eureka7001.com:7001/eureka


主启动

@SpringBootApplication
@EnableEurekaClient
public class PaymentHystrixMain8001 {
public static void main(String[] args) {
SpringApplication.run(PaymentHystrixMain8001.class,args);
}
}


业务

@RestController
@Slf4j
public class PaymentController {
@Resource
private PaymentService paymentService;
@Value("${server.port}")
private String serverPort;
@GetMapping("/payment/hystrix/ok/{id}")
public String paymentInfo_OK(@PathVariable("id") Integer id){
String result = paymentService.paymentInfo_OK(id);
log.info("*****result"+result);
return result;
}
@GetMapping("/payment/hystrix/timeout/{id}")
public String paymentInfo_TimeOut(@PathVariable("id") Integer id){
String result = paymentService.paymentInfo_TimeOut(id);
log.info("*****result"+result);
return result;
}
}


说明：这里业务类有一个是正常的，另一个是采用线程等待的方式模拟网络卡顿。

1. 超时导致服务器变慢
2. 出错（宕机或程序运行出错）
3. 解决
   
   1. 被调用服务超时了，调用者不能一直卡死等待，必须有服务降级
   2. 被调用服务宕机了，调用者不能一直卡死等待，必须有服务降级
   3. 被调用服务是OK的，但是调用者自己出现故障或者有自我要求（自己的等待时间小于服务提供者），自己必须降级。

3.3.4 服务降级

3.3.4.1 服务提供方

设置自身调用超时时间的峰值，峰值内可以正常运行，超过了需要有兜底的方法处理，作服务降级fallback

在出现故障的方法上面声明方法出现故障要调用的兜底方法，以及设定调用兜底方法的时机。

定义一个兜底方法

主启动类上添加注解

3.3.4.2 服务调用方

服务提供方有自己的服务降级策略，那么服务调用方也应该有自己的降级策略，当服务调用方某个方法出错或是因为网络延迟的时候，我们也应该让它有个兜底的方法，而不是让它报错或是一直处在加载的状态，那样会影响整个微服务的调用链路。

启动类加上注解

yml文件开启客户端的Hystrix功能

#开启客户端Hystrix
feign:
hystrix:
enabled: true


业务方法加上兜底方法调用规则

3.3.5 当前存在的问题

每个业务方法对应一个兜底的方法，这样如果业务方法太多的话，会导致代码膨胀

解决思路：

使用@DefaultProperties(defaultFallback="")注解

1:1 每个方法配置一个服务降级方法，在技术上可以实现，但是也会让代码变得很繁琐

1:N 除了个别重要核心业务有专属，其它普通的可以通过统一跳转到统一处理结果页面。

在Controller方法上添加注解

定义全局FallbackMethod

public String payment_Global_FallbackMethod(){
return "Global异常处理信息，请稍后再试";
}


这样处理之后，一般的服务出现故障或是网络延迟都会去找全局的兜底方法，如果有个别的核心业务方法，还可以特别声明

3.3.6 新的问题

向上面那样做解决了代码膨胀的问题，但是同时的Fallback和业务方法耦合在了一起，所以，需要进一步优化，把Fallback method和业务方法解耦合。

解决方法

因为我们采用了OpenFeign实现负载均衡，我们在调用Controller层方法的时候都是去到对应的Service层方法，找到要调用服务的服务名然后去实现调用的，所以我们可以在声明一个类去继承service接口，然后这个类专门对service里面的方法实现Fallback。而且OpenFeign加在Service接口上的注解@FeignClient提供了对Fallback的支持

@Component
@FeignClient(value = "CLOUD-PROVIDER-HYSTRIX-PAYMENT",fallback = PaymentFallbackService.class)
public interface PaymentHystrixService {
@GetMapping("/payment/hystrix/ok/{id}")
String paymentInfo_OK(@PathVariable("id") Integer id);
@GetMapping("/payment/hystrix/timeout/{id}")
String paymentInfo_TimeOut(@PathVariable("id") Integer id);
}


3.3.7 服务熔断

3.3.7.1 熔断机制概述

熔断机制是应对雪崩效应的一种微服务链路保护机制。当扇出链路的某个微服务出错不可用或者响应时间太长时，会进行服务的降级，进而熔断该节点微服务的调用，快速返回错误的响应信息。

当检测到该节点微服务调用响应正常后，恢复调用链路

在SpringCloud框架里，熔断机制通过Hystrix实现。Hystrix会监控微服务间调用的状况，当失败的调用到一定阈值，缺省是5秒内调用失败20次，就会启动熔断机制。熔断机制的注解式@HystrixCommand

3.3.7.2 熔断是什么

相关文章地址

为一个业务方法设置服务熔断

//服务熔断
//开启Hystrix的服务熔断功能，10秒内如果10次请求有60%（也就是6次）失败的话，就熔断该服务。
@HystrixCommand(fallbackMethod = "paymentCircuitBreaker_fallback", commandProperties = {
@HystrixProperty(name = "circuitBreaker.enabled", value = "true"),
@HystrixProperty(name="circuitBreaker.requestVolumeThreshold",value="10"),
@HystrixProperty(name="circuitBreaker.sleepWindowInMilliseconds",value="10000"),
@HystrixProperty(name="circuitBreaker.errorThresholdPercentage",value="60"),
})
public String paymentCircuitBreaker(@PathVariable("id") Integer id) {
if (id <0) {
throw new RuntimeException("*****************id不能是负数");
}
String serialNumber = IdUtil.simpleUUID();
return Thread.currentThread().getName() + "\t" + "调用成功，流水号：" + serialNumber;
}
// 兜底方法
public String paymentCircuitBreaker_fallback(@PathVariable("id") Integer id) {
return "id不能为负数，请稍后再试,id：" + id;
}


在10秒钟如果10次请求有超过6次（阈值）都是失败的话，熔断器的开关就会断开（open），触发熔断机制，这样一段时间内即使有正常的请求也不会返回结果。一段时间后，这个服务会逐渐恢复，可能是因为没有再继续收到错误的请求的原因，熔断器会由open进入half open，放一部分的请求进入。再过一段时间，如果这些请求没有返回错误结果的请求，那么熔断器就会由half open又进入close状态。

3.3.7.3 熔断类型

1. 熔断打开：请求不再进行调用当前的服务，内部设置时钟一般为MTTR（平均故障处理时间），当打开时长达到所设时钟则进入半熔断状态
2. 熔断关闭：熔断关闭不会对服务进行熔断
3. 熔断半开：部分请求根据规则调用当前服务，如果请求成功且符合规则则认为当前服务恢复正常，关闭熔断。（一段时间之后（默认是5秒），这个时候断路器是半开状态，会让其中一个请求进行转发。如果成功，断路器会关闭，若失败，断路器开启。重复4和5）
4. 

HystrixProperty通用配置项

3.4 Hystrix工作流程

3.5 服务监控hystrixDashboard

3.5.1 概述

除了隔离依赖服务的调用以外，Hystrix还提供了准实时的调用监控（Hystrix Dashboard），Hystrix会持续地记录所有通过Hystrix发起的请求的执行信息，并以统计报表和图形的形式展示给用户，包括每秒执行多少请求多少成功，多少失败等。Netflix通过hystrix-metrics-event-stream项目实现了对以上指标的监控。Spring Cloud也提供了Hystrix Dashboard的整合，对监控内容转化成可视化界面。

3.5.2 仪表盘9001

创建新模块

创建module—>cloud-consumer-hystrix-dashboard9001

导入pom




org.springframework.cloud
spring-cloud-starter-netflix-hystrix-dashboard


org.springframework.boot
spring-boot-starter-actuator


org.springframework.boot
spring-boot-devtools
runtime
true


org.projectlombok
lombok
true


org.springframework.boot
spring-boot-starter-test
test




写yml

server:
port: 9001


主启动

需要添加新的注解

@SpringBootApplication
@EnableHystrixDashboard
public class HystrixDashboardMain9001 {
public static void main(String[] args) {
SpringApplication.run(HystrixDashboardMain9001.class,args);
}
}


对于需要监控的服务要添加的依赖


org.springframework.boot
spring-boot-starter-actuator



启动该监控微服务

3.5.3 断路器演示

被监控的服务除了要添加以上的依赖之外，还需要在主启动中添加配置，否则会报错

/**
*此配置是为了服务监控而配置，与服务容错本身无关，springcloud升级后的坑
*ServletRegistrationBean因为springboot的默认路径不是"/hystrix.stream"，
*只要在自己的项目里配置上下面的servlet就可以了
*/
@Bean
public ServletRegistrationBean getServlet() {
HystrixMetricsStreamServlet streamServlet = new HystrixMetricsStreamServlet();
ServletRegistrationBean registratiOnBean= new ServletRegistrationBean(streamServlet);
registrationBean.setLoadOnStartup(1);
registrationBean.addUrlMappings("/hystrix.stream");
registrationBean.setName("HystrixMetricsStreamServlet");
return registrationBean;
}


把要监控的地址填到HystrixDashboard的web页面中

监控图形说明