Hystrix服务容错

最新推荐文章于 2024-01-27 17:02:20 发布
最新推荐文章于 2024-01-27 17:02:20 发布
阅读量306 收藏
点赞数
分类专栏： 微服务 文章标签： java 微服务
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/weixin_37649025/article/details/124674657
版权

Hystrix服务容错

官方文档地址：Home · Netflix/Hystrix Wiki · GitHub

1、什么是Hystrix

Hystrix源自Netflix团队于2011开始研发，2012年Hystrix不断发展成熟，Netflix内部的许多团队都采用了它，如今，每天在Netflix上通过Hystrix执行数百亿个线程隔离和数千亿个信号量隔离的调用，极大地提高了系统的稳定性。

在分布式环境中，不可避免会有很多服务依赖项中的某些服务失败导致雪崩效应，Hystrix是一个库，可以通过添加等待时间容限和容错逻辑来帮助您控制这些分布式服务之间的交互。Hystrix通过隔离服务之间的访问点，停止服务之间的级联故障并提供后备选项来实现此目的，所有这些都可以提高系统整体稳定性。

2、雪崩效应

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

一切服务正常时，请求看起来是这样的：

image-20220422174641005

当其中一个服务有延迟时，它可能阻塞整个用户请求：

image-20220422175052290

在高并发的情况下，一个服务的延迟可能导致所有服务器上的所有资源在数秒内饱和。比起服务故障，更糟糕的是这些应用程序还可能导致服务之间的延迟增加，从而备份队列，线程和其他系统资源，从而导致整个系统出现更多级联故障。

image-20220422175802407

总结：

造成服务雪崩的原因可以归结为以下三点：

  • 服务提供者不可用（硬件故障，程序bug，缓存击穿，用户大量请求等）
  • 重试加大流量（用户重试，代码逻辑重试）
  • 服务消费者不可用（同步等待造成的资源耗尽）

最终的结果就是：一个服务不可用，导致一系列服务的不可用。

3、解决方案

雪崩是系统中的蝴蝶效应导致，其发生的原因多种多样，从源头我们无法完全杜绝雪崩的发生，但是雪崩的根本原因源于服务之间的强依赖，所以我们可以提前评估做好服务容错，解决方案大概可以分为以下几种：

  • 请求缓存：支持将一个请求与返回结果缓存处理
  • 请求合并：将相同的请求进行合并让后调用批处理接口
  • 服务隔离：限制调用分布式服务的资源，某一个调用的服务出现问题不会影响到其他服务调用
  • 服务熔断：牺牲局部服务，保全整体系统稳定性
  • 服务降级：服务熔断以后，客户端调用自己本地方法返回缺省值

4、模拟高并发场景

示例代码地址：https://gitee.com/junweihu/eureka-demo

服务提供者接口增加Thread.sleep(2000)，模拟服务处理时长

    @GetMapping("/{id}")
    public Product selectProductById(@PathVariable Integer id) {
        try {
            TimeUnit.MILLISECONDS.sleep(2000);  
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        return productService.selectProductById(id);
    }

服务消费者降低Tomcat最大线程数方便模拟高并发

server:
  port: 9090
  tomcat:
    max-connections: 200     # 降低最大线程数

JMeter

image-20220424165841629

下载地址：https://jmeter.apache.org/download_jmeter.cgi

修改配置

进入/bin目录编辑jmeter.properties文件，修改

  • language=zh_CN 显示中文
  • sampleresult.default.encoding=UTF-8 字符编码使用UTF-8

运行

运行/bin/jmeter.jar

添加线程组，设置线程属性

image-20220425153314894

添加HTTP请求，设置请求基本信息

image-20220425153524176

添加结果数，查看结果

image-20220425153749937

启动执行

image-20220425154004120

5、请求缓存

Hystrix为了降低访问服务的频率，支持将一个请求与返回结果做缓存处理。如果再次请求的URL没有变化，那么Hystrix不会请求服务，而是直接从缓存中将结果返回。这样可以大大降低访问服务的压力。

Hystrix自带缓存有两个缺点：

  • 本地缓存，集群情况下无法同步
  • 不支持第三方缓存，如Redis，MemCache

这里使用Spring的缓存集成方案，NoSql使用Redis来实现。

添加依赖

        <!--        spring boot data redis-->
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-data-redis</artifactId>
            <version>2.5.6</version>
        </dependency>

        <!--        对象池-->
        <dependency>
            <groupId>org.apache.commons</groupId>
            <artifactId>commons-pool2</artifactId>
            <version>2.9.0</version>
        </dependency>

添加配置

spring:
  application:
    name: service-consumer
  redis:
    host: localhost
    port: 6379
    password: root
    database: 0
    timeout: 10000         # 连接超时时间
    lettuce:
      pool:               # 连接池配置
        max-active: 1024  # 最大连接数
        max-wait: 10000   # 最大连接阻塞等待时间，单位毫秒
        max-idle: 200     # 最大空闲连接
        min-idle: 5       # 最小空闲连接

添加配置类

    /**
     * 重写redisTemplate序列化
     * @param redisConnectionFactory
     * @return
     */
    @Bean
    public RedisTemplate<String, Object> redisTemplate(RedisConnectionFactory redisConnectionFactory) {
        RedisTemplate<String, Object> template = new RedisTemplate<>();
        // 为String类型key设置序列化器
        template.setKeySerializer(new StringRedisSerializer());
        template.setValueSerializer(new GenericJackson2JsonRedisSerializer());
        // 为hash类型key设置序列化器
        template.setHashKeySerializer(new StringRedisSerializer());
        template.setHashValueSerializer(new GenericJackson2JsonRedisSerializer());
        template.setConnectionFactory(redisConnectionFactory);
        return template;
    }

    /**
     * 重写cache序列化
     * @param redisTemplate
     * @return
     */
    @Bean
    public RedisCacheManager redisCacheManager(RedisTemplate redisTemplate) {
        RedisCacheWriter redisCacheWriter = RedisCacheWriter.nonLockingRedisCacheWriter(redisTemplate.getConnectionFactory());
        RedisCacheConfiguration redisCacheConfiguration = RedisCacheConfiguration.defaultCacheConfig()
                // 设置默认过期时间
                .entryTtl(Duration.ofMinutes(30))
                // 设置key value的序列化
                .serializeKeysWith(RedisSerializationContext.SerializationPair.fromSerializer(new StringRedisSerializer()))
                .serializeValuesWith(RedisSerializationContext.SerializationPair.fromSerializer(new GenericJackson2JsonRedisSerializer()));

        return new RedisCacheManager(redisCacheWriter, redisCacheConfiguration);
    }

再需要缓存的方法上添加@Cacheable注解

    @Cacheable(cacheNames = "orderService:selectOrder")
    @GetMapping("/product/{id}")
    Product selectProductById(@PathVariable Integer id);

启动类添加@EnableCaching注解

// 开启缓存注解
@EnableCaching
@EnableFeignClients
@SpringBootApplication
public class ServiceConsumerApplication
{
    public static void main( String[] args )
    {
        SpringApplication.run(ServiceConsumerApplication.class);
    }
}

缓存结果

image-20220425163057376

6、请求合并

在微服务架构中，我们将多个项目拆分成很多独立的模块，这些独立的模块通过远程调用来互相配合工作，但是，在搞并发情况下，通信次数的增加会导致总的通信时间增加，同时，线程池的资源是有限的，高并发环境会导致大量的线程处于等待状态，进而导致响应延时，为了解决这些问题，我们需要了解Hystrix的请求合并。

image-20220425183517868
请求合并的缺点

设置请求合并之后，本来一个请求可能5ms就返回了，但是现在必须再等10ms看看还有没有其他的请求一起，这样一个请求的耗时就可能从5m增加到10ms。

如果我们要发起的请求本身就是一个高延时的请求，那么这个时候就可以使用请求合并了，因为这个时候时间消耗就显得微不足道了，另外高并发也是请求合并的一个非常重要的场景。

请求合并的实现

添加依赖

服务消费者添加hystrix依赖

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

添加配置

feign:
  hystrix:
    enabled: true

将多次调用selectById方法合并成一次调用selectByIds方法

    @GetMapping("/phones")
    public List<Product> selectPhoneList(@RequestParam List<Integer> ids) {
        ArrayList<Product> products = new ArrayList<>();
        ArrayList<Future<Product>> futures = new ArrayList<>();
        for (Integer id : ids) {
            Future<Product> productFuture = productService.selectById(id);
            futures.add(productFuture);
        }

        for (Future<Product> future : futures) {
            try {
                products.add(future.get());
            } catch (InterruptedException e) {
                e.printStackTrace();
            } catch (ExecutionException e) {
                e.printStackTrace();
            }
        }

        return products;
    }

合并请求

    // 合并请求
    // 处理合并请求的方法一定要支持异步，返回值必须是Future<T>
    @HystrixCollapser(batchMethod = "selectByIds", // 合并请求方法
            scope = com.netflix.hystrix.HystrixCollapser.Scope.GLOBAL,
            collapserProperties = {
                    // 间隔多久的请求会合并
                    @HystrixProperty(name = "timerDelayInMilliseconds", value = "200"),
                    // 批处理中允许的最大请求书
                    @HystrixProperty(name = "maxRequestsInBatch", value = "200")
            }
    )
    @Override
    public Future<Product> selectById(Integer id) {
        System.out.println("==call method selectById==");
        return null;
    }

    // 声明需要服务容错的方法
    @HystrixCommand
    @Override
    public List<Product> selectByIds(List<Integer> ids) {
        System.out.println("==call method selectByIds==");
        return productClient.selectPhoneList(ids);
    }

@HystrixCollapser注解说明

参数作用默认值备注
@HystrixCollapser被@HystrixCollapser标注的方法，返回类型必须为Future，使用异步方法，否则无法进行请求合并
batchMethod合并请求的方法方法只能接受一个参数，如果需要传递多个参数，可以将它们封装成一个参数
scope请求方式REQUEST请求方式分为REQUEST和GLOBAL。REQUEST只对一个request请求的多次服务调用进行合并；GLOBAL是对应用中的所有线程的请求中的多次调用进行请求合并
timerDelayInMilliseconds请求时间间隔在10ms之内的请求会被合并为一个请求10ms建议尽量设置的小一点，如果并发量不大的话，其实也没有必要使用HystrixCollapser来处理
maxRequestsInBatch设置触发批处理之前，在批处理中允许的最大请求数Integer.MAX_VALUE

启动类添加@EnableHystrix注解

// 开启熔断器
@EnableHystrix
// 开启缓存注解
@EnableCaching
@EnableFeignClients
@SpringBootApplication
public class ServiceConsumerApplication
{
    public static void main( String[] args )
    {
        SpringApplication.run(ServiceConsumerApplication.class);
    }
}

7、服务隔离

7.1、线程池隔离

没有线程池隔离的项目所有接口都运行在一个ThreadPool中，当某一个接口压力过大或者出现故障，会导致资源耗尽从而影响到其他接口的调用而引发服务雪崩效应。线程池隔离方式，等于多了一层保护措施，可以通过hystrix设置超时，超时后直接返回。

优点：

  • 使用线程池隔离可以安全隔离依赖的服务，减少所依赖的服务发生故障时的影响面。比如A服务发生异常，导致请求大量超时，对应的线程池被打满，这时并不影响在其他线程池中的C、D服务的调用。
  • 当失败的服务再次变得可用时，线程池将清理并立即恢复，而不需要一个长时间的恢复。
  • 独立的线程池提高了并发性。

缺点：

  • 请求在线程池中执行，肯定会带来任务调度、排队个上下文切换带来的CPU开销。
  • 因为涉及到跨线程，那么就存在ThreadLocal数据传递的问题，比如在主线程初始化的ThreadLocal变量，在线程池中无法获取。
实现线程池隔离

添加@HystrixCommand注解实现线程隔离

    // 线程池隔离
    @HystrixCommand(groupKey = "productServiceSinglePool", // 服务名称，相同名称使用同一个线程池
            commandKey = "selectProductById",              // 接口名称，默认为方法名
            threadPoolKey = "productServiceSinglePool",    // 线程池名称，相同名称使用同一个线程池
            commandProperties = {
                    // 超时时间，默认1000ms
                    @HystrixProperty(name = "execution.isolation.thread.timeoutInMilliseconds", value = "5000")
            },
            threadPoolProperties = {
                    @HystrixProperty(name = "coreSize", value = "5"),  // 线程池大小
                    @HystrixProperty(name = "maxQueueSize", value = "100"),  // 等待队列长度（最大队列长度，默认值-1）
                    @HystrixProperty(name = "keepAliveTimeMinutes", value = "2"), // 线程存活时间，默认1min
                    @HystrixProperty(name = "queueSizeRejectionThreshold", value = "100") // 超出等待队列阈值执行拒绝策略
            },
            fallbackMethod = "selectProductByIdFallBack"
    )
    @Override
    public Product selectProductById(Integer id) {
        System.out.println(Thread.currentThread().getName());
        return productClient.selectProductById(id);
    }

    private Product selectProductByIdFallBack(Integer id) {
        return new Product(888, "未知商品", 0, 0d);
    }

    // 线程池隔离
    @HystrixCommand(groupKey = "productServiceListPool", // 服务名称，相同名称使用同一个线程池
            commandKey = "selectByIds",              // 接口名称，默认为方法名
            threadPoolKey = "productServiceListPool",    // 线程池名称，相同名称使用同一个线程池
            commandProperties = {
            // 超时时间，默认1000ms
            @HystrixProperty(name = "execution.isolation.thread.timeoutInMilliseconds", value = "5000")
            },
            threadPoolProperties = {
            @HystrixProperty(name = "coreSize", value = "10"),  // 线程池大小
                    @HystrixProperty(name = "maxQueueSize", value = "100"),  // 等待队列长度（最大队列长度，默认值-1）
                    @HystrixProperty(name = "keepAliveTimeMinutes", value = "2"), // 线程存活时间，默认1min
                    @HystrixProperty(name = "queueSizeRejectionThreshold", value = "100") // 超出等待队列阈值执行拒绝策略
            },
            fallbackMethod = "selectByIdsFallback"
    )
    @Override
    public List<Product> selectByIds(List<Integer> ids) {
        System.out.println(Thread.currentThread().getName());
        return productClient.selectPhoneList(ids);
    }

    private List<Product> selectByIdsFallback(List<Integer> ids) {
        System.out.println("==call method selectByIdsFallback==");
        return Arrays.asList(new Product(999, "未知商品", 0, 0d));
    }

分别调用两个线程池里的方法

image-20220426173107776

可以通过修改服务提供者使接口超时，触发服务降级

7.2、信号量隔离

每个请求线程通过计数信号进行限制，当信号量大于了最大请求数maxConcurrentRequest时，进行限制，调用fallback接口快速返回。信号量的调用是同步的，也就是说，每次调用都得阻塞调用方的线程，直到结果返回。这样就导致了无法对访问做超时处理（只能依靠协议超时，无法主动释放）。

image-20220426182150665
实现信号量隔离
// 信号量隔离
@HystrixCommand(
        commandProperties = {
                // 超时时间，默认1000ms
                @HystrixProperty(name = HystrixPropertiesManager.EXECUTION_ISOLATION_THREAD_TIMEOUT_IN_MILLISECONDS, value = "5000"),
                // 信号量隔离
                @HystrixProperty(name = HystrixPropertiesManager.EXECUTION_ISOLATION_STRATEGY, value = "SEMAPHORE"),
                // 信号量最大并发
                @HystrixProperty(name = HystrixPropertiesManager.EXECUTION_ISOLATION_SEMAPHORE_MAX_CONCURRENT_REQUESTS, value = "5")
        },
        fallbackMethod = "selectProductByIdFallBack"
)
@Override
public Product selectProductById(Integer id) {
    System.out.println(Thread.currentThread().getName());
    return productClient.selectProductById(id);
}

@HystrixCommand注解说明

参数作用默认值备注
execution.isolation.strategy隔离策略配置项THREAD只有两种THREAD和SEMAPHORE
execution.isolation.thread.timeoutInMilliseconds超时时间1000ms在THREAD模式下，达到超时时间，自动终断；SEMAPHORE模式下，会等待执行完成后，再去判断是否超时；
execution.isolation.thread.interruptOnTimeout是否打开超时线程终断TRUETHREAD模式有效
execution.isolation.semaphore.maxConcurrentRequests信号量最大并发度10SEMAPHORE模式有效
fallback.isolation.semaphore.maxConcurrentRequestsfallback最大并发度·10SEMAPHORE模式有效

7.3、线程池隔离VS信号量隔离

7.3.1、线程池隔离
  • 处理请求线程和调用provider线程不是同一个线程
  • 支持超时，可以直接返回
  • 支持熔断，当线程池达到最大线程数后，再请求会触发fallback接口熔断
  • 隔离原理：每个服务使用单独线程池
  • 支持异步和同步方式
  • 资源消耗大，大量的线程上下文切换、排队、调度等，容易造成机器负载高
  • 无法传递http header
7.3.2、信号量隔离
  • 请求线程和调用provider线程是同一线程
  • 不支持超时
  • 支持熔断，当信号量达到maxConcurrentRequests后，再请求会触发fallback接口熔断
  • 隔离原理：通过信号量计数器
  • 仅支持同步调用，不支持异步
  • 资源消耗小，只是个计数器
  • 可以传递http header
7.3.4、总结
  • 请求并发大，耗时长，采用线程池隔离策略。这样可以保证大量的线程可用，不会由于服务原因一直处于阻塞或等待状态，快速失败返回。还有就是对依赖服务的网络请求涉及超时问题的都使用线程隔离。
  • 请求并发大，耗时短，采用信号量隔离，因为这类服务的返回通常很快，不会占用线程太长时间，而且也减少了线程切换的开销。

8、服务熔断

服务熔断一般是指软件系统中，由于某些原因使得服务出现了过载现象，为了防止造成整个系统故障，从而采用的一种保护措施，所以很多地方也把熔断称为过载保护。

image-20220427170614144

断路器的打开和关闭流程官网解释如下：

image-20220507162132620

  1. 请求次数是否达到阈值
  2. 错误百分比是否超过阈值
  3. 断路器状态从关闭到开启
  4. 断路器打开时所有请求短路
  5. 一定时间后，让下一个请求通过（此时是半开状态），如果请求失败断路器还是开启状态，如果请求成功了断路器关闭，回到第一步

服务熔断实现

@HystrixProperty注解

name:HystrixPropertiesManager

defaultValue:HystrixCommandProperties

    // 服务熔断
    @HystrixCommand(
            commandProperties = {
                    // 请求数阈值：在快照时间窗口内，必须满足请求阈值数才有资格熔断。打开断路器的最少请求数，默认20个请求。意味着在时间窗口内，如果调用次数少于20次，即使所有的请求都超时或者失败，断路器都不会打开
                    @HystrixProperty(name = HystrixPropertiesManager.CIRCUIT_BREAKER_REQUEST_VOLUME_THRESHOLD, value = "10"),
                    // 错误百分比阈值：当请求总数在快照内超过了阈值，且有一半的请求失败，这时断路器将会打开。默认50%
                    @HystrixProperty(name = HystrixPropertiesManager.CIRCUIT_BREAKER_ERROR_THRESHOLD_PERCENTAGE, value = "50"),
                    // 快照时间窗口：断路器开启时需要统计一些请求和错误数据，统计的时间范围就是快照时间窗口，默认5秒
                    @HystrixProperty(name = HystrixPropertiesManager.CIRCUIT_BREAKER_SLEEP_WINDOW_IN_MILLISECONDS, value = "5000")
            },
            fallbackMethod = "selectProductByIdFallBack"
    )
    @Override
    public Product selectProductById(Integer id) {
        System.out.println(Thread.currentThread().getName()+ LocalDateTime.now().format(DateTimeFormatter.ISO_LOCAL_TIME));
        if (id == 1) {
            throw new RuntimeException("模拟查询ID为1导致异常");
        }
        return productClient.selectProductById(id);
    }

可以看到熔断以后相同的请求5秒调用一次selectProductById，其他时间直接调用fallback方法

image-20220427175127978

9、服务降级

9.1、开启条件
  • 方法抛出HystrixBadRequestException异常
  • 方法调用超时
  • 熔断器开启拦截调用
  • 线程池、队列、信号量跑满
9.2、服务降级实现
9.2.1、方法服务降级
// 服务降级
@HystrixCommand(fallbackMethod = "selectProductByIdFallBack")
@Override
public Product selectProductById(Integer id) {
    System.out.println(Thread.currentThread().getName()+ LocalDateTime.now().format(DateTimeFormatter.ISO_LOCAL_TIME));
    if (id == 1) {
        throw new RuntimeException("模拟查询ID为1导致异常");
    }
    return productClient.selectProductById(id);
}
9.2.2、类全局服务降级

在类中添加注解

@DefaultProperties(defaultFallback = "selectProductByIdFallback")

image-20220507152724186

在需要降级的方法上添加注解

@HystrixCommand

image-20220507152841742

创建一个全局fallbakc方法

public Product selectProductByIdFallback(){
    return new Product(999, "undefined", 0, 0d);
}

10、Feign实现服务容错

@FeignClient注解申明的接口实现fallbackFactory，在类中new 一个接口的实现类，在方法中重写异常处理相关逻辑

@Slf4j
@Component
public class ProductFallbackFactory implements FallbackFactory<ProductClient> {
    @Override
    public ProductClient create(Throwable throwable) {
        return new ProductClient() {
            @Override
            public List<Product> selectProductList() {
                // 异常处理 todo
                log.error("ProductFallbackFactory-selectProductList异常",throwable);
                return null;
            }

            @Override
            public Product selectProductById(Integer id) {
                // 异常处理 todo
                log.error("ProductFallbackFactory-selectProductById异常", throwable);
                return null;
            }

            @Override
            public Map addProduct(Product product) {
                // 异常处理 todo
                log.error("ProductFallbackFactory-addProduct异常",throwable);
                return null;
            }

            @Override
            public Product selectByProduct(Product product) {
                // 异常处理 todo
                log.error("ProductFallbackFactory-selectByProduct异常",throwable);
                return null;
            }

            @Override
            public List<Product> selectPhoneList(List<Integer> ids) {
                // 异常处理 todo
                log.error("ProductFallbackFactory-selectPhoneList异常",throwable);
                return null;
            }
        };
    }
}

@FeignClient注解添加fallbackFactory配置

@FeignClient(value = "service-provider", fallbackFactory = ProductFallbackFactory.class)
public interface ProductClient {

    @GetMapping("/product/list")
    List<Product> selectProductList();

    @GetMapping("/product/{id}")
    Product selectProductById(@PathVariable Integer id);

    @PostMapping("/product/add")
    Map addProduct(@RequestBody Product product);

    @GetMapping("/product/pojo")
    Product selectByProduct(Product product);

    @GetMapping("/product/phoneList")
    List<Product> selectPhoneList(@RequestParam List<Integer> ids);
}

关闭provider服务，此时调用接口，服务降级，打印异常信息

image-20220427192046743

11、Hystrix服务监控

除了实现服务容错之外，Hystrix还提供了近乎实时的监控功能，将服务执行结果、运行指标、请求数量、成功数量等这些状态通过Actuator进行收集，然后访问/actuator/hystrix.stream即可看到实时的监控数据。

11.1、添加依赖

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-actuator</artifactId>
</dependency>

11.2、添加配置

management:
  endpoints:
    web:
      exposure:
        include: hystrix.stream

11.3、启动类

添加@EnableHystrix注解

11.4、访问

http://localhost:9090/actuator/hystrix.stream

11.5、查看数据

image-20220506150347330

11.6、监控中心

所谓的监控中心就是Hystrix提供的一套可视化系统，Hystrix-Dashboard，可以非常友好的看到当前环境中服务运行的状态。Hystrix-Dashboard是一款针对Hystrix进行实时监控的工具，通过Hystrix-Dashboard我们可以直观地看到各Hystrix Command的请求响应时间，请求成功率等数据。

11.6.1、添加依赖

在需要开启数据监控的项目中添加dashboard依赖

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

<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>

启动类

添加注解@EnableHystrixDashboard

// 开启数据监控
@EnableHystrixDashboard
// 开启熔断器
@EnableHystrix
// 开启缓存注解
@EnableCaching
@EnableFeignClients
@SpringBootApplication
public class ServiceConsumerApplication
{
    public static void main( String[] args )
    {
        SpringApplication.run(ServiceConsumerApplication.class);
    }
}

访问

访问：http://localhost:9090/hystrix，控制中心界面如下：

image-20220506163623761

image-20220506164645140

11.7、聚合监控中心搭建

Turbine是聚合服务器发送事件流数据的一个工具，dashboard只能监控单个节点，实际生产环境中都为集群，因此可以通过Turbine来监控集群服务。

新建一个聚合监控项目，添加依赖

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

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

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

添加配置文件

server:
  port: 8181

spring:
  application:
    name: eureka-turbine

eureka:
  instance:
    prefer-ip-address: true
    instance-id: ${spring.cloud.client.ip-address}:${server.port}
  client:
    service-url:
      defaultZone: http://localhost:8761/eureka/,http://localhost:8762/eureka/


turbine:                                            # 聚合监控
  app-config: service-consumer,service-provider     # 监控的服务列表
  cluster-name-expression: "'default'"              # 指定集群名称

启动类添加注解

@EnableTurbine
@EnableHystrix
@EnableHystrixDashboard
@SpringBootApplication
public class App 
{
    public static void main( String[] args )
    {
        SpringApplication.run(App.class);
    }
}

访问http://localhost:8181/hystrix

image-20220506201009328

image-20220506201050939

12、Hystrix工作流程总结

image-20220509200325097

  1. 构造一个HystrixCommand或者HystrixObservableCommand对象
  2. 执行command命令
  3. 结果是否缓存
  4. 熔断器是否打开
  5. 线程池、队列、信号量是否打满
  6. 执行对应的构造方法或者run方法
  7. 计算熔断器状态开启还是关闭
  8. 获取fallback返回
  9. 返回成功响应
稳重的窝瓜
关注
专栏目录
Hystrix 服务容错保护之服务熔断与降级
大道至简，悟在天成。
07-29 425
学习这篇请先学习 SpringBoot架构演进之SpringCloud集成eureka构建高可用项目 https://blog.csdn.net/qq_17025903/article/details/89471494 SpringCloud Eureka 服务治理 https://blog.csdn.net/qq_17025903/article/details/91394686 Sp...
Spring Cloud Hystrix服务容错 （Feign调用方式）
07-18 615
spring cloud 小白，又来总结一些牛人的博客内容了，首先我们今天来谈谈spring cloud hystrix断路器功能，这片文章主要讲解，spring cloud hystrix断路器集成feign client来进行访问。 Hystrix 断路器： 在分布式环境中，一个服务可能会依赖很多其他的服务，并且这些服务都不可避免地有失效的可能。Hystrix通过隔离服务之间的访问点，阻止...
Hystrix实现容错
06-02
客户端整合Hystrix实现容错，通过简单地配置，为系统保驾护航
（三）Hystrix服务容错处理
admin_15082037343的博客
07-05 179
Hystrix：可以简单认为是，服务的调用者（消费者）调用服务提供者提供的服务时的异常处理。 Feign整合Hystrix服务容错 基本环境 参考：https://blog.csdn.net/admin_15082037343/article/details/107071725 Fallback方式 demo-client添加依赖 <dependency> <groupId>org.springframework.cloud</groupId> &
Hystrix服务容错保护
yudian1991的博客
06-19 254
Hystrix接口超时容断和服务降级
sbc(五)Hystrix-服务容错与保护
weixin_33948416的博客
09-21 150
1 前言 看过 应用限流的朋友应该知道，限流的根本目的就是为了保障服务的高可用。 本次再借助SpringCloud中的集成的Hystrix组件来谈谈服务容错。 其实产生某项需求的原因都是为了解决某个需求。当我们将应用进行分布式模块部署之后,各个模块之间通过远程调用的方式进行交互(RPC)。拿我们平时最常见的下单买商品来说，点击下单按钮的一瞬间可能会向发送的请求包含： 请求订单系统创建订单。 请求...
Spring Cloud Hystrix 服务容错保护的原理实现
08-25
Spring Cloud Hystrix 服务容错保护的原理实现 Spring Cloud Hystrix 服务容错保护的原理实现主要介绍了Spring Cloud Hystrix 服务容错保护的原理实现。Hystrix 是Netflix 中的一个组件库，它隔离了服务之间的访问...
基于Spring Cloud的Hystrix服务容错保护库设计与源码解析
最新发布
09-27
本项目深入探讨了基于Spring Cloud架构的Hystrix服务容错保护库的设计与源码解析。项目包含48个文件，涵盖15个Java源文件、11个XML配置文件、7个PNG图片文件、4个Git忽略文件、3个JAR包文件、3个属性文件以及3个YAML...
spring cloud hystrix 服务容错保护例子
06-26
Spring Cloud Hystrix 是一个非常重要的组件，它为微服务架构提供了服务容错保护，确保了系统的稳定性和高可用性。这个例子展示了如何在Spring Cloud环境中集成Hystrix来实现服务熔断和降级策略。 首先，`spring-...
SpringCloud服务容错保护(Hystrix)介绍与使用示例
07-16
SpringCloud服务容错保护(Hystrix)介绍与使用示例 在微服务架构中，一个服务可能会调用很多的其他微服务应用，虽然做了多集群部署，但可能还会存在诸如网络原因或者服务提供者自身处理的原因，或多或少都会出现请求失败或者请求延迟问题，若服务提供者长期未对请求做出回应，服务消费者又不断的请求下，可能就会造成服务提供者服务崩溃，进而服务消费者也一起跟着不可用，严重的时候就发生了系统雪崩了。鉴于此，产生了断路器等一系列的服务保护机制。本章节，就来说下如何利用Hystrix进行容错处理。
Hystrix原理与实战
08-15 201
Hystrix原理与实战 背景 分布式系统环境下，服务间类似依赖非常常见，一个业务调用通常依赖多个基础服务。 比如：订单服务调用商品服务，商品服务调用库存服务。 对于同步调用，当库存服务不可用时，商品服务请求线程被阻塞，当有大批量请求调用库存服务时，最终可能导致整个商品服务资源耗尽，无法继续对外提供服务。并且这种不可用可能沿请求调用链向上传递，这种现象被称为雪崩效应。 初探Hy...
四、Spring Cloud实现微服务- 熔断机制
chuxue1989的专栏
06-23 1495
1. 熔断机制介绍 在介绍熔断机制之前，我们需要了解微服务的雪崩效应。在微服务架构中，微服务是完成一个单一的业务功能，这样做的好处是可以做到解耦，每个微服务可以独立演进。但是，一个应用可能会有多个微服务组成，微服务之间的数据交互通过远程过程调用完成。这就带来一个问题，假设微服务A调用微服务B和微服务C，微服务B和微服务C又调用其它的微服务，这就是所谓的“扇出”。如果扇出的链路上某个微服务的调用响...
使用Hystrix实现微服务的容错处理(一)
安澜公子的博客
07-21 643
使用Hystrix实现微服务的容错处理(一) 为什么要有微服务容错处理 在实际使用过程中可能会遇到这样的情况，如果某个服务的提供者响应非常慢，那服务的消费者请求服务提供者就会产生超时的情况。如果不做处理，可能导致消费者的资源消耗，甚至拖垮整个系统。以之前的用户和电影为例，电影微服务从用户微服务获取用户信息，假如此时用户微服务网络很微弱，电影微服务在请求用户信息时就会进入一种卡死状态，此时如果消费者...
Spring Cloud Hystrix：服务容错保护
weixin_42907150的博客
01-27 1044
Spring Cloud Hystrix 是Spring Cloud Netflix 子项目的核心组件之一，具有服务容错及线程隔离等一系列服务保护功能，本文将对其用法进行详细介绍。在微服务架构中，服务与服务之间通过远程调用的方式进行通信，一旦某个被调用的服务发生了故障，其依赖服务也会发生故障，此时就会发生故障的蔓延，最终导致系统瘫痪。
微服务架构-雪崩效应
追寻---专栏
08-29 253
微服务化产品线，每一个服务专心于自己的业务逻辑，并对外提供相应的接口，看上去似乎很明了，其实还有很多的东西需要考虑，比如：服务的自动扩充，熔断和限流等，随着业务的扩展，服务的数量也会随之增多，逻辑会更加复杂，一个服务的某个逻辑需要依赖多个其他服务才能完成。一但一个依赖不能提供服务很可能会产生雪崩效应，最后导致整个服务不可访问。 微服务之间进行rpc或者http调用时，我们一般都会设置调用超时，失败重试等机制来确保服务的成功执行，看上去很美，如果不考虑服务的熔断和限流，就是雪崩的源头。 假设我们有两个访问量比
Hystrix容错处理
weixin_30474613的博客
07-11 125
如果服务提供者响应非常缓慢，那么消费者对提供者的请求就会被强制等待，直接提供者响应或超时。在高负载场景下，如果不做任何处理，此类问题可能会导致服务消费者的资源耗竭甚至整个系统的崩溃。这时，就需要进行容错处理 雪崩效应： ”基础服务故障“导致”级联故障“的现象称为雪崩效应。雪崩效应描述的是提供者不可用导致消费者不可能，并将不可用逐渐放大的过程。 如图，A作...
hystrix服务容错
zengqingfa123的博客
02-18 416
hystrix 解决问题： 在微服务架构中多层服务之间会相互调用，如果其中有一层服务故障了，可能会导致一层服务或者多层服务 故障，从而导致整个系统故障。这种现象被称为服务雪崩效应。 一、 Hystrix断路器简介 Hystrix是一个实现了超时机制和断路器模式的工具类库。 Hystrix是有Netflix开源的一个延迟和容错库，用于隔离访问远程系统、服务或第三方库，防止级联失败，从而提升系统的可用性和容错性。 1、hystrix 容错机制 1.1 包裹请求： 使用HystrixCommand包裹对依赖的调用
【5.服务容错保护库Hystrix】
qq_32828749的博客
11-07 465
服务器容错保护库Hystrix
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值