(学习记录)
一、概述
1.分布式系统面临的问题
复杂分布式体系结构中的应用程序有数十个依赖关系,每个依赖关系在某些时候将不可避免地失败。

服务雪崩
多个微服务之间调用的时候,假设微服务A调用微服务B和微服务C,微服务B和微服务C又调用其它的微服务,这就是所谓的“扇出”。如果扇出的链路上某个微服务的调用响应时间过长或者不可用,对微服务A的调用就会占用越来越多的系统资源,进而引起系统崩溃,所谓的“雪崩效应”.
对于高流量的应用来说,单一的后端依赖可能会导致所有服务器上的所有资源都在几秒钟内饱和。比失败更糟糕的是,这些应用程序还可能导致服务之间的延迟增加,备份队列,线程和其他系统资源紧张,导致整个系统发生更多的级联故障。这些都表示需要对故障和延迟进行隔离和管理,以便单个依赖关系的失败,不能取消整个应用程序或系统。
通常当你发现一个模块下的某个实例失败后,这时候这个模块依然还会接收流量,然后这个有问题的模块还调用了其他的模块,这样就会发生级联故障,或者叫雪崩。
2.是什么
Hystrix是一个用于处理分布式系统的延迟和容错的开源库,在分布式系统里,许多依赖不可避免的会调用失败,比如超时、异常等,Hystrix能够保证在一个依赖出问题的情况下,不会导致整体服务失败,避免级联故障,以提高分布式系统的弹性。
断路器:
“断路器”本身是一种开关装置,当某个服务单元发生故障之后,通过断路器的故障监控(类似熔断保险丝),向调用方返回一个符合预期的、可处理的备选响应(FallBack),而不是长时间的等待或者抛出调用方无法处理的异常,这样就保证了服务调用方的线程不会被长时间、不必要地占用,从而避免了故障在分布式系统中的蔓延,乃至雪崩。
3.作用
作用: 服务降级
服务熔断
接近实时的监控
官网资料:How To Use · Netflix/Hystrix Wiki · GitHub
Hystrix也进行了停更。
二、Hystrix重要概念
1.服务降级
服务器忙,请稍后再试,不让客户端等待并立刻返回一个友好提示,fallback
哪些情况会出发降级?
1.程序运行异常
2.超时
3.服务熔断触发服务降级
4.线程池/信号量打满也会导致服务降级
2.服务熔断
类比保险丝达到最大服务访问后,直接拒绝访问,拉闸限电,然后调用服务降级的方法并返回友好提示。
服务的降级->进而熔断->恢复调用链路
3.服务限流
秒杀高并发等操作,严禁一窝蜂的过来拥挤,大家排队,一秒钟N个,有序进行
三、hystrix案例
1.提供端
新建module工程:cloud-provider-hystrix-payment8001
1.配置pom.xml文件
<dependencies>
<!--hystrix-->
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-netflix-hystrix</artifactId>
</dependency>
<!--eureka client-->
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
</dependency>
<!--web-->
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-actuator</artifactId>
</dependency>
<dependency><!-- 引入自己定义的api通用包,可以使用Payment支付Entity -->
<groupId>com.atguigu.springcloud</groupId>
<artifactId>cloud-api-commons</artifactId>
<version>${project.version}</version>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-devtools</artifactId>
<scope>runtime</scope>
<optional>true</optional>
</dependency>
<dependency>
<groupId>org.projectlombok</groupId>
<artifactId>lombok</artifactId>
<optional>true</optional>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-test</artifactId>
<scope>test</scope>
</dependency>
</dependencies>
</project>
2.配置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
3.主启动
@SpringBootApplication
@EnableEurekaClient //本服务启动后会自动注册进eureka服务中
public class PaymentHystrixMain8001
{
public static void main(String[] args)
{
SpringApplication.run(PaymentHystrixMain8001.class,args);
}
}
4.业务类
service:
@Service
public class PaymentService
{
/**
* 正常访问,一切OK
* @param id
* @return
*/
public String paymentInfo_OK(Integer id)
{
return "线程池:"+Thread.currentThread().getName()+"paymentInfo_OK,id: "+id+"\t"+"O(∩_∩)O";
}
/**
* 超时访问,演示降级
* @param id
* @return
*/
public String paymentInfo_TimeOut(Integer id)
{
try { TimeUnit.SECONDS.sleep(3); } catch (InterruptedException e) { e.printStackTrace(); }
return "线程池:"+Thread.currentThread().getName()+"paymentInfo_TimeOut,id: "+id+"\t"+"O(∩_∩)O,耗费3秒";
}
}
controller:
@RestController
@Slf4j
public class PaymentController
{
@Autowired
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) throws InterruptedException
{
String result = paymentService.paymentInfo_TimeOut(id);
log.info("****result: "+result);
return result;
}
}
Jmeter压测测试结果:两个都在自己转圈圈
导致原因:tomcat的默认的工作线程数被打满 了,没有多余的线程来分解压力和处理
上面还是服务提供者8001自己测试,假如此时外部的消费者80也来访问,那消费者只能干等,最终导致消费端80不满意,服务端8001直接被拖死
2.消费端
根据上述,加入80:cloud-consumer-feign-hystrix-order80
1.配置pom.xml
加入hystrix和feign依赖
2.配置yml
简单注入Eureka注册中心
3.主启动
开启对应的服务
4.业务类
service接口加上@FeignClient注解,调用cloud-provider-hystrix-payment8001服务
controller调用
5.测试
正常访问:返回对应的结果
高并发访问:报消费端超时错误
正是因为出现以上问题,导致了我们hytrix的出现。
当超时导致服务器变慢(转圈)-----超时不再等待
出错(宕机或程序运行出错)-------出错要有兜底
四、Hytrix三大特性
1.服务降级
降级配置:
1.注解配置@HystrixCommand
2.在yml中配置
1.配置8001服务降级
先从8001开始:设置自身调用超时时间的峰值,峰值内可以正常运行,超过了需要有兜底的方法处理,作服务降级fallback
/**
* 超时访问,演示降级
一旦程序发生异常,或者超时,就会返回兜底方法(paymentInfo_TimeOutHandler)对应的内容
超时时间是3S
* @param id
* @return
*/
@HystrixCommand(fallbackMethod = "paymentInfo_TimeOutHandler",commandProperties = {
@HystrixProperty(name="execution.isolation.thread.timeoutInMilliseconds",value="3000")
})
public String paymentInfo_TimeOut(Integer id)
{
int second = 5;
try { TimeUnit.SECONDS.sleep(second); } catch (InterruptedException e) { e.printStackTrace(); }
return "线程池:"+Thread.currentThread().getName()+"paymentInfo_TimeOut,id: "+id+"\t"+"O(∩_∩)O,耗费秒: "+second;
}
public String paymentInfo_TimeOutHandler(Integer id){
return "/(ㄒoㄒ)/调用支付接口超时或异常:\t"+ "\t当前线程池名字" + Thread.currentThread().getName();
}
2.主启动:添加新注解@EnableCircuitBreaker //开启断路由
@SpringBootApplication
@EnableEurekaClient //本服务启动后会自动注册进eureka服务中
@EnableCircuitBreaker //开启断路由
public class PaymentHystrixMain8001 {
public static void main(String[] args) {
SpringApplication.run(PaymentHystrixMain8001.class,args);
}
/**
*此配置是为了服务监控而配置,与服务容错本身无关,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;
}
}
3.配置80降级 ,与8001有点不一样
3.1yml配置
#开启Feign中Hytrix功能
# Feign将使用断路器包装所有方法,也就是将@FeignClient标记的那个service接口下所有的方法进行了hystrix包装
feign:
hystrix:
enabled: true
#开启了Hystrix断路器并且设置了Hystrix的超时时间为6秒
hystrix:
command:
default:
execution:
timeout:
enabled: true
isolation:
thread:
timeoutInMilliseconds: 6000
ribbon:
ReadTimeout: 5000
ConnectTimeout: 5000
3.2启动类
@SpringBootApplication
@EnableFeignClients
@EnableHystrix //开启hystrix功能
public class OrderHystrixMain80 {
public static void main(String[] args) {
SpringApplication.run(OrderHystrixMain80.class,args);
}
}
3.3业务类
@GetMapping("/consumer/payment/hystrix/timeout/{id}")
@HystrixCommand(fallbackMethod = "paymentTimeOutFallbackMethod",commandProperties = {
@HystrixProperty(name="execution.isolation.thread.timeoutInMilliseconds",value="1500")
})
public String paymentInfo_TimeOut(@PathVariable("id") Integer id)
{
String result = paymentHystrixService.paymentInfo_TimeOut(id);
return result;
}
public String paymentTimeOutFallbackMethod(@PathVariable("id") Integer id)
{
return "我是消费者80,对方支付系统繁忙请10秒钟后再试或者自己运行出错请检查自己,o(╥﹏╥)o";
}
注意:此时 yml,注解方式都配置了,并且feign集成了ribbon。但是只会走一个时间,取三者最小的。
超时总结:
1.使用Feign调用接口分为两层,Ribbon的调用和Hystrix的调用,所以Ribbon的超时时间和Hystrix的超时时间的结合就是Feign的超时时间。
2.一般情况下 都是 Ribbon 的超时时间(<)Hystrix的超时时间(因为涉及到Ribbon 的重试机制),如果Ribbon 的超时时间大于Hystrix的超时时间,对于Ribbon 的重试是没有意义的(Hystrix超时熔断了,Ribbon 无法重试)。
这个参数的意思就是在feign中开启hytrix功能,所有的接口都会被hystrix包围。如果没有开启配置,只会触发ribbon超时
feign:
hystrix:
enabled: true注意:
.默认情况下,如果Ribbon没有配置重试时间和次数,默认是1S超时,默认会自动重试1次。
.默认情况下,如果Hystrix没有配置重试时间和次数,默认是1S超时,默认会自动重试1次比如:当开启hytrix功能后,假如hytrix设置超时时间为10S,ribbon设置6s,但是提供方需要8s运行完,还是会报重试异常。
因为此时,虽然hytrix功能没有超时,但是ribbon超时会触发重试机制,并且开启了Hystirx的断路器功能。
所以Ribbon在处理请求超时的时候,因为没有对Ribbon超时进行处理,Hystirx就出来起作用了,对服务进行熔断,降级处理,进而进入回调方法。再比如:yml中hystrix全局设置10s,通过注解设置6s,ribbon设置时间是8s,但是提供者消费7s.
所以此时以注解的时间为准,触发熔断机制,如果没有设置注解的超时时间,就不会触发熔断兜底方法。所以当二者碰到feign时要协同作战,同时设置ribbon超时和hystrix超时
总结:ribbon超时和hystrix超时只要中间触发一个,并且开启了feign中的hystrix功能,都会走兜底方法。还的注意他们两个的默认1s超时
4.80配置第二种
根据上述解决了,出问题没兜底的存在,但是每个业务方法对应一个兜底的方法,代码膨胀。
解决每个方法都要配置一个兜底方法,将公共的兜底提取,但是还是没有达到与业务逻辑的分离 1:1 每个方法配置一个服务降级方法,技术上可以,实际上傻X 1:N 除了个别重要核心业务有专属,其它普通的可以@DefaultProperties(defaultFallback = "") 统一跳转到统一处理结果页面
@DefaultProperties(defaultFallback = "payment_Global_FallbackMethod") public class PaymentHystirxController { @GetMapping("/consumer/payment/hystrix/timeout/{id}") @HystrixCommand //加了@DefaultProperties属性注解,并且没有写具体方法名字,就用统一全局的 public String paymentInfo_TimeOut(@PathVariable("id") Integer id) { String result = paymentHystrixService.paymentInfo_TimeOut(id); return result; } public String payment_Global_FallbackMethod() { return "Global异常处理信息,请稍后再试,/(ㄒoㄒ)/~~"; } }
解决和业务逻辑混在一起,最终方案:实现一个@FeignClient接口的实现类,指定参数fallback.
本次案例服务降级处理是在客户端80实现完成的,与服务端8001没有关系
只需要为Feign客户端定义的接口添加一个服务降级处理的实现类即可实现解耦。根据cloud-consumer-feign-hystrix-order80已经有的PaymentHystrixService接口,
重新新建一个类(PaymentFallbackService)实现该接口,统一为接口里面的方法进行异常处理实现类:
@Component //必须加 //必须加 //必须加 public class PaymentFallbackService implements PaymentFeignClientService { @Override public String getPaymentInfo(Integer id) { return "服务调用失败,提示来自:cloud-consumer-feign-order80"; } }修改yml:开启feign中的hystrix功能
PaymentFeignClientService接口修改:
@FeignClient(value = "CLOUD-PROVIDER-HYSTRIX-PAYMENT",fallback = PaymentFallbackService.class)
2.服务熔断
2.1概述
熔断机制是应对雪崩效应的一种微服务链路保护机制。当扇出链路的某个微服务出错不可用或者响应时间太长时,会进行服务的降级,进而熔断该节点微服务的调用,快速返回错误的响应信息。当检测到该节点微服务调用响应正常后,恢复调用链路。
在Spring Cloud框架里,熔断机制通过Hystrix实现。Hystrix会监控微服务间调用的状况,
当失败的调用到一定阈值,缺省是5秒内20次调用失败,就会启动熔断机制。熔断机制的注解是@HystrixCommand。
2.2实操
修改cloud-provider-hystrix-payment8001:
//=========服务熔断 //参数意思就是10S内,10次请求有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 不能负数,请稍后再试,/(ㄒoㄒ)/~~ id: " +id; }
涉及到断路器的三个重要参数:快照时间窗、请求总数阀值、错误百分比阀值。
1:快照时间窗:断路器确定是否打开需要统计一些请求和错误数据,而统计的时间范围就是快照时间窗,默认为最近的10秒。
2:请求总数阀值:在快照时间窗内,必须满足请求总数阀值才有资格熔断。默认为20,意味着在10秒内,如果该hystrix命令的调用次数不足20次,即使所有的请求都超时或其他原因失败,断路器都不会打开。
3:错误百分比阀值:当请求总数在快照时间窗内超过了阀值,比如发生了30次调用,如果在这30次调用中,有15次发生了超时异常,也就是超过50%的错误百分比,在默认设定50%阀值情况下,这时候就会将断路器打开
2.3熔断类型
熔断打开:请求不再进行调用当前服务,内部设置时钟一般为MTTR(平均故障处理时间),当打开时长达到所设时钟则进入半熔断状态
熔断关闭:熔断关闭不会对服务进行熔断
熔断半开:部分请求根据规则调用当前服务,如果请求成功且符合规则则认为当前服务恢复正常,关闭熔断
2.4熔断被打开的条件
1.当满足一定的阀值的时候(默认10秒内超过20个请求次数)
2.当失败率达到一定的时候(默认10秒内超过50%的请求失败)
3.到达以上阀值,断路器将会开启
4.当开启的时候,所有请求都不会进行转发
5.一段时间之后(默认是5秒),这个时候断路器是半开状态,会让其中一个请求进行转发。
如果成功,断路器会关闭,若失败,继续开启。重复4和5
2.5断路器被打开后的情况
1:再有请求调用的时候,将不会调用主逻辑,而是直接调用降级fallback。通过断路器,实现了自动地发现错误并将降级逻辑切换为主逻辑,减少响应延迟的效果。
2:原来的主逻辑要如何恢复呢?
对于这一问题,hystrix也为我们实现了自动恢复功能。
当断路器打开,对主逻辑进行熔断之后,hystrix会启动一个休眠时间窗,在这个时间窗内,降级逻辑是临时的成为主逻辑,
当休眠时间窗到期,断路器将进入半开状态,释放一次请求到原来的主逻辑上,如果此次请求正常返回,那么断路器将继续闭合,
主逻辑恢复,如果这次请求依然有问题,断路器继续进入打开状态,休眠时间窗重新计时。
3.服务限流
后面高级篇讲解alibaba的Sentinel说明
五、 服务监控hystrixDashboard
1.概述
除了隔离依赖服务的调用以外,Hystrix还提供了准实时的调用监控(Hystrix Dashboard),Hystrix会持续地记录所有通过Hystrix发起的请求的执行信息,并以统计报表和图形的形式展示给用户,包括每秒执行多少请求多少成功,多少失败等。Netflix通过hystrix-metrics-event-stream项目实现了对以上指标的监控。Spring Cloud也提供了Hystrix Dashboard的整合,对监控内容转化成可视化界面。
2.实操
工程名:cloud-consumer-hystrix-dashboard9001
2.1配置pom.xml
<dependencies>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-netflix-hystrix-dashboard</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-actuator</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-devtools</artifactId>
<scope>runtime</scope>
<optional>true</optional>
</dependency>
<dependency>
<groupId>org.projectlombok</groupId>
<artifactId>lombok</artifactId>
<optional>true</optional>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-test</artifactId>
<scope>test</scope>
</dependency>
</dependencies>
</project>
2.2yml配置
server:
port: 9001
2.3主启动
@SpringBootApplication
@EnableHystrixDashboard//开启
public class HystrixDashboardMain9001
{
public static void main(String[] args)
{
SpringApplication.run(MainApp9001.class,args);
}
}
注意:所有Provider微服务提供类(8001/8002/8003)都需要监控依赖配置
<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-actuator</artifactId> </dependency>
2.4测试
1.启动
2.访问:http://localhost:9001/hystrix
3.在测试前记得修改一下8001(新版本Hystrix需要在主启动类MainAppHystrix8001中指定监控路径)
访问后再次访问:http://localhost:8001/payment/circuit/31
断路器是关闭的
访问:http://localhost:8001/payment/circuit/-31
断路器是打开的
3. 如何看图?
实心圆:共有两种含义。它通过颜色的变化代表了实例的健康程度,它的健康度从绿色<黄色<橙色<红色递减。
该实心圆除了颜色的变化之外,它的大小也会根据实例的请求流量发生变化,流量越大该实心圆就越大。所以通过该实心圆的展示,就可以在大量的实例中快速的发现故障实例和高压力实例
曲线:用来记录2分钟内流量的相对变化,可以通过它来观察到流量的上升和下降趋势。




789

被折叠的 条评论
为什么被折叠?



