初次认识服务容错保护——Hystrix

最新推荐文章于 2024-06-01 17:32:26 发布

田野里的稻草人

最新推荐文章于 2024-06-01 17:32:26 发布

阅读量1k

点赞数 1

分类专栏：微服务架构文章标签： spring cloud 微服务

本文链接：https://blog.csdn.net/qq_25447799/article/details/123436238

版权

微服务架构专栏收录该内容

14 篇文章 5 订阅

订阅专栏

文章目录

Hystrix服务降级
依赖隔离
断路器
Hystrix监控面板
Hystrix监控数据聚合
- 通过HTTP收集聚合
- 通过消息代理收集聚合
Hystrix降级逻辑中如何获取触发的异常

待补：https://blog.didispace.com/spring-cloud-starter-dalston-2-2/

Hystrix服务降级

概述

Hystrix用于服务降级（fallback），服务熔断（break），服务限流（flowlimit），服务隔离，还有一个近实时的监控。

hystrix既可以隔离依赖服务的调用，还提供了准实时的调用监控（Hystrix Dashboard），Hystrix会持续地记录所有通过Hystrix发起的请求的执行信息，并图表展示，包括每秒执行了多少请求，多少成功，多少失败等。

快速入门

准备两个工程：

eureka-server工程：服务注册中心，端口：1001
eureka-client工程：服务提供者，两个实例启动端口分别为2001
复制一下之前实现的一个服务消费者：eureka-consumer-ribbon，命名为eureka-consumer-ribbon-hystrix。下面我们开始对其进行改在：
第一步，导入依赖：

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

第二步，编写启动类，开启注解支持。【可以使用@EnableCircuitBreaker【服务端的】或@EnableHystrix【客户端的】开启Hystrix注解支持】

@EnableCircuitBreaker
@EnableDiscoveryClient
@SpringBootApplication
public class Application {
	@Bean
	@LoadBalanced
	public RestTemplate restTemplate() {
		return new RestTemplate();
	}
	public static void main(String[] args) {
		new SpringApplicationBuilder(Application.class).web(true).run(args);
	}
}

注意：这里我们还可以使用Spring Cloud应用中的@SpringCloudApplication注解来修饰应用主类，该注解的具体定义如下所示。我们可以看到该注解中包含了上我们所引用的三个注解，这也意味着一个Spring Cloud标准应用应包含服务发现以及断路器。

@Target({ElementType.TYPE})
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Inherited
@SpringBootApplication
@EnableDiscoveryClient
@EnableCircuitBreaker
public @interface SpringCloudApplication {
}

第三步：改造服务消费方式，新增ConsumerService类，然后将在Controller中的逻辑迁移过去。最后，在为具体执行逻辑的函数上增加@HystrixCommand注解来指定服务降级方法，比如：

@RestController
public class DcController {
    @Autowired
    ConsumerService consumerService;
    @GetMapping("/consumer")
    public String dc() {
        return consumerService.consumer();
    }
    @Service
    class ConsumerService {
        @Autowired
        RestTemplate restTemplate;
        @HystrixCommand(fallbackMethod = "fallback")
        public String consumer() {
            return restTemplate.getForObject("http://eureka-client/dc", String.class);
        }
        public String fallback() {
            return "fallback";
        }
    }
}

下面我们来验证一下上面Hystrix带来的一些基础功能。我们先把涉及的服务都启动起来，然后访问localhost:2101/consumer，此时可以获取正常的返回，比如：Services: [eureka-consumer-ribbon-hystrix, eureka-client]。
为了触发服务降级逻辑，我们可以将服务提供者eureka-client的逻辑加一些延迟，比如：

@GetMapping("/dc")
public String dc() throws InterruptedException {
    Thread.sleep(5000L);
    String services = "Services: " + discoveryClient.getServices();
    System.out.println(services);
    return services;
}

重启eureka-client之后，再尝试访问localhost:2101/consumer，此时我们将获得的返回结果为：fallback。我们从eureka-client的控制台中，可以看到服务提供方输出了原本要返回的结果，但是由于返回前延迟了5秒，而服务消费方触发了服务请求超时异常，服务消费者就通过HystrixCommand注解中指定的降级逻辑进行执行，因此该请求的结果返回了fallback。这样的机制，对自身服务起到了基础的保护，同时还为异常情况提供了自动的服务降级切换机制。

依赖隔离

Hystrix则使用“舱壁模式”实现线程池的隔离，它会为每一个Hystrix命令创建一个独立的线程池，这样就算某个在Hystrix命令包装下的依赖服务出现延迟过高的情况，也只是对该依赖服务的调用产生影响，而不会拖慢其他的服务。
使用了@HystrixCommand来将某个函数包装成了Hystrix命令，这里除了定义服务降级之外，Hystrix框架就会自动的为这个函数实现调用的隔离。依赖隔离、服务降级在使用时候都是一体化实现的.

断路器

当我们把服务提供者eureka-client中加入了模拟的时间延迟之后，在服务消费端的服务降级逻辑因为hystrix命令调用依赖服务超时，触发了降级逻辑，但是即使这样，受限于Hystrix超时时间的问题，我们的调用依然很有可能产生堆积。

这个时候断路器就会发挥作用，那么断路器是在什么情况下开始起作用呢？这里涉及到断路器的三个重要参数：快照时间窗、请求总数下限、错误百分比下限。这个参数的作用分别是：

快照时间窗：断路器确定是否打开需要统计一些请求和错误数据，而统计的时间范围就是快照时间窗，默认为最近的10秒。
请求总数下限：在快照时间窗内，必须满足请求总数下限才有资格根据熔断。默认为20，意味着在10秒内，如果该hystrix命令的调用此时不足20次，即使所有的请求都超时或其他原因失败，断路器都不会打开。
错误百分比下限：当请求总数在快照时间窗内超过了下限，比如发生了30次调用，如果在这30次调用中，有16次发生了超时异常，也就是超过50%的错误百分比，在默认设定50%下限情况下，这时候就会将断路器打开。

那么当断路器打开之后会发生什么呢？
我们先来说说断路器未打开之前，对于之前那个示例的情况就是每个请求都会在当hystrix超时之后返回fallback，每个请求时间延迟就是近似hystrix的超时时间，如果设置为5秒，那么每个请求就都要延迟5秒才会返回。当熔断器在10秒内发现请求总数超过20，并且错误百分比超过50%，这个时候熔断器打开。打开之后，再有请求调用的时候，将不会调用主逻辑，而是直接调用降级逻辑，这个时候就不会等待5秒之后才返回fallback。通过断路器，实现了自动地发现错误并将降级逻辑切换为主逻辑，减少响应延迟的效果。

在断路器打开之后，处理逻辑并没有结束，我们的降级逻辑已经被成了主逻辑，那么原来的主逻辑要如何恢复呢？
对于这一问题，hystrix也为我们实现了自动恢复功能。当断路器打开，对主逻辑进行熔断之后，hystrix会启动一个休眠时间窗，在这个时间窗内，降级逻辑是临时的成为主逻辑，当休眠时间窗到期，断路器将进入半开状态，释放一次请求到原来的主逻辑上，如果此次请求正常返回，那么断路器将继续闭合，主逻辑恢复，如果这次请求依然有问题，断路器继续进入打开状态，休眠时间窗重新计时。

Hystrix监控面板

准备：

eureka-server：服务注册中心
eureka-client：服务提供者
eureka-consumer-ribbon-hystrix：使用ribbon和hystrix实现的服务消费者

由于eureka-consumer-ribbon-hystrix项目中的/consumer接口实现使用了@HystrixCommand修饰，所以这个接口的调用情况会被Hystrix记录下来，以用来给断路器和Hystrix Dashboard使用。

构建一个Hystrix Dashboard

创建一个标准的Spring Boot工程，命名为：hystrix-dashboard。
导入依赖：

<dependencies>
	<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>
	<dependency>
		<groupId>org.springframework.boot</groupId>
		<artifactId>spring-boot-starter-actuator</artifactId>
	</dependency>
</dependencies>

为应用主类加上@EnableHystrixDashboard，启用Hystrix Dashboard功能。

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

根据实际情况修改application.properties配置文件，比如：选择一个未被占用的端口等，此步非必须。

spring.application.name=hystrix-dashboard
server.port=1301

到这里我们已经完成了基本配置，接下来我们可以启动该应用，并访问：http://localhost:1301/hystrix，我们可以看到如下页面：
在这里插入图片描述

Delay：该参数用来控制服务器上轮询监控信息的延迟时间，默认为2000毫秒，我们可以通过配置该属性来降低客户端的网络和CPU消耗。
Title：该参数对应了上图头部标题Hystrix Stream之后的内容，默认会使用具体监控实例的URL，我们可以通过配置该信息来展示更合适的标题。

这是Hystrix Dashboard的监控首页，该页面中并没有具体的监控信息。从页面的文字内容中我们可以知道，Hystrix Dashboard共支持三种不同的监控方式，依次为：

默认的集群监控：通过URLhttp://turbine-hostname:port/turbine.stream开启，实现对默认集群的监控。
指定的集群监控：通过URLhttp://turbine-hostname:port/turbine.stream?cluster=[clusterName]开启，实现对clusterName集群的监控。
单体应用的监控：通过URLhttp://hystrix-app:port/hystrix.stream开启，实现对具体某个服务实例的监控。

既然Hystrix Dashboard监控单实例节点需要通过访问实例的/hystrix.stream接口来实现，自然我们需要为服务实例添加这个端点，而添加该功能的步骤也同样简单，只需要下面两步：

在服务实例pom.xml中的dependencies节点中新增spring-boot-starter-actuator监控模块以开启监控相关的端点，并确保已经引入断路器的依赖spring-cloud-starter-hystrix：

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

确保服务的主启动类已经使用@EnableCircuitBreaker或@EnableHystrix注解，开启了断路器功能。
到这里已经完成了所有的配置，我们可以在Hystrix Dashboard的首页输入http://localhost:2101/hystrix.stream，已启动对“eureka-consumer-ribbon-hystrix”的监控，点击“Monitor Stream”按钮，此时我们可以看到如下页面：
实心圆：共有两种含义。它通过颜色的变化代表了实例的健康程度，如下图所示，它的健康度从绿色、黄色、橙色、红色递减。该实心圆除了颜色的变化之外，它的大小也会根据实例的请求流量发生变化，流量越大该实心圆就越大。所以通过该实心圆的展示，我们就可以在大量的实例中快速的发现故障实例和高压力实例。
曲线：用来记录2分钟内流量的相对变化，我们可以通过它来观察到流量的上升和下降趋势。

Hystrix监控数据聚合

在介绍使用Turbine之前，我们先来回顾一下单体应用的监控：
在这里插入图片描述
其中，我们构建的内容包括：

eureka-server：服务注册中心
eureka-client：服务提供者
eureka-consumer-ribbon-hystrix：使用ribbon和hystrix实现的服务消费者
hystrix-dashboard：用于展示eureka-consumer-ribbon-hystrix服务的Hystrix数据

下面，我们将在上述架构基础上，引入Turbine来对服务的Hystrix数据进行聚合展示。这里我们将分别介绍两种聚合方式。

通过HTTP收集聚合

具体实现步骤如下：

创建一个标准的Spring Boot工程，命名为：turbine。
编辑pom.xml，具体依赖内容如下：

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

创建应用主类TurbineApplication，并使用@EnableTurbine注解开启Turbine

@Configuration
@EnableAutoConfiguration
@EnableTurbine
@EnableDiscoveryClient
@SpringBootApplication
public class TurbineApplication {
	public static void main(String[] args) {
		SpringApplication.run(TurbineApplication.class, args);
	}
}

在application.properties加入eureka和turbine的相关配置，具体如下：

spring.application.name=turbine
server.port=8989
management.port=8990
eureka.client.serviceUrl.defaultZone=http://localhost:1001/eureka/
turbine.app-config=eureka-consumer-ribbon-hystrix
turbine.cluster-name-expression="default"
turbine.combine-host-port=true

参数说明

turbine.app-config参数指定了需要收集监控信息的服务名；
turbine.cluster-name-expression 参数指定了集群名称为default，当我们服务数量非常多的时候，可以启动多个Turbine服务来构建不同的聚合集群，而该参数可以用来区分这些不同的聚合集群，同时该参数值可以在Hystrix仪表盘中用来定位不同的聚合集群，只需要在Hystrix Stream的URL中通过cluster参数来指定；
turbine.combine-host-port参数设置为true，可以让同一主机上的服务通过主机名与端口号的组合来进行区分，默认情况下会以host来区分不同的服务，这会使得在本地调试的时候，本机上的不同服务聚合成一个服务来统计。
此时的架构如下图所示

通过消息代理收集聚合

Spring Cloud在封装Turbine的时候，还实现了基于消息代理的收集实现。所以，我们可以将所有需要收集的监控信息都输出到消息代理中，然后Turbine服务再从消息代理中异步的获取这些监控信息，最后将这些监控信息聚合并输出到Hystrix Dashboard中。通过引入消息代理，我们的Turbine和Hystrix Dashoard实现的监控架构可以改成如下图所示的结构：
在这里插入图片描述

这里多了一个重要元素：RabbitMQ。

构建一个新的应用来实现基于消息代理的Turbine聚合服务，具体步骤如下：

创建一个标准的Spring Boot工程，命名为：turbine-amqp。
编辑pom.xml，具体依赖内容如下：

 <parent>
	<groupId>org.springframework.cloud</groupId>
	<artifactId>spring-cloud-starter-parent</artifactId>
	<version>Dalston.SR1</version>
	<relativePath /> <!-- lookup parent from repository -->
</parent>
<dependencies>
	<dependency>
		<groupId>org.springframework.cloud</groupId>
		<artifactId>spring-cloud-starter-turbine-amqp</artifactId>
	</dependency>
	<dependency>
		<groupId>org.springframework.boot</groupId>
		<artifactId>spring-boot-starter-actuator</artifactId>
	</dependency>
</dependencies>

这里主要引入了spring-cloud-starter-turbine-amqp依赖，它实际上就是包装了spring-cloud-starter-turbine-stream和spring-cloud-starter-stream-rabbit。

在应用主类中使用@EnableTurbineStream注解来启用Turbine Stream的配置。

@Configuration
@EnableAutoConfiguration
@EnableTurbineStream
@EnableDiscoveryClient
public class TurbineApplication {

	public static void main(String[] args) {
		SpringApplication.run(TurbineApplication.class, args);
	}

}

配置application.properties文件：

spring.application.name=turbine-amqp

server.port=8989
management.port=8990


eureka.client.serviceUrl.defaultZone=http://localhost:1001/eureka/

对于Turbine的配置已经完成了，下面我们需要对服务消费者eureka-consumer-ribbon-hystrix做一些修改，使其**监控信息能够输出到RabbitMQ上。**这个修改也非常简单，只需要在pom.xml中增加对spring-cloud-netflix-hystrix-amqp依赖，具体如下：

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

在完成了上面的配置之后，我们可以继续之前的所有项目（除turbine以外），并通过Hystrix Dashboard开启对http://localhost:8989/turbine.stream的监控，我们可以获得如之前实现的同样效果，只是这里我们的监控信息收集时是通过了消息代理异步实现的。

Hystrix降级逻辑中如何获取触发的异常

两种方式，一种是加注解，另一种是继承。
1、加@HystrixCommand注解

@HystrixCommand(fallbackMethod = "fallback")
User getUserById(String id) {
    throw new RuntimeException("getUserById command failed");
}
User fallback(String id, Throwable throwable) {
    return new User("def", "def");
}

这里定义了一个主逻辑函数getUserById，主逻辑中会主动抛出一个异常，从而触发该主逻辑的降级函数fallback。重点看fallback函数中的最后一个传参Throwable throwable。通过这样的简单定义，开发人员就可以很方便的获取触发降级逻辑的异常信息，用作日志记录或者其它复杂的业务逻辑了。
2、继承
在使用继承方式的时候通过getFailedExecutionException方法就可以获取到触发降级的异常信息了

public static class UserCommand extends HystrixCommand<User> {
    protected UserCommand() {
        super(HystrixCommandGroupKey.Factory.asKey("UserCommand"));
    }
    @Override
    protected User run() throws Exception {
        throw new RuntimeException("getUserById command failed");
    }
    @Override
    protected User getFallback() {
        System.out.println(getFailedExecutionException().getMessage());
        return new User("def", "def");
    }
}