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

Easter79
• 阅读 676

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

有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的依赖

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-hystrix</artifactId>
</dependency>

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

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

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

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

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-netflix-hystrix</artifactId>
</dependency>

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

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

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

@SpringCloudApplication
@EnableFeignClients
public class OrderApplication {
    public static void main(String[] args) {
        SpringApplication.run(OrderApplication.class, args);
    }
}

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

/**
 * 测试 使用hystrix
 */
@RestController
@DefaultProperties(defaultFallback = "defaultFallback")
public class HystrixController {
    /**
     * HystrixCommandProperties 参数对应查看
     * 下面超时配置
     */
    @HystrixCommand(
            commandProperties = {
                    @HystrixProperty(name = "execution.isolation.thread.timeoutInMilliseconds",
                                     value = "3000")
            }
    )
    @GetMapping("/list")
    public String list() {
        RestTemplate restTemplate=new RestTemplate();
        String s=restTemplate.postForObject("http://192.168.5.102:9001/product/list",
        Arrays.asList("1"),String.class);
        return s;
    }

    public String defaultFallback() {
        return "拼命加载中...";
    }
}

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

依赖隔离

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

熔断机制

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

点赞
收藏
评论区
推荐文章
Easter79 Easter79
3年前
springcloud(四):熔断器Hystrix
熔断器雪崩效应在微服务架构中通常会有多个服务层调用,基础服务的故障可能会导致级联故障,进而造成整个系统不可用的情况,这种现象被称为服务雪崩效应。服务雪崩效应是一种因“服务提供者”的不可用导致“服务消费者”的不可用,并将不可用逐渐放大的过程。如果下图所示:A作为服务提供者,B为A的服务消费者,C和D是B
Easter79 Easter79
3年前
springcloud使用Hystrix实现微服务的容错处理
使用Hystrix实现微服务的容错处理容错机制如果服务提供者相应非常缓慢,那么消费者对提供者的请求就会被强制等待,知道提供者相应超时。在高负载场景下,如果不作任何处理,此类问题可能会导致服务消费者的资源耗尽甚至整个系统崩溃。雪崩效应微服务架构的应用系统通常包含多个服务层,微服务之间通过网络进行通信,从而支撑起整个应用系统,因此,微服务之间难免
Stella981 Stella981
3年前
Spring Cloud(三):服务容错保护——Spring Cloud Hystrix
  在微服务架构中,通常会出现服务不可用的现象,假设A为服务提供者,B为A服务的调用者,C、D为B服务的调用者,那么当A服务不可用之后,随着时间的推移就会导致B服务不可用,B服务的不可用可能会导致C、D服务的不可用,最终导致整个系统的不可用,为了解决这种级联失败的问题,在分布式架构中出现了断路器等一系列服务保护机制。  在SpringCloud中使用H
Wesley13 Wesley13
3年前
Java中使用HTTP阻塞式调用服务器API
应用场景:前端页面点击刷新,调用服务器A上Java接口,然后A调用服务器B的后台Python接口实时刷新后台数据库。在这个场景中会涉及到两个问题:异步,Python服务器压力(一)解决Python服务器压力如果Python服务器接口不做任何措施,那么可能会有恶意的访问,从而导致该服务器一直刷新后台数据库。我的解决方式是:服务器B会提供一串字符
Easter79 Easter79
3年前
SpringCloud笔记六:Hystrix
\TOC\Hystrix是什么?Hystrix是一个断路器,主要作用是服务熔断。我举个例子,比如我想访问服务A,但是服务A依赖服务B,服务B依赖服务C...这种多个服务之间依赖调用称为扇出(就像一把折扇缓缓打开一样)倘若某个服务反应的时间很长,或者服务不可用了,那么对服务A的调用会占用系统越来越多的资源,直至系统崩
Easter79 Easter79
3年前
SpringCloud的限流、降级和熔断——Hystrix
!(https://oscimg.oschina.net/oscnet/updb144b1538f24c2488b01c4e66a45d48038.JPEG)一、前言分布式系统环境中,服务间类似依赖非常常见,一个业余调用通常依赖多个基础服务。如下图,对于同步调用,当库存服务不可用时,商品服务请求线程被阻塞,当有大批量请求调用库存服务时,
Easter79 Easter79
3年前
SpringCloud课程:15.Hystrix断路器简介 与 服务降级
Hystrix断路器一、概述分布式系统面临的问题复杂分布式体系结构中的应用程序有数十个依赖关系,每个依赖关系在某些时候不可避免地失败。服务雪崩多个微服务之间调用的时候,假设微服务A调用微服务B和微服务C,微服务B和微服务C又调用其他的微服务,这就是所谓的“扇出效应” 如果扇出的链路上某个微服务的调用响应
Stella981 Stella981
3年前
Hystrix熔断机制原理剖析
一、前言在分布式系统架构中多个系统之间通常是通过远程RPC调用进行通信,也就是A系统调用B系统服务,B系统调用C系统的服务。当尾部应用C发生故障而系统B没有服务降级时候可能会导致B,甚至系统A瘫痪,这种现象被称为雪崩现象。所以在系统设计时候要使用一定的降级策略,来保证当服务提供方服务不可用时候,服务调用方可以切换到降
Easter79 Easter79
3年前
SpringCloud开发学习总结(三)—— 服务治理Eureka
 在最初开始构建微服务系统的时候可能服务并不多,我们可以通过做一些静态配置来完成服务的调用。比如,有两个服务A和B,其中服务A需要调用服务B来完成一个业务操作时,为了实现服务B的高可用,不论采用服务端负载均衡还是客户端负载均衡,都需要手工维护服务B的具体实例清单。但是随着业务的发展,系统功能越来越复杂,相应的微服务应用也不断增加,我们的静态配置会变得越来越
Stella981 Stella981
3年前
Hystrix原理与实战(文章略长)
背景分布式系统环境下,服务间类似依赖非常常见,一个业务调用通常依赖多个基础服务。如下图,对于同步调用,当库存服务不可用时,商品服务请求线程被阻塞,当有大批量请求调用库存服务时,最终可能导致整个商品服务资源耗尽,无法继续对外提供服务。并且这种不可用可能沿请求调用链向上传递,这种现象被称为雪崩效应。!(https://stati
Easter79
Easter79
Lv1
今生可爱与温柔,每一样都不能少。
文章
2.8k
粉丝
5
获赞
1.2k