壹

工作中的微服务架构,某个服务通常会被多个服务调用或者多层调用完成需求,如果某个服务不可用,导致一个系统功能不可用或者服务直接没用了的情况,这种情况称为雪崩效应

有A服务调用B服务,B服务调用C服务,如果B服务调用C服务出了问题,那么B服务会一直重试,等待会将资源耗尽,结果B服务也不可用,导致A服务调用B服务的时候,也出问题,这样的话,ABC服务都瘫了

为预防以上问题,在下面学习Spring Cloud Hystrix,防雪崩,容错机制,基于NetFlix的Hystrix

Hystrix翻译中文是豪猪的意思,没见过也知道防御力很高的样子,还有之前学习的Eureka翻译中文的意思是找到了,就是后来词化成发现

Hystrix 供分布式系统使用，提供延迟和容错功能，隔离远程系统、访问和第三方程序库的访问

贰

Spring Cloud Hystrix

①服务降级

②服务熔断

③依赖隔离

④监控(Hystrix Dashboard)

根据以上特性功能开始学习

服务降级

这个功能其实我们平时也都见过,比如访问某宝页面抢购,某奇艺看东西会提示: 网络开小差了,请稍后再试等类似的提示

服务降级主导思想是区分业务,详细体现在优先核心服务,非核心服务不可用或放低其可用度,就有一种弃车保帅的意思,舍小保大

假设一个电商系统,某天的交易有巨大的流量出现,摆好的服务器资源就这么多,那么优先保证商品、订单、支付等服务的可用性,另外比如广告、积分等就属于非核心服务,那么就可以调度一下

细分到服务,比如商品服务,购买的时候,买家查询频繁度远高于卖家查询,那么就可以调度买家查询为核心服务,优先保证其可用性,另外买家查询服务就属于非核心服务,实际还需要根据业务场景调度

Hystrix的使用,通过@HystrixCommand注解,fallbackMethod回退函数实现降级逻辑

在之前的order服务和product服务进行学习,主要学习组件内容,按套路出牌

order服务

第一步maven加入Hystrix的依赖

1<dependency>
2    <groupId>org.springframework.cloud</groupId>
3    <artifactId>spring-cloud-starter-hystrix</artifactId>
4</dependency>

注意: 如果后面@DefaultProperties注解无法导入的话,在依赖上把版本号<version>加上

凡是遇到这样的问题,大多数原因是官方把这个包名改过了,为了继续使用原来已经使用过的组件依赖,要求加上version指定版本,才可以

这边spring-cloud-starter-hystrix的名字在spring cloud 2.0.3发布的正式版中改成了spring-cloud-starter-netflix-hystrix

所以引入依赖,改成以下写法就可以了

1<dependency>
2    <groupId>org.springframework.cloud</groupId>
3    <artifactId>spring-cloud-starter-netflix-hystrix</artifactId>
4</dependency>

第二步在启动类上,将之前的注解替换成@SpringCloudApplication,

该注解包含@SpringBootApplication @EnableDiscoveryClient @EnableCircuitBreaker三个注解的效果

从这点大家就可以明白怎么整合注解功能的使用

1@SpringCloudApplication
2@EnableFeignClients
3public class OrderApplication {
4    public static void main(String[] args) {
5        SpringApplication.run(OrderApplication.class, args);
6    }
7}

第三步创建一个controller测试代码

1/**
2 * 测试 使用hystrix
3 */
4@RestController
5@DefaultProperties(defaultFallback = "defaultFallback")
6public class HystrixController {
7    /**
8     * HystrixCommandProperties 参数对应查看
9     * 下面超时配置
10     */
11    @HystrixCommand(
12            commandProperties = {
13                    @HystrixProperty(name = "execution.isolation.thread.timeoutInMilliseconds",
14                                     value = "3000")
15            }
16    )
17    @GetMapping("/list")
18    public String list() {
19        RestTemplate restTemplate=new RestTemplate();
20        String s=restTemplate.postForObject("http://192.168.5.102:9001/product/list",
21        Arrays.asList("1"),String.class);
22        return s;
23    }
24
25    public String defaultFallback() {
26        return "拼命加载中...";
27    }
28}

简单的测试降级,请求发送会触发defaultFallback的返回,相关配置信息也不用记,实在太长了,知道在哪里就可以了,如果不出现降级,可以去url请求的终端服务做点小手脚,比如thread.sleep(xxx)

依赖隔离

依赖隔离就想到之前学习的docker,也具有隔离特性,docker实现进程的隔离,使容器之前互不影响,回来Hystrix,他使用的是线程池隔离方式,Hystrix会为每一个hystrixcommand创建独立的线程池,你就像上面测试的某一个依赖服务,并不会拖慢影响其他的服务,Hystrix自动实现依赖隔离

熔断机制

微服务分布式容错机制必须要考虑,到目前知道的方式主要两种,

①重试机制: 对应预期短暂的故障问题

②断路器模式: 对应更长时间的故障问题,该模式是将受保护的服务封装在一个可以监控故障的断路器对象中,当该服务的故障达到阀值,断路器就会采取措施,跳闸断路,断路器对象被采取返回错误的方式告之

martin fowler发的一篇文章,关于CircuitBreaker(断路器),

URL: https://martinfowler.com/bliki/CircuitBreaker.html

拿其中的执行状态机制图,做一个翻译学习

以上解释到断路器设计模式---状态机制,可以看出有三种状态closed、open、half open, 顾名思义,以熔断路为主角

closed: 熔断器关闭状态,调用失败次数累计达到阀值,就会启动熔断机制

open/half open: 熔断器打开状态,此时对服务都直接返回错误,该处设计时钟概念,到了点就会进入half open状态,运行一些服务请求,如果请求是成功的,就认为服务恢复了,关闭熔断器closed,否则就继续fail回到open状态

代码中注解配置写法类似超时设置,主要参数以及说明如下:

1/**
2 * HystrixCommandProperties 参数对应查看
3 * @return
4 */
5@HystrixCommand(
6        commandProperties = {
7                //超时设置
8                @HystrixProperty(name = "execution.isolation.thread.timeoutInMilliseconds",
9                                 value = "2000"),
10                //设置熔断
11                @HystrixProperty(name = "circuitBreaker.enabled",value = "true"),
12                //设置滚动窗口中，断路器的最小请求数量
13                @HystrixProperty(name = "circuitBreaker.requestVolumeThreshold",value = "10"),
14                //断路器确定是否需要打开统计请求和错误数据的时候，具有一个时间范围即时间窗口，当断路器打开，
15                //对主逻辑进行熔断之后，hystrix会启动休眠时间窗，此时降级逻辑会称为主逻辑，当休眠时间窗到期，断路           
16                //器就进入half open状态
17                //尝试释放请求到原主逻辑上，就想之前描述的，成功则断路器闭合closed，失败则继续打开open，休眠时间
18                //窗将重新计时
19                //以下设置休眠时间窗为10000毫秒
20                @HystrixProperty(name = "circuitBreaker.sleepWindowInMilliseconds",
21                                 value = "10000"),
22                //设置断路器打开的百分比条件，
23                //比如此处设置为60，在滚动窗口中发生了10次request，有7次发生了异常，超出设置值，则断路器就进入
24                //open状态，反之即closed
25                @HystrixProperty(name = "circuitBreaker.errorThresholdPercentage",value = "60")
26        }
27)
28@GetMapping("/list")
29public String list() {
30   ......
31}

以上是粗略学习hystrix,所以配置都写在了注解上面,下面转化配置文件,以超时设置为例,上面服务中的方法名字是list,下面设置一个默认超时设置和一个针对list方法的超时设置,在方法上需要加上@HystrixCommand注释,该注解有一个commandKey参数,指定该方法的key使用断路器,如果不设置默认是方法的名字,此处没有其他方法,图方便就直接用名字

hystrix: command: default: execution: isolation: thread: timeoutInMilliseconds: 2500 list: execution: isolation: thread: timeoutInMilliseconds: 2800

关于Hystrix还有控制面板可以观察调控的更清晰,还有结合Hystrix+feign等方面的使用,继续学习

-------------------------------------------------------------

SpringCloud 微服务 (十五) 服务容错 Hystrix

壹

贰

服务降级

order服务

依赖隔离

熔断机制

评论区

相关推荐