在微服务架构中,根据业务来拆分成一个个的服务,服务与服务之间可以相互调用(RPC),在Spring Cloud可以用RestTemplate+Ribbon和Feign来调用。为了保证其高可用,单个服务通常会集群部署。由于网络原因或者自身的原因,服务并不能保证100%可用,如果单个服务出现问题,调用这个服务就会出现线程阻塞,此时若有大量的请求涌入,Servlet容器的线程资源会被消耗完毕,导致服务瘫痪。服务与服务之间的依赖性,故障会传播,会对整个微服务系统造成灾难性的严重后果,这就是服务故障的“雪崩”效应。
为了解决这个问题,业界提出了断路器模型。
Hystrix是一个用于处理分布式系统的延迟 和容错的开源库,在分布式系统里,许多依赖不可避免的会调用失败,比如超时、异常等。Hystrix能够保证在一个依赖出问题的情况下,不会导致整体服务失败,避免级联故障,以提高分布式系统的弹性。
“断路器”本身是一种开关装置,当某个服务单元发生故障之后,通过断路器的故障监控(类似熔断保险丝),向调用方返回一个符合预期的、可处理的备选响应(FallBack),而不是长时间的等待或者抛出调用方 无法处理的异常, 这样就保证了服务调用方的线程不会被长时间、不必要地占用,从而避免了故障在分布式系统中的蔓延、乃至雪崩。
服务降级、服务熔断、服务限流、接近实时的监控。。。。
服务降级、服务熔断、服务限流
理论一大堆,先看个例子
org.springframework.cloud
spring-cloud-starter-netflix-hystrix
org.springframework.cloud
spring-cloud-starter-netflix-eureka-client
com.diligentkong.springcloud
cloud-api-common
${project.version}
org.springframework.boot
spring-boot-starter-web
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
server:
port: 8001
spring:
application:
name: cloud-provider-hystrix-payment
eureka:
client:
#表示是否将自己注册进EurekaServer中 默认为true
register-with-eureka: true
#是否从Eureka Server抓取已有的注册信息,默认为true 单节点无所谓,集群必须设置为true 才能配合ribbon使用负载均衡
fetch-registry: true
service-url:
defaultZone: http://localhost:7001/eureka
@SpringBootApplication
@EnableEurekaClient
public class PaymentHystrixMain8001 {
public static void main(String[] args) {
SpringApplication.run(PaymentHystrixMain8001.class,args);
}
}
@Service
public class PaymentServiceImpl implements PaymentService {
@Override
public String paymentInfo_OK(Integer id) {
return "线程池: "+Thread.currentThread().getName() + " paymentInfo_OK,id: " + id+"\t"+"O(∩_∩)O哈哈~";
}
@Override
public String paymentInfo_TimeOut(Integer id) {
int timeNumber = 3;
try {
TimeUnit.SECONDS.sleep(timeNumber);
} catch (InterruptedException e) {
e.printStackTrace();
}
return "线程池: "+Thread.currentThread().getName() + " paymentInfo_TimeOut,id: " + id+"\t"+"┭┮﹏┭┮ 呜呜"+ "耗时"+timeNumber+"秒";
}
}
controller层
@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;
}
}
访问:http://localhost:8001/payment/hystrix/ok/5
线程池: http-nio-8001-exec-8 paymentInfo_OK,id: 5 O(∩_∩)O哈哈~
http://localhost:8001/payment/hystrix/timeout/56
线程池: http-nio-8001-exec-5 paymentInfo_TimeOut,id: 56 ┭┮﹏┭┮ 呜呜耗时3秒
消费者80端加入访问hystrix8001,
在hystrix8001的基础上,加上
org.springframework.cloud
spring-cloud-starter-openfeign
server:
port: 80
eureka:
client:
#表示是否将自己注册进EurekaServer中 默认为true
register-with-eureka: false
#是否从Eureka Server抓取已有的注册信息,默认为true 单节点无所谓,集群必须设置为true 才能配合ribbon使用负载均衡
fetch-registry: true
service-url:
defaultZone: http://localhost:7001/eureka
@SpringBootApplication
@EnableFeignClients
public class OrderHystrixMain80 {
public static void main(String[] args) {
SpringApplication.run(OrderHystrixMain80.class,args);
}
}
@Component
@FeignClient(value = "CLOUD-PROVIDER-HYSTRIX-PAYMENT") //调用的是哪个微服务cloud-provider-hystrix-payment
public interface PaymentHystrixService {
@GetMapping("/payment/hystrix/ok/{id}")
public String paymentInfo_OK(@PathVariable("id") Integer id);
@GetMapping("/payment/hystrix/timeout/{id}")
public String paymentInfo_TimeOut(@PathVariable("id") Integer id);
}
controller层
@RestController
@Slf4j
public class OrderHystrixController {
@Resource
private PaymentHystrixService paymentHystrixService;
@GetMapping("/consumer/payment/hystrix/ok/{id}")
public String paymentInfo_OK(@PathVariable("id") Integer id){
String result = paymentHystrixService.paymentInfo_OK(id);
return result;
}
@GetMapping("/consumer/payment/hystrix/timeout/{id}")
public String paymentInfo_TimeOut(@PathVariable("id") Integer id){
String result = paymentHystrixService.paymentInfo_TimeOut(id);
return result;
}
}
启动7001, hystrix8001 hystrix80,访问
http://localhost/consumer/payment/hystrix/ok/1
线程池: http-nio-8001-exec-1 paymentInfo_OK,id: 1 O(∩_∩)O哈哈~
问题:
当我们进行高并发测试时,消费者80端,要么转圈圈等待,要么消费端报超时错误。
解决
对象服务8001 超时了,调用者80 不能一直卡死等待,必须有服务降级
对方服务8001 down机了,调用者80不能一直卡死等待,必须有服务降级
对方服务8001 ok了,调用者80 自己出故障或有自我要求(自己的等待时间小于服务提供者),自己处理降级。
8001先从自身找问题: 设置自身调用超时时间的峰值,峰值内可以正常运行,超时了需要有兜底的方法处理,作为服务降级fallback。
业务类修改内容:
主启动类上 添加一个注解 @EnableCircuitBreaker
测试:
http://localhost:8001/payment/hystrix/timeout/3
结果:
我是支付服务8001, 线程池: hystrix-PaymentServiceImpl-1 paymentInfo_TimeOutHandler,id: 3 ┭┮﹏┭┮
上图故意制造了一个异常 int age = 10/0 计算异常,
当前服务不可用了,做服务降级,兜底的方案就是:paymentInfo_TimeOutHandler
同样的道理,80订单服务 也可以更好的保护自己,进行客户端降级。
yml中添加
feign:
hystrix:
enabled: true
主启动类 OrderHystrixMain80上添加**@EnableHystrix注解**
修改业务类OrderHystrixController
访问:
http://localhost/consumer/payment/hystrix/timeout/1
结果:
我是消费者80,对方支付系统繁忙,请10秒钟再试试 或者自己运行出错请检查自己,┭┮﹏┭┮
说明:
Hystrix既可以放到 支付端 也可以放在 消费端,一般降级服务都放在 客户端
每个业务方法对应一个兜底的方法,代码膨胀;和业务逻辑混在一起,代码混乱。
从了个别重要核心业务有自己专属的兜底方法,其他普通的可以通过@DefaultProperties(defaultFallback=“”)统一跳转到统一处理结果页面
通用的和独有的各自分开,避免了代码膨胀,合理减少了代码量。
@RestController
@Slf4j
@DefaultProperties(defaultFallback = "payment_Global_FallbackMethod")
public class OrderHystrixController {
@Resource
private PaymentHystrixService paymentHystrixService;
@GetMapping("/consumer/payment/hystrix/ok/{id}")
public String paymentInfo_OK(@PathVariable("id") Integer id){
String result = paymentHystrixService.paymentInfo_OK(id);
return result;
}
@GetMapping("/consumer/payment/hystrix/timeout/{id}")
/*@HystrixCommand(fallbackMethod = "paymentTimeOutFallbackMethod" ,commandProperties = {
@HystrixProperty(name = "execution.isolation.thread.timeoutInMilliseconds",value = "1500")
})*/
@HystrixCommand //没有指明 就用默认的fallback
public String paymentInfo_TimeOut(@PathVariable("id") Integer id){
int age = 5/0; //一进来,方法就报错
String result = paymentHystrixService.paymentInfo_TimeOut(id);
return result;
}
public String paymentTimeOutFallbackMethod(@PathVariable("id") Integer id){
return "我是消费者80,对方支付系统繁忙,请10秒钟再试试 或者自己运行出错请检查自己,┭┮﹏┭┮";
}
// 下面是全局fallback方法
public String payment_Global_FallbackMethod(){
return "Global异常处理信息,请稍后再试,┭┮﹏┭┮";
}
}
访问http://localhost/consumer/payment/hystrix/timeout/1
Global异常处理信息,请稍后再试,┭┮﹏┭┮
本案例服务降级处理是在客户端80实现完成的,与服务端8001没有关系
80去调用8001,每一个方法都配一个兜底的方法,显得代码比较松散。
抓主要矛盾: 80能跑起来 是因为我们通过feignClient调用8001
只需要为Feign客户端定义的接口添加一个服务降级处理的实现类即可实现解耦
修改cloud-consumer-feign-hystrix-order80
根据cloud-consumer-feign-hystrix-order80已有的PaymentHystrixService接口,重新新建一个类(PaymentFallbackService)实现该接口,统一为接口里面的方法进行异常处理。
@Component
public class PaymentFallbackService implements PaymentHystrixService {
@Override
public String paymentInfo_OK(Integer id) {
return "------------PaymentFallbackService fall back-paymentInfo_OK,哈哈哈";
}
@Override
public String paymentInfo_TimeOut(Integer id) {
return "-----------PaymentFallbackService fall back-paymentInfo_TimeOut,呜呜呜";
}
}
yml
Yml
server:
port: 80
eureka:
client:
#表示是否将自己注册进EurekaServer中 默认为true
register-with-eureka: false
#是否从Eureka Server抓取已有的注册信息,默认为true 单节点无所谓,集群必须设置为true 才能配合ribbon使用负载均衡
fetch-registry: true
service-url:
defaultZone: http://localhost:7001/eureka
#用于服务降级 在注解@FeignClient中添加fallbackFactory属性值
feign:
hystrix:
enabled: true #在feign中开启hystrix
在PaymentHystrixService添加fallback = PaymentFallbackService.class
在PaymentHystrixService添加fallback = PaymentFallbackService.class
测试:
http://localhost/consumer/payment/hystrix/ok/1
线程池: http-nio-8001-exec-4 paymentInfo_OK,id: 1 O(∩_∩)O哈哈~
故意关闭微服务8001,继续访问,客户端自己调用提示:
------------PaymentFallbackService fall back-paymentInfo_OK,哈哈哈
此时服务端provider已经down了,但是我们做了服务降级处理,让客户端在服务端不可用时也会或得提示信息而不会挂起耗死服务器
熔断机制是应对雪崩效应的一种微服务链路保护机制。当扇出链路的某个微服务出错不可用或者响应时间太长时,会进行服务的降级,进而熔断该节点微服务的调用,快速返回错误的响应信息。
当检测到该节点微服务调用响应正常后,恢复调用链路。
在springcloud框架里,熔断机制通过hystrix实现。Hystrix会监控微服务间调用的状态,当失败的调用到一定阈值,缺省是5秒内20次调用失败,就会启动熔断机制。熔断机制的注解是**@HystrixCommand**
修改cloud-provider-hystrix-payment8001
在PaymentServiceImpl类中添加如下内容:
// ---------------服务熔断
@Override
@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(Integer id){
if (id < 0){
throw new RuntimeException("**********id 不能为负数");
}
String serialNumber = IdUtil.simpleUUID();
return Thread.currentThread().getName() + "\t" + "调用成功,流水号: " + serialNumber;
}
public String paymentCircuitBreaker_fallback(Integer id){
return "id 不能为负数, 请稍后再试,呜呜--- id:" + id;
}
PaymentController添加如下内容
// ============服务熔断
@GetMapping("/payment/circuit/{id}")
public String paymentCircuitBreaker(@PathVariable("id") Integer id){
String result = paymentService.paymentCircuitBreaker(id);
log.info("**********result: "+ result);
return result;
}
访问正确:
http://localhost:8001/payment/circuit/2
访问错误http://localhost:8001/payment/circuit/-2
重点测试:多次错误,然后慢慢正确,发现刚开始就算是正确的访问地址也不能返回正确的结果
涉及断路器的三个重要参数: 快照时间窗、请求总数阈值、错误百分比阈值
1.快照时间窗:断路器确定是否打开需要统计一些请求和错误数据,而统计的时间范围就是快照时间窗,默认为最近的10秒
2.请求总数阈值:在快照时间窗内,必须满座请求总数阈值才有资格熔断,默认为20,意味着在10秒内,如果该hystrix命令的调用次数不足20次,即使所有的请求都超时或其他原因失败,断路器都不会打开。
3.错误百分比阈值:当请求总数在快照时间窗内超过了阈值,比如发生了30次调用,如果在这30次调用中,有15次发生了超时异常,也就是超时50%的错误百分比,在默认设定50%阈值情况下,这时候就会将断路器打开。
断路器开启或者关闭的条件
当满足一定的阈值的时候,(默认10秒内超过20个请求次数)
当失败率达到一定的时候(默认10秒内超过50%的请求失败)
到达以上阈值,断路器将会开启
当开启的时候,所有请求都不会进行转发,一段时间之后(默认5秒),这个时候断路器是半开状态,会让其中一个请求进行转发。如果成功,断路器会关闭,若失败,继续开启。重复以上步骤
断路器打开之后
1.再有请求调用的时候,将不会调用主逻辑,而是直接调用降级fallback。通过断路器,实现了自动地发现错误并将降级逻辑切换为主逻辑,减少响应延迟的效果
2.原来的主逻辑要如何恢复呢?
对于这个问题,hystrix也为我们实现了自动恢复功能。
当断路器打开,对主逻辑进行熔断之后,hystrix会启动一个休眠时间窗,在这个时间窗内,降级逻辑是临时的成为主逻辑,当休眠时间窗到期,断路器将进入半打开状态,释放一次请求到原来的主逻辑上,如果此次请求正常返回,那么断路器将继续闭合,主逻辑恢复,如果这次请求依然有问题,断路器继续进入打开状态,休眠时间窗重新计时。
除了隔离依赖服务的调用以外,Hystrix还提供了 准实时的调用监控(Hystrix Dashboard),Hystrix会持续地记录所有通过Hystrix发起的请求的执行信息,并以统计报表和图形的形式展示给用户,包括每秒执行多少请求,多少成功,多少失败等。Netflix通过hystrix-mertics-event-stream项目实现了对以上指标的监控。Spring Cloud也提供了Hystrix Dashboard的整合,对监控内容转化成可视化界面。
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
application.yml
server:
port: 9001
主启动类
@SpringBootApplication
@EnableHystrixDashboard
public class HystrixDashboardMain9001 {
public static void main(String[] args) {
SpringApplication.run(HystrixDashboardMain9001.class,args);
}
}
启动9001 ,访问http://localhost:9001/hystrix
在其主启动类中添加如下代码:
@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;
}
启动7001,8001,9001
配置如下信息:
访问http://localhost:8001/payment/circuit/2
http://localhost:8001/payment/circuit/-2
自行观察界面的变化
github源代码地址:https://github.com/diligentkong/cloud2020