服务熔断Hystrix入门

最新推荐文章于 2022-07-28 22:49:54 发布

超凡脱俗的程序猿

最新推荐文章于 2022-07-28 22:49:54 发布

阅读量212

点赞数 1

本文链接：https://blog.csdn.net/m0_54759967/article/details/120430507

版权

Spring Cloud 专栏收录该内容

10 篇文章 0 订阅

订阅专栏

1. 微服务架构的高并发问题

在微服务架构中，我们将业务拆分成一个个的服务，服务与服务之间可以相互调用，由于网络原因或者自身的原因，服务并不能保证服务的100%可用，如果单个服务出现问题，调用这个服务就会出现网络延迟，此时若有大量的网络涌入，会形成任务累计，导致服务瘫痪。在SpringBoot程序中，默认使用内置tomcat作为web服务器。单tomcat支持最大的并发请求是有限的，如果某一接口阻塞，待执行的任务积压越来越多，那么势必会影响其他接口的调用。

1.1 线程池的形式实现服务隔离

（1）配置坐标

为了方便实现线以线程池的形式完成资源隔离，需要引入如下依赖

<dependency>
    <groupId>com.netflix.hystrix</groupId>
    <artifactId>hystrix-metrics-event-stream</artifactId>
    <version>1.5.12</version>
</dependency>
<dependency>
    <groupId>com.netflix.hystrix</groupId>
    <artifactId>hystrix-javanica</artifactId>
    <version>1.5.12</version>
</dependency>

（2）配置线程池

配置HystrixCommand接口的实现类，再实现类中可以对线程池进行配置

public class OrderCommand extends HystrixCommand<String> {
    private RestTemplate restTemplate;
    private Long id;

    public OrderCommand(RestTemplate restTemplate, Long id) {
        super(setter());
        this.restTemplate = restTemplate;
        this.id = id;
    }

    private static Setter setter() {
        // 服务分组
        HystrixCommandGroupKey groupKey = HystrixCommandGroupKey.Factory.asKey("order_product");
        // 服务标识
        HystrixCommandKey commandKey = HystrixCommandKey.Factory.asKey("product");
        // 线程池名称
        HystrixThreadPoolKey threadPoolKey = HystrixThreadPoolKey.Factory.asKey("order_product_pool");
        /**
         * 线程池配置
         * withCoreSize : 线程池大小为10
         * withKeepAliveTimeMinutes: 线程存活时间15秒
         * withQueueSizeRejectionThreshold :队列等待的阈值为100,超过100执行拒绝
         策略
         */
        HystrixThreadPoolProperties.Setter threadPoolProperties =HystrixThreadPoolProperties.Setter().withCoreSize(50)
                                                                        .withKeepAliveTimeMinutes(15).withQueueSizeRejectionThreshold(100);
        // 命令属性配置Hystrix 开启超时
        HystrixCommandProperties.Setter commandProperties =HystrixCommandProperties.Setter()
                .withExecutionIsolationStrategy(HystrixCommandProperties.ExecutionIsolationStrategy.THREAD)// 采用线程池方式实现服务隔离
                .withExecutionTimeoutEnabled(false);// 禁止
        return HystrixCommand.Setter.withGroupKey(groupKey).andCommandKey(commandKey).andThreadPoolKey(threadPoolKey)
                    .andThreadPoolPropertiesDefaults(threadPoolProperties).andCommandPropertiesDefaults(commandProperties);
    }

    @Override
    protected String run() throws Exception {
        return restTemplate.getForObject("http://shop-serviceproduct/product/" + id, String.class);
    }

    @Override
    protected String getFallback() {
        return "熔断降级";
    }
}

（3）配置调用

修改 OrderController ，使用自定义的OrderCommand完成调用

@Autowired
private RestTemplate restTemplate;
@GetMapping("/buy/{id}")
public String order(@PathVariable Long id) throws ExecutionException,InterruptedException, TimeoutException {
    return new OrderCommand(restTemplate,id).execute();
}

2. 服务熔断Hystrix

2.1 服务容错的核心知识

2.1.1 雪崩效应

在微服务架构中，一个请求需要调用多个服务是非常常见的。如客户端访问A服务，而A服务需要调用B 服务，B服务需要调用C服务，由于网络原因或者自身的原因，如果B服务或者C服务不能及时响应，A服务将处于阻塞状态，直到B服务C服务响应。此时若有大量的请求涌入，容器的线程资源会被消耗完毕，导致服务瘫痪。服务与服务之间的依赖性，故障会传播，造成连锁反应，会对整个微服务系统造成灾难性的严重后果，这就是服务故障的“雪崩”效应。

雪崩是系统中的蝴蝶效应导致其发生的原因多种多样，有不合理的容量设计，或者是高并发下某一个方法响应变慢，亦或是某台机器的资源耗尽。从源头上我们无法完全杜绝雪崩源头的发生，但是雪崩的根本原因来源于服务之间的强依赖，所以我们可以提前评估，做好熔断，隔离，限流。

2.1.2. 服务隔离

顾名思义，它是指将系统按照一定的原则划分为若干个服务模块，各个模块之间相对独立，无强依赖。当有故障发生时，能将问题和影响隔离在某个模块内部，而不扩散风险，不波及其它模块，不影响整体的系统服务。

所谓降级，就是当某个服务熔断之后，服务器将不再被调用，此时客户端可以自己准备一个本地的 fallback回调，返回一个缺省值。也可以理解为兜底

2.1.4. 服务限流

限流可认为服务降级的一种，限流就是限制系统的输入和输出流量已达到保护系统的目的。一般来说系统的吞吐量是可以被测算的，为了保证系统的稳固运行，一旦达到的需要限制的阈值，就需要限制流量并采取少量措施以完成限制流量的目的。比方：推迟解决，拒绝解决，或者者部分拒绝解决等等。

2.2. Hystrix介绍

Hystrix是由Netflix开源的一个延迟和容错库，用于隔离访问远程系统、服务或者第三方库，防止级联失败，从而提升系统的可用性与容错性。Hystrix通过以下几点实现延迟和容错。

包裹请求：使用HystrixCommand包裹对依赖的调用逻辑，每个命令在独立线程中执行。这使用了设计模式中的“命令模式”。
跳闸机制：当某服务的错误率超过一定的阈值时，Hystrix可以自动或手动跳闸，停止请求该服务一段时间。
资源隔离：Hystrix为每个依赖都维护了一个小型的线程池（或者信号量）。如果该线程池已满，发往该依赖的请求就被立即拒绝，而不是排队等待，从而加速失败判定。
监控：Hystrix可以近乎实时地监控运行指标和配置的变化，例如成功、失败、超时、以及被拒绝的请求等。
回退机制：当请求失败、超时、被拒绝，或当断路器打开时，执行回退逻辑。回退逻辑由开发人员
自行提供，例如返回一个缺省值。
自我修复：断路器打开一段时间后，会自动进入“半开”状态。

2.3. Rest实现服务熔断

（1）配置依赖

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

（2）开启熔断

在启动类 Application 中添加 @EnableCircuitBreaker 注解开启对熔断器的支持。

@EntityScan("cn.itcast.entity")
@EnableCircuitBreaker //开启熔断器
@SpringBootApplication
//@SpringCloudApplication  //组合注解
public class OrderApplication {
    //创建RestTemplate对象
    @Bean
    @LoadBalanced
    public RestTemplate restTemplate() {
        return new RestTemplate();
    }
    public static void main(String[] args) {
        SpringApplication.run(OrderApplication.class, args);
    }
}

(3) 配置熔断降级业务逻辑

有代码可知，编写一个回退方法findProductFallBack，该方法与 findProduct 方法具有相同的参数与返回值类型，该方法返回一个默认的错误信息。使用注解@HystrixCommand的fallbackMethod属性，指定熔断触发的降级方法是 findProductFallBack 。

@RestController
@RequestMapping("/order")
public class OrderController {
    @Autowired
    private RestTemplate restTemplate;
    //下订单
    @GetMapping("/product/{id}")
    @HystrixCommand(fallbackMethod = "orderFallBack")
    public Product findProduct(@PathVariable Long id) {
        return restTemplate.getForObject("http://shop-serviceproduct/product/1", Product.class);
    }
    //降级方法
    public Product orderFallBack(Long id) {
        Product product = new Product();
        product.setId(-1l);
        product.setProductName("熔断:触发降级方法");
        return product;
    }
}

我们刚才把fallback写在了某个业务方法上，如果这样的方法很多，那岂不是要写很多。所以我们可以把Fallback配置加在类上，实现默认fallback：

@RestController
@RequestMapping("/order")
@DefaultProperties(defaultFallback = "orderFallBack" )
public class OrderController {

超时设置

在之前的案例中，请求在超过1秒后都会返回错误信息，这是因为Hystix的默认超时时长为1，我们可以通过配置修改这个值：

hystrix:
    command:
        default:
            execution:
                isolation:
                    thread:
                        timeoutInMilliseconds: 2000

2.4. Feign实现服务熔断

SpringCloud Fegin默认已为Feign整合了hystrix，所以添加Feign依赖后就不用在添加hystrix，怎么才能让Feign的熔断机制生效，只要按以下步骤开发：

(1) 修改application.yml在Fegin中开启hystrix

在Feign中已经内置了hystrix，但是默认是关闭的需要在工程的 application.yml 中开启对hystrix的支持

feign:
    hystrix: #在feign中开启hystrix熔断
        enabled: true

（2）配置FeignClient接口的实现类

基于Feign实现熔断降级，降级方法需要配置到FeignClient接口的实现类中

/**
* 实现自定义的ProductFeginClient接口
* 在接口实现类中编写熔断降级方法
*/
@Component
public class ProductFeginClientCallBack implements ProductFeginClient {
    /**
    * 降级方法
    */
    public Product findById(Long id) {
        Product product = new Product();
        product.setId(-1l);
        product.setProductName("熔断:触发降级方法");
        return product;
    }
}

（3）修改FeignClient添加hystrix熔断

在@FeignClient注解中添加降级方法

//指定需要调用的微服务名称
@FeignClient(name="service-product",fallback =ProductFeginClientCallBack.class)
public interface ProductFeginClient {
    //调用的请求路径
    @RequestMapping(value = "/product/{id}",method = RequestMethod.GET)
    public Product findById(@PathVariable("id") Long id);
}

超凡脱俗的程序猿

关注

1
点赞
踩
2

收藏

觉得还不错? 一键收藏
0
评论
服务熔断Hystrix入门

1.微服务架构的高并发问题在微服务架构中，我们将业务拆分成一个个的服务，服务与服务之间可以相互调用，由于网络原因或者自身的原因，服务并不能保证服务的100%可用，如果单个服务出现问题，调用这个服务就会出现网络延迟，此时若有大量的网络涌入，会形成任务累计，导致服务瘫痪。在SpringBoot程序中，默认使用内置tomcat作为web服务器。单tomcat支持最大的并发请求是有限的，如果某一接口阻塞，待执行的任务积压越来越多，那么势必会影响其他接口的调用。1.1 线程池的形式实现服务隔离..
复制链接

扫一扫

专栏目录