概述
分布式系统当中可能会面临的问题
复杂分布式系统结构中的应用程序有数十个依赖关系,每个依赖关系在某些时候将不可避免地失败
服务雪崩
多个服务之间调用的时候,假设微服务A调用微服务B和微服务C,微服务B和微服务C又调用其它的微服务,这就是所谓的“扇出”。如果扇出的链路上某个微服务的调用响应时间过程或者不可用,对微服务A的调用就会占用越来越多的系统资源,进而引起系统崩溃,所谓的“雪崩效应”
扇出:A调用B,B调用C,C调用D,就像一把折扇慢慢打开,依赖的程度慢慢加深加宽。
对于高流量的应用来说,单一的后端依赖可能会导致所有服务器上的所有资源都在几秒钟内饱和,比失败更糟糕的是,这些应用程序还可能导致服务之间的延迟增加,备份队列,线程和其它系统资源紧张,导致整个系统发生更多的级联故障。这些都表示需要对故障和延迟进行隔离和管理,以便单个依赖关系的失败,不能取消整个应用程序或系统。
是什么
Hystrix是一个用于处理分布式系统的延迟和容错的开源库,在分布式系统里,许多依赖不可避免的会调用失败,比如超时、异常等,Hystrix能够保证在一个依赖出问题的情况下,不会导致整体服务失败,避免级联故障,以提高分布式系统的弹性。
“断路器”本身是一种开关装置,当某个服务单元发生故障之后,通过断路器的故障监控(类似熔断保险丝),向调用放返回一个符合预期的、可处理的备选响应(FallBack),而不是长时间的等待或者抛出调用方无法处理的异常,这样就保证了服务调用方的线程不会被长时间、不必要地占用,从而避免了故障在分布式系统中的蔓延,乃至雪崩
官网资料
Hystrix官网
看到Hystrix是Netflix公司下的,我们的代码、样例、个人的思考都可以参考Wiki
服务熔断
熔断机制是应对雪崩效应的一种微服务链路保护机制。
当扇出链路的某个微服务不可用或者响应时间太长时,会进行服务降级,进而熔断该节点的微服务调用,快速返回“错误”的响应信息。 当检测到该节点微服务调用响应正常后恢复调用链路。在springCloud框架里熔断机制通过Hystrix实现。Hystrix会监控微服务间调用的状况,当失败调用到一定阀值,缺省是5秒内20次调用失败就会启动熔断机制。熔断机制的注解是@HystrixCommand
使用方法
引入pom依赖
<!--hystrix-->
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-hystrix</artifactId>
</dependency>
在代码上进行编写,在这之前我们看下示例
示例中在Controller方法上加了一个@HystrixCommand
注解,作用是在get方法抛出异常时候,就请调fallback中出异常了后的兜底的方法。即get方法出事了,就调用processHystrix_Get方法
在代码上编写
@RestController
public class DeptController
{
@Autowired
private DeptService service;
@RequestMapping(value = "/dept/get/{id}", method = RequestMethod.GET)
@HystrixCommand(fallbackMethod = "processHystrix_Get")
public Dept get(@PathVariable("id") Long id)
{
Dept dept=service.get(id);
if(dept==null){
throw new RuntimeException("该ID:"+id+"没有对应的信息");
}
return dept;
}
public Dept processHystrix_Get(@PathVariable("id")Long id){
return new Dept().setDeptno(id).setDname("该ID:"+id+"没有对应的信息,null--@HystrixCommand")
.setDb_source("no this database in MySQL");
}
}
在主启动类上加@EnableCircuitBreaker
@SpringBootApplication
@EnableEurekaClient
@EnableDiscoveryClient//本服务启动后会自动注册进eureka服务中
@EnableCircuitBreaker //对Hystrix熔断机制的支持
public class DeptProvider8001_Hystrix_App
{
public static void main(String[] args)
{
SpringApplication.run(DeptProvider8001_Hystrix_App.class, args);
}
}
运行结果
服务降级
整体资源快不够了,忍痛将某些服务先关掉,待度过难关,再开启回来。什么意思呢?举例
A、B、C三个项目组对外开发服务,每个组有5个开发在保持,突然有一天老板说由于客户变动及其重视A系统,现在A系统访问的压力也极大
这个时候,从保证优先级的角度,A系统的项目经理只好求老大从C系统去借调对应的工程师呢?同样,这个时候整体资源快不够了,A从C借调4个工程师
C不够了,这时候我们是不是忍痛将C暂时关掉呢?可是这样A保障了,C是不是还有些访问调用的请求呢?就好比银行A、B、C三个窗口,C这个业务员要被抽掉干别的事,是不是要挂一个暂停服务的牌子?不然给调用者一点说明都没有,那调用者就会生气了。我们关C支援A,但是C还是有一堆老客户来找他的,我们这应该给老客户一些回应,一些友好的降级处理,保证我们的服务来维系之后等A度过难关后,再重新开启C。
服务的降级是在客户端实现的,与服务端没有关系
使用
上图是服务熔断的使用方式,我们可以看到如果再增加list、add、update方法,那么都也会有一个@HystrixCommand
中指定的fallbackMethod方法,这样就有两个问题带来,
- 方法膨胀
加一个@HystrixCommand
我就要加一个用来兜底的方法 - springAOP面向切面的编程,Hystrix是SpringCloud的,那spring的原理概念也可以使用,上面代码是将处理业务的逻辑和处理异常的切面整合到一起了,高度耦合
@HystrixCommand
就是一个异常通知处理的意思呢?最好是不是实现一种效果,业务处理和异常处理不要耦合到一块。
避免上述两点,服务降级实现是这样
创建实现了FallbackFactory接口的DeptClientServiceFallbackFactory类
@Component //不要忘记添加,否则不好使
public class DeptClientServcieFallbackFactory implements FallbackFactory<DeptClientService> {
@Override
public DeptClientService create(Throwable throwable) {
return new DeptClientService() {
@Override
public Dept get(long id) {
return new Dept().setDname("ID"+id+"没有对应的信息,Consumer客户端提供降级消息,此刻provider服务已经关闭")
.setDb_source("no this database in MYSQL");
}
@Override
public List<Dept> list() {
return null;
}
@Override
public boolean add(Dept dept) {
return false;
}
};
}
DeptClientService接口在注解@FeignClient
中添加fallbackFactory属性值
@FeignClient(value = "MICROSERVICECLOUD-DEPT",fallbackFactory = DeptClientServcieFallbackFactory.class)
public interface DeptClientService {
。。。
配置文件中增加
feign:
hystrix:
enabled: true
运行时候,如果服务端关闭,consumer端就会返回下图
此时服务端Provider已经down了,但是我们做了服务降级处理,让客户端在服务端不可用时也会获得提示信息而不会耗死服务器
总结
所谓降级,一般是从整体符合考虑。就是当某个服务熔断之后,服务器将不再被调用,此时客户端可以自己准备一个本地的fallback回调,返回一个缺省值。
这样做,虽然服务水平下降,但好歹可用,比直接挂掉要强
服务监控hystrixDashboard
Hystrix除了隔离依赖服务的调用外,Hystrix还提供了准实时的调用监控(Hystrix Dashboard),Hystrix 会持续地记录所有通过Hystrix发起的请求的执行信息,并以统计报表和图形的形式展示给用户,包括每秒执行多少请求多少成功,多少失败等。
Netflix通过hystrix-metrics-event-stream项目实现了对以上指标的监控。Spring Cloud也提供了Hystrix Dashboard的整合,对监控内容转化成可视化界面
官网
左上角的breaker dashboard是熔断监控,就是对微服务的健康状态、调用状态、压力状态一个直观的图形化界面。
使用
引入pom依赖
<!-- hystrix和 hystrix-dashboard相关-->
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-hystrix</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-hystrix-dashboard</artifactId>
</dependency>
添加application.yml配置
server:
port: 9001
写main方法启动类
@SpringBootApplication
@EnableHystrixDashboard
public class DeptConsumer_DashBoard_App {
public static void main(String[] args){
SpringApplication.run(DeptConsumer_DashBoard_App.class,args);
}
}
启动项目,在浏览器访问http://localhost:9001/hystrix ,出现下图表示成功
上图的小动物像什么?像鸡,那吃鸡就打不过了。熊猫,那外面的刺是什么?它全身长刺,什么东西全身张刺?刺猬?豪猪——社会我豪猪,人狠话不多,它的意思是能够对你的微服务提供全方位的保护和监控
我们要监控单个应用,在地址栏输入Single Hystrix App: http://hystrix-app:port/hystrix.stream ,如http://localhost:8001/hystrix.stream ,就可以看到下图
还可以使用面板的形式
Delay:该参数用来控制服务器上轮询监控信息的延迟时间,默认为2000毫秒,可以通过配置该属性来降低客户端网络和CPU消耗
Title:该参数对应了头部标题Hystrix Stream 之后的内容,默认会使用具体监控实例的URL,可以通该信息来展示更合适的标题
可以看到出现了这样一个面板
上图的面板如何看呢?
7色
1圈
实心圆:共有两种含义。它通过颜色的变化代表了实例的健康程度,它的健康度从绿色<黄色<橙色<红色递减
该实心圆除了颜色的变化外,它的大小也会根据实例的请求流量发生变化,流量越大该实现圆就越大。所以通过该实心圆的展示,就可以在大量的实例中快速的发现故障实例和高压力实例
1线
曲线:用来记录2分钟内流量的相对变化,可以通过它来观察到流量的上升和下降趋势。