《Spring Cloud微服务架构实战》--集群保护机制--Hystrix

6.1概述

在很多系统架构中都需要考虑横向扩展、单点故障等问题,对于一个庞大的应用集群，部分服务或者机器出现问题不可避免。在出现故障时，如何减少故障的影响、保障集群的高可用，成为一个重要的课题。

在微服务集群中，不管是服务器，还是客户端，都支持集群部署，本章将讲述Spring Cloud中所使用的集群保护框架：Hystrix。

6.1.1实际问题

假设有一个应用程序，调用关系如图6-1所示

图6-1中用户访问服务A模块，服务通过Web接口或者其他方式访问基础服务模块, 基础服务模块访问数据库。

如果数据库因为某些原因变得不可用，基础服务将会得到“数据库无法访问”的信息，并且会将此信息告知服务A模块。

在出现问题时，用户不断地请求服务A模块，而服务A 模块则继续请求基础服务模块，基础服务模块仍然不停地连接有问题的数据库直到超时，大量的用户请求（包括重试的请求）会发送过来，整个应用不堪重负。

实际情况可能更加糟糕，用户的请求不停地发送给服务A模块，而由于数据库的原因，基础服务模块退迟无法响应，有可能造成整个机房的网络阻塞，受害的不仅仅是该应用程序，机房中的所有服务都有可能因为网络原因而瘫痪。

6.1.2传统的解决方式

　　对于前面遇到的实际问题，可以选择在连接数据库时加上超时的配置，让基础服务模块快速响应。但这仅仅算是解决了其中一种情况，在实际情况中，基础服务模块有可能出现问题，

例如部分线程阻塞、进程假死等，在这些情况下，对外的服务A模块面对大量的用户与有故障的基础服务模块，仍然无法独善其身，前面所说的问题依然会出现。

　　笔者曾就职于某电影院售票系统供应商，在某一年的春节档期，几大互联网巨头发起了观影优惠活动，大量的用户请求涌入我们中心端的系统。由于其中某些服务节点(Tomcat) 处理缓慢，很多重试、新接入的请求不断访问我们的服务。

在这个时候，传说中的“人肉运维”出现了，值班的运维同事，通过手工重启Tomcat来试图缓解这种情况，然而挣扎了几个小时后，以失败告终。

最终，整个集群网络阻塞，不得不停止对外服务，公司损失惨重。

在这件事过后，公司方面加强了对服务节点的监控，加入了故障报告、紧急故障处理等机制，期望能减少或者避免这些问题所带来的影响。

在当今的互联网时代，面对大量的用户请求，传统或者单一的解决方式在复杂的集群面前显得有点力不从心，我们需要更优雅而且更完善的方案来解决这些问题。

6.1.3集群容错框架Hystrix

　　在分布式环境中，总会有一些被依赖的服务会失效，例如像网络短暂无法访问、服务器宕机等情况。

　　Hystrix是Netflix下的一个Java库，Spring Cloud将Hystrix整合到Netflix 项目中，Hystrix通过添加延迟阈值以及容错的逻辑，来帮助我们控制分布式系统间组件的交互。

Hystrix通过隔离服务间的访问点、停止它们之间的级联故障、提供可回退操作来实现容错。

例如我们前面所讲到的问题，如果数据库层面出现问题，服务A模块在访问基础模块时必定会出现超时的情况，此时可以将基础模块隔离开来，服务A在短时间内不再调用基础模块，并且快速响应用户的请求，

　　从而保证服务A自身乃至整个集群的稳定性，这是 Hystrix可以解决的问题。加入容错机制，当出现前面所说的问题时，原来的应用程序将变为图6-2所示的结构。

如图6-2所示，当前基础服务模块或者数据库不可用时，服务A将对其进行“熔断”, 在一定的时间内，服务A都不会再调用基础服务，以维持本身的稳定。

图6-2加入容错机制

　　除了服务间的依赖会导致整个集群不可用外,在其他情况下，我们同样需要集群容错。假设集群中存在30个服务，每个服务在99.99%的时间内是正常运行的，计算下来，整个集群在99.7%的时间内是正常运行的。

如果该集群接受10亿次请求，那么将会有300万次请求会失败。在现实中，情况可能更加严重，每个服务有99.99%的正常服务时间，已经是一个很乐观的数字。

　　网络连接失败、超时，服务器硬件故障，部署引起的问题，应用程序的bug,所有这些情况都可能会出现，不能因为单点故障而降低整个集群的可用性，容错机制变得尤为重要。

6.1.4 Hystrix 的功能

Hystrix主要实现以下功能：

当所依赖的网络服务发生延迟或者失败时，对访问的客户端程序进行保护，就像前面例子中对服务A模块进行保护一样。
在分布式系统中，停止级联故障。
网络服务恢复正常后，可以快速恢复客户端的访问能力。
调用失败时执行服务回退。
可支持实时监控、报警和其他操作。

接下来，我们将讲述Hystrix的相关功能。

6.2 第一个Hystrix程序

　　先编写一个简单的Hello World程序，展示Hystrix的基本功能。注意：6.2节与6.3节， Hystrix均没有与Spring Cloud整合使用

6.2.1 准备工作

使用Spring Boot的spring-boot-starter-web项目，建立一个普通的Web项目，发布两个测试服务用于测试，控制器的代码请见代码：

@RestController
public class MyController {
　　@GetMapping("/normalHello")
　　public String normalHello(HttpServletRequest request) {
　　　　return "Hello World";
　　}

　　@GetMapping("/errorHello")
　　public String errorHello(HttpServletRequest request) throws Exception {
　　　　//模拟需要处理10秒
　　　　Thread.sleep (10000);
　　　　return "Error Hello World";
　　}
}

　　一个正常的服务，另外一个服务则需要等待10秒才有返回。本例的Web项目对应的代码目录为 codes\06\6.2\first-hystrix-server,启动类是 Server Application _o

6.2.2客户端使用Hystrix

结合Hystrix来请求Web服务,可能与原来的方式不太一样。新建项目first-hystrix-client, 在pom.xml中加入以下依赖：


　　com.netflix.hystrix
　　hystrix-core
　　l.5.12


　　org.slf4j
　　l.7.25
　　slf4j-log4j12


　　commons-logging
　　commons-logging
　　l.2


　　org.apache.httpcomponents
　　httpclient
　　4.5.2

　　本书Spring Cloud所使用的Hystrix的版本为1.5.12,我们也使用与其一致的版本。客户端项目除了要使用Hystrix夕卜，还会使用HttpClient模块访问Web服务，因此要加入相应的依赖。

新建一个命令类，实现请见代码:

public class HelloCommand extends HystrixCommand {

　　private String url;
　　CloseableHttpClient httpclient;

　　public HelloCommand(String url) {
　　　　//调用父类的构造器，设置命令组的key,默认用来作为线程池的key
　　　　super(HystrixCommandGroupKey.Factory.asKey("ExampleGroup"));
　　　　// 创建 HttpClient客户端
　　　　this.httpclient = HttpClients.createDefault(); 
　　　　this.url = url;
　　}

　　protected String run() throws Exception {
　　　　try {
　　　　　　//调用GET方法请求服务
　　　　　　HttpGet httpget = new HttpGet(url);
　　　　　　//得到服务响应
　　　　　　HttpResponse response = httpclient.execute(httpget); //解析并返回命令执行结果
　　　　　　return EntityUtils.toString(response.getEntity());
　　　　} catch (Exception e) (
　　　　　　e.printStackTrace();
　　　　}
　　　　return "";
　　}
}

　　新建运行类，执行HelloCommand,如代码清单6-3所示:

public class HelloMain {
　　public static void main(String[] args) {
　　　　//请求正常的服务
　　　　String normalUrl = "http://localhost:8080/normalHello";
　　　　HelloCommand command = new HelioCommand(normalUrl);
　　　　String result = command.execute(); 
　　　　System.out.printin("请求正常的服务，结果：" + result);
　　}
}

正常情况下，直接调用HttpClient的API来请求Web服务，而前面的命令类与运行类则通过命令来执行调用的工作。在命令类HelloCommand中，实现了父类的run方法，使用HttpClient调用服务的过程，都放到了该方法中。

运行HelloMain类，可以看到，结果与平常调用Web服务无异。接下来，测试使用Hystrix的情况下调用有问题的服务。

6.2.3调用错误服务

假设我们所调用的Hello服务发生故障，导致无法正常访问，那么对于客户端来说, 如何自保呢？本例将调用延时的服务，为客户端设置回退方法。

修改HelloCommand类, 加入回退方法，请见代码清单6-4。

protected String getFallback () {
　　System.out.printIn("执行 HelloCommand 的回退方法");
　　return "error";
}

在运行类中，调用发生故障的服务，请见代码:

public class HelloErrorMain {
　　public static void main(String[] args) {
　　　　//请求异常的服务
　　　　String normalUrl = "http://localhost:8080/errorHello";
　　　　HelloCommand command = new HelloCommand(normalUrl);
　　　　String result = command.execute();
　　　　System.out.printin ("请求异常的服务,结果："+ result);
　　}
}

运行HelloErrorMain类，输出如下：

执行HelloCommand的回退方法
请求异常的服务，结果：error

　　根据结果可知，回退方法被执行。本例中调用的errorHello服务，会阻塞10秒才有返回。默认情况下，如果调用的Web服务无法在1秒内完成，那么将会触发回退。

回退更像是一个备胎，当请求的服务无法正常返回时，就调用该“备胎”的实现。这样做可以很好地保护客户端，服务端所提供的服务受网络等条件的制约，如果有服务真的需要10秒才能返回结果，

　　而客户端又没有容错机制，后果就是，客户端将一直等待返回，直到网络超时或者服务有响应，而外界会一直不停地发送请求给客户端，最终导致的结果就是，客户端因请求过多而瘫痪。

6.2.4 Hystrix的运作流程

　　在前面的例子中，使用Hystrix时仅仅创建命令并予以执行。看似简单，实际上，Hystrix 有一套较为复杂的执行逻辑，为了能让大家大致了解该执行过程，笔者将整个流程进行了简化。

Hystrix的运作流程请见图6-3。

简单说明一下运作流程。

第一步：在命令开始执行时，会做一些准备工作，例如为命令创建相应的线程池(后面章节讲述)等。
第二步：判断是否打开了缓存，打开了缓存就直接查找缓存并返回结果。
第三步：判断断路器是否打开，如果打开了，就表示链路不可用，直接执行回退方法。结合本章开头的例子，可理解为基础服务模块不可用，服务A模块直接执行回退，响应用户请求。
第四步：判断线程池、信号量（计数器）等条件，例如像线程池超负荷，则执行回退方法，否则，就去执行命令的内容（例如前面例子中的调用服务）。
第五步：执行命令，计算是否要对断路器进行处理，执行完成后，如果满足一定条件，则需要开启断路器。如果执行成功，则返回结果，反之则执行回退。

整个流程最主要的地方在于断路器是否被打开，后面会讲解断路器的相关内容。我们的客户端在使用Hystrix时，表面上只是创建了一个命令来执行，实际上Hystrix已经为客户端添加了几层保护。

图6-3所示的流程图对Hystrix的运作流程做了最简单的描述，对于部分细节，在此不进行讲述，读者大致了解运作流程即可

6.3 Hystrix的使用

本节将详细讲述Hystrix的使用方法

6.3.1 命令执行

在前面的例子中，使用了 execute方法执行命令，一个命令对象可以使用以下方法来执行命令。

toObservable：返回一个最原始的可观察的实例(Observable) , Observable 是 RxJava 的类，使用该对象可以观察命令的执行过程，并且将执行信息传递给订阅者。
observe:调用toObservable方法，获得一个原始的Observable实例后，使用 ReplaySubject作为原始Observable的订阅者。
queue：通过toObservable方法获取原始的Observable实例，再调用Observable的 toBlocking 方法得到一个 BlockingObservable 实例，最后调用 BlockingObservable 的 toFuture方法返回Future实例，调用Future的get方法得到执行结果。
execute：调用queue的get方法返回命令的执行结果，该方法同步执行。

以上4个方法，除execute方法外，其他方法均为异步执行。observe与toObservable 方法的区别在于，toObservable被调用后，命令不会立即执行，只有当返回的Observable 实例被订阅后，才会真正执行命令。

而在observe方法的实现中，会调用toObservable得到 Observable实例，再对其进行订阅，因此调用observe方法后会立即执行命令(异步)。代码清单6-6使用了 4个执行命令的方法。

public class RunTest {
　　public static void main(String[] args) throws Exception {
　　　　//使用execute方法
　　　　RunCommand cl = new RunCommand ("使用 execute 方法执行命令")；
　　　　cl.execute();
　　　　//使用queue方法
　　　　RunCommand c2 = new RunCommand ("使用 queue 方法执行命令")；
　　　　c2.queue();
　　　　//使用observe方法
　　　　RunCommand c3 = new RunCorranand ("使用 observe 方法执行命令")；
　　　　c3.observe();
　　　　// 使用 toObservable 方法
　　　　RunCommand c4 = new RunCommand ("使用 toObservable 方法执行命令")； 
　　　　//调用toObservable方法后，命令不会马上执行
　　　　Observable ob = c4.toObservable ();
　　　　//进行订阅，此时会执行命令
　　　　ob.subscribe(new Observer() {
　　　　　　public void onCompleted() {
　　　　　　　　System.out.printIn ("命令执行完成")；
　　　　　　}

　　　　　　public void onError(Throwable e) {
　　　　　　}
　　　　　　public void onNext(String t) {
　　　　　　　　System, out .printin (n	命令执行结果："+ t);
　　　　　　}
　　　　})；
　　　　Thread.sleep(100);
　　}

　　//测试命令
　　static class RunCommand extends HystrixCommand {
　　　　String msg;
　　　　public RunCommand(String msg) (
　　　　　　super(HystrixCommandGroupKey.Factory.asKey("ExampleGroup")); 
　　　　　　this.msg = msg;
　　　　}
　　　　protected String run() throws Exception {
　　　　　　System.out.printIn(msg);
　　　　　　return "success";
　　　　}
　　}
}

对于4个执行命令的方法，读者需要知道toObservable与observe方法的区别，这两个方法将会在Spring Cloud中使用。

6.3.2属性配置

　　使用Hystrix时，可以为命令设置属性，以下的代码片断为一个命令设置了执行的超时时间：

public MyCommand(boolean isTimeout) {
　　super(
　　　　Setter.withGroupKey(HystrixCommandGroupKey.Factory.asKey("ExampleGroup"))
　　　　　　.andCommandPropertiesDefaults(HystrixCommandProperties.Setter()
　　　　　　.withExecutionTimeoutlnMilliseconds(500))
　　)；
}

　　以上的配置仅对该命令生效，设置了命令的超时时间为500毫秒。

该配置项的默认值为1秒，如果想对全局生效，可以使用以下代码片断：

ConfigurationManager
.getConfiglnstance()
.setProperty("hystrix.command.default.execution.isolation.thread.timeoutlnMilliseconds", 500);

以上代码片断同样设置了命令超时时间为500毫秒，但对全局有效。除了超时的配置外，还需要了解一下命令的相关名称，可以为命令设置以下名称。

命令组名称(GroupKey):必须提供命令组名称，默认情况下，全局维护的线程池 Map以该值作为key,该Map的value为执行命令的线程池。
命令名称(CommandKey):可选参数。
线程池名称(ThreadPoolKey):指定了线程的key后，全局维护的线程池Map将以该值作为key。

以下的代码片断分别设置以上的3个Key：

public RunCommand(String msg) {
　　super(
　　　　Setter.withGroupKey(HystrixCommandGroupKey.Factory.asKey("group-key"))
　　　　　　　　.andCommandKey (HystrixCommandKey.Factory.asKey("command-key"))
　　　　　　　　.andThreadPoolKey(HystrixThreadPoolKey.Factory.asKey("pool-key”))
　　)；
}

Hystrix的配置众多，后面章节的案例中会涉及部分配置。读者如果想了解更多配置, 可到以下地址査看 https://github.com/Netflix/Hystrix/wiki/Configurationo

6.3.3 回退

根据6.2节的流程图可知，至少会有3种情况触发回退(fallback)：

断路器被打开。
线程池、队列、信号量满载。
实际执行命令失败。

在命令中实现父类(HystrixCommand)的getFal!back()方法，即可实现回退。当以上情况发生时，将会执行回退方法。在前面的例子中已经展示了 “执行命令失败”的回退，

下面测试一下断路器被打开时的回退，详情请见代码:

public class FallbackTest {
　　public static void main(String[] args) {
　　　　//断路器被强制打开
　　　　ConfigurationManager.getConfiglnstance() .setProperty(
　　　　　　　　"hystrix.command.default.circuitBreaker.forceOpen", "true");
　　　　FallbackCommand c = new FallbackCommand();
　　　　c.execute ();
　　　　//创建第二个命令，断路器关闭
　　　　ConfigurationManager.getConfiglnstance().setProperty(
　　　　　　　　"hystrix.command.default.circuitBreaker.forceOpen", "false");
　　　　FallbackCommand c2 = new FallbackCommand();
　　　　c2.execute();
　　}

　　static class FallbackCommand extends HystrixCommand {
　　　　public FallbackCommand() (
　　　　　　super(HystrixCommandGroupKey.Factory.asKey("ExampleGroup"));
　　　　}
　　　　/**
　　　　 * 断路器被强制打开，该方法不会执行
　　　　 */
　　　　protected String run () throws Exception {
　　　　　　System.out.printin("命令执行");
　　　　　　return "";
　　　　}
　　　　/**
　　　　 * 回退方法，断路器打开后会执行回退
　　　　 */
　　　　protected String getFallback() {
　　　　　　System.out.printIn(”执行回退方法”)；
　　　　　　return "fallback";
　　　　}
　　}
}

如果让断路器打开，需要符合一定的条件。本例为了简单起见，在代码清单中使用了配置管理类(ConfigurationManager)将断路器强制打开与关闭。在打开断路器后， FallbackCommand总会执行回退(getFallback)方法将断路器关闭，命令执行正常。

如果断路器被打开，而命令中没有提供回退方法，将抛出以下异常：

com.netflix.hystrix.exception.HystrixRuntimeException: Fallbackcommand short-circuited and no fallback available.

　　另外，需要注意的是，命令执行后，不管是否会触发回退，都会去计算整个链路的健康状况，根据健康状况来判断是否要打开断路器。

如果命令仅仅失败了一次，是不足以打开断路器的，关于断路器的逻辑将在后面章节讲述。

6.3.4回退的模式

　　Hystrix的回退机制比较灵活，你可以在A命令的回退方法中执行B命令，如果B命令也执行失败，同样也会触发B命令的回退，这样就形成一种链式的命令执行，例如以下代码片断：

static class CommandA extends HystrixCommand { ……省略其他代码
　　protected String run() throws Exception {
　　　　throw new RuntimeException();
　　)
　　protected String getFallback() {
　　　　return new CommandB().execute();
　　}
}

还有其他较为复杂的例子，例如银行转账。假设一个转账命令包含调用A银行扣款、 B银行加款两个命令，其中一个命令失败后，执行转账命令的回退，如图6-4所示。

要做到图6-4所示的多命令只执行一次回退的效果，CommandA与CommandB不能有回退方法。如果CommandA命令执行失败，并且该命令有回退方法，此时将不会执行 MainCommand的回退方法。

除了上面所提到的链式的回退以及多命令回退，读者还可以根据实际情况来设计回退。

6.3.5断路器开启

断路器一旦开启，就会直接调用回退方法，不再执行命令，而且也不会更新链路的健康状况。断路器的开启要满足两个条件：

整个链路达到一定阈值，默认情况下，10秒内产生超过20次请求，则符合第一个条件。

满足第一个条件的情况下，如果请求的错误百分比大于阈值，则会打开断路器，默认为50%

Hystrix的逻辑是先判断是否满足第一个条件，再判断是否满足第二个条件。如果两个条件都满足，则开启断路器。断路器开启的测试代码请见代码清单6-8。

public class OpenTest {
　　public static void main(String[] args) throws Exception {
　　　　// 10秒内有10个请求，则符合第一个条件
　　　　ConfigurationManager.getConfiglnstance().setProperty(
　　　　　　　　"hystrix. command. default. metrics. rollings tats. timelnMilliseconds ”，10000); 
　　　　ConfigurationManager.getConfiglnstance().setProperty(
　　　　　　　　"hystrix. command. default. circuitBreaker. requestVolumeThreshold" , 10); 
　　　　ConfigurationManager.getConfiglnstance().setProperty(
　　　　　　　　"hystrix.command.default.circuitBreaker.errorThresholdPercentage”，50);

　　　　for(int i = 0; i < 15; i++) {
　　　　　　//执行的命令全部都会超时
　　　　　　MyCommand c = new MyCommand();
　　　　　　c.execute();
　　　　　　//断路器打开后输岀信息
　　　　　　if(c.isCircuitBreakerOpen()) {
　　　　　　　　System, out. printin (n断路器被打开，执行第"+ (i + 1) + ”个命令”)；
　　　　　　)
　　　　}
　　}

　　/**
　　 * 模拟超时的命令
　　 * @author杨恩雄
　　 */
　　static class MyCommand extends HystrixCommand {
　　　　//设置超时的时间为500毫秒
　　　　public MyCommand() {
　　　　　　super(Setter.withGroupKey(HystrixCommandGroupKey.Factory.asKey("ExampleGroup"))
　　　　　　　　　　　　.andCommandPropertiesDefaults(HystrixCommandProperties.Setter()
　　　　　　　　　　　　.withExecutionTimeoutInMilliseconds(500))
　　　　　　)；
　　　　}

　　　　protected String run() throws Exception {
　　　　　　//模拟处理超时
　　　　　　Thread.sleep(800); 
　　　　　　return "";
　　　　}

　　　　@Override
　　　　protected String getFallback() {
　　　　　　return "";
　　　　}
　　}
}

　　注意代码清单6-8中的三个配置，第一个配置了数据统计的时间，第二个配置了请求的阈值，第三个配置了错误百分比。

如果在10秒内，有大于10个请求发生，并且请求的错误率超过50%,则开启断路器。

　　在命令类MyCommand中，设置了命令执行的超时时间为500毫秒，命令执行需要800毫秒，换言之，该命令总会超时，命令模拟了现实环境中所依赖的服务瘫痪(超时响应) 的情况。

　　在运行类中，循环15次执行命令，调用isCircuitBreakerOpen方法，如果断路器打开，则输出信息。运行代码清单6-8所示的OpenTest类，输出如下：

断路器被打开，执行第11个命令
断路器被打开，执行第12个命令
断路器被打开，执行第13个命令
断路器被打开，执行第14个命令
断路器被打开，执行第15个命令

根据结果可知，前面执行的10个命令没有开启断路器，而到了第11个命令，断路器被打开，命令不再执行。

6.3.6断路器关闭

　　断路器打开后，在一段时间内，命令不会再执行(一直触发回退)，这段时间我们称作 “休眠期”。休眠期的默认值为5秒，休眠期结束后，Hystrix会尝试性地执行一次命令，

此时断路器的状态不是开启，也不是关闭，而是一个半开的状态，如果这一次命令执行成功，则会关闭断路器并清空链路的健康信息；

如果执行失败，断路器会继续保持打开的状态。断路器的打开与关闭测试，请见代码：

public class CloseTest {
　　public static void main(String[] args) throws Exception {
　　　　// 10秒内有3个请求就满足第一个开启断路器的条件
　　　　ConfigurationManager.getConfiglnstance().setProperty(
　　　　　　　　　　"hystrix.command.default.metrics.rollingStats.timelnMilliseconds", 10000); 
　　　　ConfigurationManager.getConfiglnstance().setProperty(
　　　　　　　　　　"hystrix.command.default.circuitBreaker.requestVolumeThreshold", 3); 
　　　　//请求的失败率，默认值为50%
　　　　ConfigurationManager.getConfiglnstance().setProperty(
　　　　　　　　　　"hystrix.command.default.circuitBreaker.errorThresholdPercentage", 50); 
　　　　//设置休眠期，断路器打开后，这段时间不会再执行命令，默认值为5秒，此处设置为3秒 
　　　　ConfigurationManager.getConfiglnstance().setProperty(
　　　　　　　　　　"hystrix.command.default.circuitBreaker.sleepWindowInMi1liseconds" , 3000); 


　　　　//该值决定是否执行超时
　　　　boolean isTimeout = true;
　　　　for(int i = 0; i < 10; i++) (
　　　　　　//执行的命令全部都会超时
　　　　　　MyCommand c = new MyCommand(isTimeout);
　　　　　　c.execute();
　　　　　　//输出健康状态等信息 
　　　　　　Healthcounts he = c.getMetrics().getHealthCounts(); 
　　　　　　System.out.printIn("断路器状态："+ c. isCircuitBreakerOpen () +",请求总数：n + hc.getTotalRequests ());
　　　　　　if(c.isCircuitBreakerOpen()) {
　　　　　　　　//断路器打开，让下一次循环成功执行命令
　　　　　　　　isTimeout = false;
　　　　　　　　System.out.printIn (" =====断路器打开了，等待休眠期结束====")；
　　　　　　　　//休眠期会在3秒后结束，此处等待4秒，确保休眠期结束
　　　　　　　　Thread.sleep(4000);
　　　　　　}
　　　　}
}

　　/**
　　 * 模拟超时的命令
　　 * @author杨恩雄
　　 */
　　static class MyCommand extends HystrixCominand {
　　　　private boolean isTimeout;
　　　　//设置超时的时间为500毫秒
　　　　public MyCommand(boolean isTimeout) {
　　　　　　super(
　　　　　　　　Setter.withGroupKey(HystrixCommandGroupKey.Factory.asKey("ExampleGroup"))
　　　　　　　　　　　　.andCommandPropertiesDefaults(HystrixCommandProperties.Setter()
　　　　　　　　　　　　.withExecutionTimeoutInMilliseconds(500))
　　　　　　)；
　　　　　　this.isTimeout = isTimeout;
　　　　}

　　　　protected String run () throws Exception {
　　　　　　//让外部决定是否超时
　　　　　　if(isTimeout) (
　　　　　　　　//模拟处理超时
　　　　　　　　Thread.sleep(800);
　　　　　　} else {
　　　　　　　　Thread.sleep(200);
　　　　　　}
　　　　　　return "";
　　　　}

　　　　@Override
　　　　protected String getFallback() {
　　　　　　return "";
　　　　}
　　}
}

　　代码清单中配置了休眠期为3秒，循环10次，创建10个命令并执行。在执行完第4 个命令后，断路器会被打开，此时我们等待休眠期结束，让下一次循环的命令执行成功。

代码清单中使用了一个布尔值来决定是否执行成功，第5次命令会执行成功，此时断路器将会被关闭，剩下的命令全部都可以正常执行。在循环体中，使用了 HealthCounts对象，该对象用于记录链路的健康信息。

如果断路器关闭（链路恢复健康），HealthCounts里面的健康信息将会被重置。运行代码清单6-9,效果如下：

断路器状态：false,请求总数：0
断路器状态：false,请求总数：1
断路器状态：false,请求总数：2
断路器状态：true,请求总数：3
=====断路器打开了，等待休眠期结束 =====
断路器状态：false,请求总数：0 断路器状态：false,请求总数：1 断路器状态：false,请求总数：1 断路器状态：false,请求总数：3
断路器状态：false,请求总数：3
断路器状态：false,请求总数：5

6.3.7隔离机制

　　命令的真正执行，除了断路器要关闭外，还需要再过一关：执行命令的线程池或者信号量是否满载。如果满载，命令就不会执行，而是直接触发回退，这样的机制，在控制命令的执行上，实现了错误的隔离。

Hystrix提供了两种隔离策略:

THREAD：默认值，由线程池来决定命令的执行，如线程池满载，则不会执行命令。 Hystrix使用了 ThreadPoolExecutor来控制线程池行为，线程池的默认大小为10。
SEMAPHORE：由信号量来决定命令的执行，当请求的并发数高于阈值时，就不再执行命令。相对于线程策略，信号量策略开销更小，但是该策略不支持超时以及异步，除非对调用的服务有足够的信任，否则不建议使用该策略进行隔离。

接下来，使用代码测试线程隔离与信号隔离两个策略，编写共用的命令类，请见代码:

public class MyCommand extends HystrixCommand {
　　int index;
　　public MyCommand(int index) {
　　　　super(Setter.withGroupKey(HystrixCommandGroupKey.Factory.asKey("ExampleGroup")));
　　　　this.index = index;
　　}

　　protected String run() throws Exception {
　　　　Thread.sleep(500);
　　　　System.out.printIn("执行方法，当前索引："+ index);
　　　　return "";
　　}

　　@Override
　　protected String getFallback() (
　　　　System.out.printIn("执行 fallback,当前索弓|： " + index);
　　　　return "";
　　}
}

编写线程隔离的运行方法，请见代码:

public class Threadlso {
　　public static void main(String[] args) throws Exception {
　　　　//配置线程池大小为3
　　　　ConfigurationManager.getConfiginstance().setProperty(
　　　　　　　　"hystrix.threadpool.default.coreSize", 3);
　　　　for (int i = 0; i < 6; i++) {
　　　　　　MyCommand c = new MyCommand(i);
　　　　　　c.queue();
　　　　}
　　　　Thread.sleep(5000);
　　}
}

在使用线程隔离策略的运行类中，配置了线程池大小为3,进行6次循环，意味着有3 次命令将会触发回退，运行后可看到效果。代码清单6-12测试信号量隔离策略。

public class Semaphorelso {
　　public static void main(String[] args) throws Exception {
　　　　//配置使用信号量的策略进行隔离
　　　　ConfigurationManager.getConfiglnstance()? setProperty(
　　　　　　　　　　"hystrix.command.default.execution.isolation.strategy",
　　　  　　　　　　　　　　Executionisolationstrategy.SEMAPHORE);
　　　　//设置最大并发数，默认值为10,本例设置为2 
　　　　ConfigurationManager.getConfiglnstance().setProperty(
　　　　　　　　　　"hystrix.command.default.execution.isolation.semaphore.maxConcurrentReques",2);
　　　　//设置执行回退方法的最大并发，默认值为10,本例设置为20 
　　　　ConfigurationManager.getConfiglnstance().setProperty(
　　　　　　　　　　"hystrix.command.default.fallback.isolation.semaph ore.maxConcurrentRequests",20);

　　　　for (int i = 0; i < 6; i++) {
　　　　　　final int index = i;
　　　　　　Thread t = new Thread() (
　　　　　　　　public void run() {
　　　　　　　　　　MyCommand c = new MyCommand(index);
　　　　　　　　　　c.execute();
　　　　　　　　}
　　　　　　)
　　　　　　t.start();
　　　　}
　　　　Thread.sleep(5000);
　　}
}

注意代码中的3个配置项，指定使用信号量作为隔离策略，分别设置了命令执行的最大并发数，以及执行回退的最大并发数。

运行代码清单6-12,最终只有两个命令正常执行，其余命令都会触发回退，可见信号量隔离的相关配置生效。

线程（线程池）与信号量两种隔离策略各有优缺点，如果对于所调用的服务有足够的信任，可以使用信号量策略，以减少系统开销。

6.3.8合并请求

　　根据前面小节的介绍可知，默认情况下，会为命令分配线程池来执行命令实例，线程池会消耗一定的性能。对于一些同类型的请求（URL相同，参数不同），Hystrix提供了合并请求的功能，在一次请求的过程中，

可以将一个时间段内的相同请求（参数不同），收集到同一个命令中执行，这样就节省了线程的开销，减少了网络连接，从而提升了执行的性能。这个功能有点像数据库的批处理功能。

实现合并请求的功能，至少包含以下3个条件：

需要有一个执行请求的命令，将全部参数进行整理，然后调用外部服务。
需要有一个合并处理器，用于收集请求，以及处理结果。
外部接口提供支持，例如外部的服务提供了/person/{personName}的服务用于查找一个Person,如果合并请求，夕卜部还需要提供一个/persons的服务，用于查找多个Person=

接下来，实现一个简单的查找逻辑。假设有以下场景：客户端多次调用查找单个Person 的Web服务，而服务端提供了一个新的服务，可以传入多个名字，查找并返回多个Person 实例，此时，可以考虑使用合并请求。

编写一个命令类，用于收集请求参数以及调用服务，请见代码清单6-13。

public class CollapseTest{
　　static class CollapserCommand extends HystrixCommanci> { 
　　　　//请求集合，第一个类型是单个请求返回的数据类型，第二是请求参数的类型 
　　　　Collection> requests;

　　　　private CollapserCommand(
　　　　　　Collection　　　　　　　　super(Setter.withGroupKey(HystrixCommandGroupKey.Factory.asKey("ExampleGroup")));
　　　　　　　　this.requests = requests;
　　　　)

　　　　@Override 
　　　　protected Map run() throws Exception {
　　　　　　System.out.printin (n收集参数后执行命令，参数数量：” + requests .size ());
　　　　　　//处理参数
　　　　　　List personNames = new ArrayList();
　　　　　　for(CollapsedRequest request : requests) { 
　　　　　　　　personNames.add(request.getArgument());
　　　　　　}
　　　　　　//调用服务(此处模拟调用)，根据名称获取Person的Map
　　　　　　Map result = callservice(personNames);
　　　　　　return result;
　　　　}

　　　　//模拟服务返回
　　　　private Map callservice(List personNames) { 
　　　　　　Map result = new HashMap(); 
　　　　　　for(String personName : personNames) {
　　　　　　　　Person p = new Person();
　　　　　　　　p.id = UUID. randomUUID () .toStringO ;
　　　　　　　　p.name = personName;
　　　　　　　　p.age = new Random().nextlnt(30);
　　　　　　　　result.put(personName, p);
　　　　　　}
　　　　　　return result;
　　　　}
　　}

　　static class Person {
　　　　String id;
　　　　String name;
　　　　Integer age;
　　　　public String toString() {
　　　　　　// TODO Auto-generated method stub return "id: " + id + ”，name: '* + name + age: ” + age;
　　　　}
　　}
}

　　在命令类 CollapserCommand 中，维护着一个 CollapsedRequest 集合，一个 CollapsedRequest 实例表示一个请求，该类指定的第一个类型为“单请求返回的类型”，第二个类型为请求的参数类型。

例如，CollapsedRequest,表示单次请求将会以String作为参数，返回一个Person实例。代码清单中的粗体部分模拟调用查询多个Person的服务。

接下来，编写合并处理器，将请求进行合并，请见代码:

/**
 * 合并处理器
 * 第一个类型为批处理返回的结果类型
 * 第二个为单请求返回的结果类型
 * 第三个是请求参数类型
 * @author杨恩雄
 */
static class MyHystrixCollapser extends HystrixCollapser, Person, String> {
　　String personName;
　　public MyHystrixCollapser(String personName) {
　　　　this.personName = personName;
　　}

　　@Override
　　public String getRequestArgument() {
　　　　return personName;
　　}

　　@Override
　　protected HystrixCommand> createCommand (Collection> requests) { 
　　　　return new CollapserCommand(requests);
　　}

　　@Override
　　protected void mapResponseToRequests( Map batchResponse, Collection> requests) {
　　　　//让结果与请求进行关联
　　　　for (CollapsedRequest request : requests) {
　　　　　　//获取单个响应返回的结果
　　　　　　Person singleResult = batchResponse.get(request.getArgument()); 
　　　　　　//关联到请求中
　　　　　　request.setResponse(singleResult);
　　　　}
　　}
}

　　合并处理器中实现了父类的3个方法，getRequestArgument用于返回请求的参数，本例需要根据名称查询Person,因此该参数为字符串；

createCommand返回实际执行的命令（查找多个Person的批处理命令）；

mapResponseToRequests方法将会在返回结果后执行' 可在该方法中设置结果与请求之间的关联。

接下来，编写运行类，请见代码清单6.15。

public class CollapseTest{
  public static void main(String[] args) throws Exception {
    //收集1秒内发生的请求，合并为一个命令执行
    ConfigurationManager.getConfiglnstance().setProperty(
          "hystrix.collapser.default.timerDelaylnMilliseconds", 1000); 
    //请求上下文
    HystrixRequestContext context = HystrixRequestContext.initializeContext();
    //创建请求合并的处理器
    MyHystrixCollapser c1 = new MyHystrixCollapser("Angus");
    MyHystrixCollapser c2 = new MyHystrixCollapser("Crazyit");
    MyHystrixCollapser c3 = new MyHystrixCollapser("Sune");
    MyHystrixCollapser c4 = new MyHystrixCollapser("Paris");
    //异步执行
    Future f1 = c1.queue();
    Future f2 = c2.queue();
    Future f3 = c3.queue();
    Future f4 = c4.queue();

    System.out.printin(fl.get()); 
    System.out.printin(f2.get()); 
    System.out.printin(f3.get()); 
    System.out.printin(f4.get());
    context.shutdown();

  }
}

注意粗体部分，设置了 “时间段”，在1秒内执行的请求将会被合并到一起执行，该“时间段”的默认值为10毫秒。运行代码清单6-15,可以看到输出如下：

收集参数后执行命令，参数数量：4
id: 57821cac-d925-4a8e-9cd4-067c8171a626, 
id: 9f984af6-0e7d-41b0-96f9-941863c3e093, 
id: c8483f21-9382-436a-b01b-3aelc8ecfb68, 
id: 5514a5e4-8af6-4730-ab5c-080affcecc2e,

根据结果可知，创建了 4个合并处理器，最终只执行了 1次命令。

虽然合并请求后只执行了一个命令，只启动了一个线程，只进行了一次网络请求，但是在收集请求、合并请求、处理结果的过程中仍然会耗费一定的时间。

总的来说，一般情况下，合并请求进行批处理，比发送多个请求快，对于一些服务的URL相同、参数不同的请求,笔者推荐使用合并请求的功能。

6.3.9请求缓存

Hystrix支持缓存功能，如果在一次请求的过程中，多个地方调用同一个接口，可以考虑使用缓存。缓存打开后，下一次的命令不会执行，直接到缓存中获取响应并返回，具体可参见6.2.4节介绍的运作流程。

开启缓存较为简单，在命令中重写父类的getCacheKey即可。代码清单6-16测试开启缓存和清空缓存

public static void main(String[] args) {
　　//初始化请求上下文
　　HystrixRequestContext context = HystrixRequestContext.initializeContext(); 
　　//请求正常的服务
　　String key = "cache-key";
　　MyCommand cl = new MyCommand(key);
　　MyCommand c2 = new MyCommand(key);
　　MyCommand c3 = new MyCommand(key);
　　//输出结果
　　System.out.printIn(cl.execute() + "cl 是否读取缓存："+cl. isResponseFromCache());
　　System.out.printIn(c2.execute() + "c2 是否读取缓存："+c2.isResponseFromCache());
　　System.out.printIn(c3.execute() + "c3 是否读取缓存："+c3.isResponseFromCache());
　　//获取缓存实例
　　HystrixRequestCache cache = HystrixRequestCache.getlnstance(
　　　　HystrixCommandKey.Factory.asKey("MyCommandKey"), 
　　　　HystrixConcurrencyStrategyDefault.getlnstance());

　　//清空缓存
　　cache.clear(key);
　　//重新执行命令
　　MyCommand c4 = new MyCommand(key);
　　System.out .printIn (c4 .execute () + ”c4 是否读取缓存：*' +
　　c4.isResponseFromCache()); context.shutdown();
}

static class MyCommand extends HystrixCommand {
　　private String key;
　　public MyCommand(String key) {
　　　　super(
　　　　　　Setter.withG^oupKey(HystrixCommandGroupKey.Factory；asKey("ExampleGroup"))
　　　　　　.andCommandKey (HystrixCommandKey.Factory.asKey("MyCommandKey"))
　　　　)；
　　　　this.key = key;
　　}

　　protected String run() throws Exception {
　　　　System.out.printIn(”执行命令");
　　　　return "";
　　}

　　@Override
　　protected String getCacheKey() { 
　　　　return this.key;
　　}
}

在代码清单的运行类中，使用了同一个缓存的key来创建命令实例。注意粗体代码，使用 HystrixRequestCache 来清空缓存。获取 HystrixRequestCache 实例需要传入 CommandKey,

因此在命令的构造器中，也设置了 CommandKeyo运行代码清单6-16,输出结果如下：

执行命令
C1是否读取缓存：false
c2是否读取缓存：true
c3是否读取缓存：true
执行命令
c4是否读取缓存：false

　　根据输出结果可知，命令实际上只执行了两次，C2与C3这两个命令执行时都读取了缓存，而C4在执行前清空了缓存。

注意： 合并请求、请求缓存，在一次请求的过程中才能实现，因此需要先初始化请求上下文。

　　Hystrix的使用到此结束，下面将讲解在Spring Cloud中如何使用Hystrixo Spring Cloud对Hystrix进行了封装，我们只要懂得Hystrix的机制或者原理,

在使用Spring Cloud 的Hystrix注解时，就会变得非常轻松，也可以大概知道Spring Cloud帮我们做了哪些工作。

6.4 在 Spring Cloud 中使用 Hystrix

　　Hystrix主要用于保护调用服务的一方，如果被调用的服务发生故障，符合一定条件, 就开启断路器，对调用的程序进行隔离。在开始讲述本节的内容之前，先准备测试项目，本节中的例子所使用的项目如下所述。

spring-hystrix-server： Eureka 服务器，端口为 8761, 代码目录为 codes\06\6.4\spring- hystrix-servero
spring-hystrix-provider:服务提供者，本例只需要启动一个实例，端口为8080,默认提Wperson/{personld}服务。根据personld参数返回一个Person实例，另外再提供一个/hello服务，返回普通的字符串。

　　　　代码目录为codes\06\6.4\spring-hystrix-provider

spring-hystrix-invoker:服务调用者，端口为 9000, 代码目录为 codes\06\6.4\spring - hystrix- invoker

6.4.1 整合 Hystrix

为服务调用者(spring-hystrix-invoker)项目添加依赖，添加的依赖如下：


　　org.springframework.cloud
　　spring-cloud-starter-config


　　org.springframework.cloud
　　spring-cloud-starter-eureka


　　org.springframework.cloud
　　spring-cloud-starter-ribbon


　　org.springframework.cloud
　　spring-cloud--starter-hystrix

在服务调用者的应用启动类中，加入启用断路器的注解，请参见以下代码片断：

@SpringBootApplication
@EnableDiscoveryClient
@EnableCircuitBreaker
public class InvokerApplication {

　　@LoadBalanced
　　@Bean
　　public RestTemplate getRestTemplate() {
　　　　return new RestTemplate();
　　}

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

新建服务类，在服务方法中调用服务，请见代码:

public class PersonService {

　　@Autowired
　　private RestTemplate restTemplate;

　　@HystrixCommand(fallbackMethod = "getPersonFallback")
　　public Person getPerson(Integer id) {
　　　　// 使用 RestTemplate 调用 Eureka 服务
　　　　Person p = restTemplate.getForObj ect(
　　　　　　　　　　　　"http://spring-hystrix-provider/person/(personld}", Person.class, id);
　　　　return p;
　　}

　　/**
　　 * 回退方法，返回一个默认的Person
　　 */
　　public Person getPersonFallback(Integer id) {
　　　　Person p = new Person();
　　　　p.setld(0);
　　　　p.setName("Crazyit");
　　　　p.setAge(-1);
　　　　p.setMessage("request error");
　　　　return p;
　　}
}

　　服务类中注入了 RestTemplate,服务方法使用@HystrixCommand注解进行修饰，并且配置了回退方法。@HystrixCommand注解由Hystrix的javanica项目提供，该项目主要是为了简化 Hystrix 的使用。

被@HystrixCommand修饰的方法,Hystrix(javanica)会使用 AspectJ 对其进行代理，Spring会将相关的类转换为Bean放到容器中，在Spring Cloud中，我们无须过多关心Hystrix的命令管理。

接下来，编写控制器，调用服务类的方法，请见代码

@RestController
@Configuration
public class InvokerController {
　　@Autowired
　　private PersonService personService;

　　@RequestMapping(value = "/router/(personId}", method = RequestMethod.GET, 
　　　　　　　　　　　　　　　　produces = MediaType.APPLICATION_JSON_VALUE)
　　public Person router(@PathVariable Integer personld) {
　　　　Person p = personservice.getPerson(personld);
　　　　return p;
　　}
}

控制器的实现较为简单，直接注入PersonService,然后调用方法即可，按以下步骤启动集群：

启动 spring-hystrix-server,本例中配置端口为 8761
启动 spring-hystrix-provider,启动一个实例，端口为 8080
启动 spring-hystrix-invoker,端口为 9000

打开浏览器访问http://localhost:9000/router/l,输出如下：

("id":1,"name": '*Crazyitn,"age":33,"message":"http://localhost:8080/person/l" }

停止服务提供者(spring?hystrix?provide),即停止8080端口，再访问9000端口的地址，输出如下：

("id”：0,”name”："Crazyit","age”：-1,"message":"request error**}

根据输出可知，由于调用失败，触发了回退方法。

6.4.2命令配置

　　在Spring Cloud中使用@HystrixCommand来声明一个命令，命令的相关配置也可以在该注解中进行，

以下的代码片断配置了几个属性：

/**
 * 测试配置，对3个key进行命名
 * 设置命令执行超时时间为1000毫秒
 * 设置命令执行的线程池大小为1
 */
@HystrixCommand(
    fallbackMethod="testConfigFallback", groupKey="MyGroup", commandKey="MyCommandKey", threadPoolKey="MyCommandPool", 
　　 cominandProperties= {
　　　　　　　　@HystrixProperty(name = "execution.isolation.thread.timeoutInMilliseconds", value = "l000")
　　 },
　　 threadPoolProperties= {
　　　　　　　　@HystrixProperty(name = "coreSize", value = "1")
　　 }
)

除了以上的几个配置外，@HystrixCommand注解还可以使用ignoreExceptions来处理异常的传播，请见以下代码片断：

/**
 * 声明了忽略MyException,如果方法抛出MyException,则不会触发回退
 */
@HystrixCommand(ignoreExceptions = {MyException.class}, fallbackMethod="testExceptionFallBack")
public String testException() {
　　throw new MyException();
}

　　Hystrix的命令、线程配置较多，由于篇幅所限，本小节仅简单地列举几个，读者可举一反三，按需要进行配置。

6.4.3默认配置

对于一些默认的配置，例如命令组的key等，可以使注解，这样就减少了@HystrixCommand注解的代码量。以下代码片断展示了如何使用:

@DefaultProperties:
@DefaultProperties(groupKey="GroupPersonKey")
public class PersonService {
　　@HystrixCommanci 
　　// groupkey 将使用 GroupPersonKey
　　public String hello() {
　　　　return "";
　　}
}

　　除了定义GroupKey外，还支持@HystrixCommand的其余配置，例如线程属性、命令属性等。

6.4.4缓存注解

在6.3节中讲述了 Hystrix的缓存功能，在Spring Cloud中，同样支持使用缓存，并且可以通过注解来实现。根据前面章节的介绍可知，缓存与合并请求功能需要先初始化请求上下文才能实现。

新建一个javax.sei-vlet.Filter,用于创建与销毁Hystrix的请求上下文, 请见代码:

@WebFilter(urlPatterns = f ilterName = "hystrixFilter")
public class HystrixFilter implements Filter {
　　public void init(FilterConfig filterConfig) throws ServletException {
　　}
 
　　public void doFilter(ServletRequest request, ServletResponse response,Filterchain chain) throws lOException, ServletException {
　　　　HystrixRequestContext context = HystrixRequestContext.initializeContext();
　　　　try {
　　　　　　chain.doFilter(request, response);
　　　　} finally {
　　　　　　context.shutdown();
　　　　}
　　}

　　public void destroy() {
　　}
}

编写服务方法，使用@CacheResult注解进行修饰，请见代码：

@Component
public class CacheService {
　　@CacheResult
　　@HystrixCommand
　　public Person getPerson(Integer id) {
　　　　System.out.printIn("getPerson 方法")；
　　　　Person p = new Person();
　　　　p.setld(id);
　　　　p.setName("angus");
　　　　return p;
　　}
}

注意，在服务方法中，被调用一次就会进行一次控制台输出。在控制器的方法中，调用多次getPerson方法，控制器代码请见代码：

public class lnvokerController{

　　@RequestMapping(value = "/cachel/{personld}", method = RequestMethod.GET,
　　　　　　　　　　　　produces = MediaType.APPLICAT10N_JSON_VALUE)
　　public Person testCacheResult(@PathVariable Integer personld) {
　　　　//调用多次服务
　　　　for(int i = 0; i < 3; i++) (
　　　　　　Person p = cacheService.getPerson(personld);
　　　　　　System.out.printin("控制器调用服务"+ i);
　　　　}
　　　　return new Person();
　　}
}

控制器中调用了多次服务方法，也就是用户发送请求后，会执行多次服务方法，启动

“服务调用者”，访问以下地址http://localhost:9000/cachel/l, 控制台输岀如下：

执行getPerson方法
控制器调用服务0
控制器调用服务1
控制器调用服务2

根据输出结果可知，在一次用户请求的过程中，服务方法只执行了一次，缓存生效。

缓存的注解主要有以下3个。

@CacheResult：该注解修饰方法，表示被修饰的方法返回结果将会被缓存，需要与 @HystrixCommand —起使用。
@CacheRemove:用于修饰方法让缓存失效,需要与@CacheResult的缓存key关联。
@CacheKey：用于修饰方法参数，表示该参数作为缓存的key。

前面的例子使用了@CacheResult注解，下面的代码片断，@CacheResult 一起使用：

@CacheResult()
@HystrixCommanci(commandKey = "removeKey")
public String cacheMethod(String name) {
　　return "hello";
}

@CacheRemove (commandKey = "removeKey")
@HystrixCommand
public String updateMethod(String name) {
　　return nupdateH;
}

　　以上代码片断中的cacheMethod方法，使用的缓存key为removeKey,方法updateMethod 被调用后，将会删除key为updateMethod的缓存。

关于3个缓存注解更深入的使用，本小节不进行讲述，读者可以自行测试。

6.4.5合并请求注解

在Spring Cloud中同样支持合并请求，在一次HTTP请求的过程中，收集一段时间内的相同请求，放到一个批处理命令中执行。

实现合并请求，同样需要先初始化请求上下文，具体请参见6.4.4节中的Filter；接下来，编写服务类，请见代码清单6-22。

@Component
public class CollapseService {
　　//配置收集1秒内的请求
　　@HystrixCollapser(batchMethod = "getPersons", collapserProperties = 
　　　　　　　　　　　　　　　{
　　　　　　　　　　　　　　　　@HystrixProperty (name = "timerDelaylnMilliseconds" , value = "1000") 
　　　　　　　　　　　　　　　}
　　)
　　public Future getSinglePerson(Integer id) {
　　　　System.out .printin ("执行单个获取的方法”)；
　　　　return null;
　　} 

　　@HystrixCommand
　　public List getPersons(List ids) {
　　　　System.out.printIn("收集请求，参数数量：" + ids.size());
　　　　List ps = new ArrayList ();
　　　　for (Integer id : ids) {
　　　　　　Person p = new Person();
　　　　　　p.setld(id);
　　　　　　p.setName("crazyit");
　　　　　　ps.add(p);
　　　　} 
　　　　return ps;
　　}
}

　　在代码清单中，最后真实执行的方法为getPersons, getSinglePerson方法使用了 @HystrixCollapser注解来修饰，会收集1秒内调用getSinglePerson的请求，放到getPersons 方法中进行批处理。

控制器中多次调用getSinglePerson方法，如代码清单6-23所示。

public class lnvokerController{
　　@RequestMapping(value = "/collapse**, method = RequestMethod.GET, produces = MediaType.APPLICATION_JSON_VALUE) 
　　public String testCollapse() throws Exception {
　　　　//连续执行3次请求
　　　　Future fl = collapseService.getSinglePerson(1); 
　　　　Future f2 = collapseService.getSinglePerson(2); 
　　　　Future f3 = collapseService.getSinglePerson(3); 
　　　　Person pl = fl.get();
　　　　Person p2 = f2.get();
　　　　Person p3 = f3.get();
　　　　System.out .printIn (pl.getId () + "" + pl.getName ());

　　　　System.out.printIn(p2.getId() + " " + p2.getName());
　　　　System.out .printIn (p3 .getId () + " " + p3 .getName ()); 
　　　　return "";
　　}

}

异步执行了 3次getSinglePerson方法，启动*'月艮务调用者"，访问以下地址http://localhost: 9000/collapse,控制台输出如下：

收集请求，参数数量：3
1	crazyit
2	crazyit
3	crazyit

根据输出结果可知，最终只执行了 getPersons方法。相对于直接使用Hystrix,在Spring Cloud中合并请求较为简单，合并处理器已经由@HystrixCollapser注解帮我们实现，我们仅关心真正命令的执行即可。

6.4.6 Feign 与 Hystrix 整合

Feign对Hystrix提供了支持，为“服务调用者”加入以下Feign依赖：


　　org.springframework.cloud
　　spring-cloud-starter-feign

在application.yml中打开Feign的Hystrix开关，请见以下配置：

feign:
hystrix:	.
enabled: true

在应用启动类中加入Feign的开关，本小节的“服务调用者”应用启动类所使用的注解如下：

@SpringBootApplication

@EnableDiscoveryClient

@ Enabled rcuitBreaker

@ServletComponentScan

@EnableFeignClients

新建Feign接口，调用“服务提供者(spring-hystrix-provider)”的/hello服务，请见代码

@FeignClient (name = "spring-hystrix-provider", fallback = HelloClientFallback.class)
public interface HelloClient {
　　@RequestMapping(method = RequestMethod.GET, value = "/hello") 
　　public String hello();

　　@Component
　　static class HelloClientFallback implements HelloClient {
　　　　public String hello() {
　　　　　　System.out.printIn ("hello 方法的回退");
　　　　　　return "error hello";
　　　　}
　　}
}

与普通的Feign客户端无异，仅仅设置了处理回退的类，回退类实现了客户端接口。为了能测试效果，修改服务器端的/hello服务，让其有800毫秒的延时。

根据前面章节的介绍可知，默认情况下，Hystrix的超时时间为1秒，

因此，还需要修改超时设置。请见代码清单6-25,在application.yml中修改命令配置。

hystrix:
　　command:
　　　　HelloClient#hello():
　　　　　　execution:
　　　　　　　　isolation:
　　　　　　　　　　thread:
　　　　　　　　　　　　timeoutlnMilliseconds: 500 
　　　　　　circuitBreaker:
　　　　　　　　requestVolumeThreshold: 3

注意，如果是针对全局配置，则使用与下面类似的配置片断：

H默认时间段内发生的请求数
hystrix.command.default.circuitBreaker.requestVolumeThreshold
//超时时间
hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds
如果针对某个客户端，使用下面的配置片断：
hystrix.command.CommandKey.circuitBreaker.requestVolumeThreshold

　　Feign与Hystrix整合使用时，会自动帮我们生成CommandKey, 格式为：Feign客户端接口名#方法名()。

例如本例中的客户端为HelloClient, 方法为hello, 生成的CommandKey 为 HelloClient#hello()；而默认情况下，生成的 GroupKey 为@FeignClient 注解的 name 属性。

　　在以上的配置中，我们针对hello方法设置了超时时间为500毫秒，而/hello服务超时时间为800毫秒，换言之，hello方法总会超时。

另外，如果请求超过3次并且失败率超过 50%,断路器将被打开。编写控制器，调用hello服务，并查看断路器的情况，请见代码：

@RestController
public class HelloController {
　　@Autowired
　　HelloClient helloClient;

　　@RequestMapping(value = "/feign/hello", method = RequestMethod.GET) 
　　public String feignHello () {
　　　　// hello方法会超时
　　　　String helloResult = helloClient.hello();	1
　　　　//获取断路器
　　　　HystrixCircuitBreaker breaker = HystrixCircuitBreaker.Factory.getlnstance(
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　HystrixCommandKey.Factory.asKey("HelloClient#hello()"));
　　　　System.out.printin("断路器状态：" + breaker.isOpen());
　　　　return helloResult;
　　}
}

在控制器的方法中，获取了 hello方法的断路器，并输出其状态。接下来，编写一个测试客户端，多线程访问 http://localhost:9000/feign/hello/{index),

也就是控制器的 feignHello方法，客户端请见代码：

public class TestFeignClient {
　　public static void main(String[] args) throws Exception {
　　　　//创建默认的HttpClient
　　　　final CloseableHttpClient httpclient = HttpClients.createDefault ();
　　　　//调用多次服务并输出结果
　　　　for(int i = 0; i < 6; i++) {
　　　　　　//建立线程访问接口
　　　　　　Thread t = new Thread() {
　　　　　　　　public void run() {
　　　　　　　　　　try {
　　　　　　　　　　　　String url = "http://localhost:9000/feign/hello";
　　　　　　　　　　　　//调用GET方法请求服务
　　　　　　　　　　　　HttpGet httpget = new HttpGet(url);
　　　　　　　　　　　　//获取响应
　　　　　　　　　　　　HttpResponse response = httpclient.execute(httpget);
　　　　　　　　　　　　//根据响应解析出字符串
　　　　　　　　　　　　System.out.printin(EntityUtils.toString(response.getEntity()));
　　　　　　　　　　} catch (Exception e) {
　　　　　　　　　　　　e.printStackTrace();　　
　　　　　　　　　　}
　　　　　　　　}
　　　　　　)；
　　　　　　t.start();
　　　　}
　　　　//等待完成
　　　　Thread.sleep(15000);
　　}
}

　　完成后，依次启动Eureka服务器、服务提供者、服务调用者，运行代码清单6-27,可看到“服务调用者”的控制台输出如下：

断路器状态：false
断路器状态：false
断路器状态：false
断路器状态：false
断路器状态：true
断路器状态：true

根据输出可知，断路器己经被打开。

6.4.7 Hystrix 监控

为服务调用者加入Actuator,可以对服务调用者的健康情况进行实时监控。例如可以看到某个方法的断路器是否打开、当前负载等情况，

为服务调用者(spring-hystrix-invoker) 加入以下依赖：


　　org.springframework.boot
　　spring-boot-starter-actuator
　　l.5.3.RELEASE

重新启动 spring-hystrix-invoker (9000 端口)，访问 http://localhost:9000/hystrix.stream, 可以看到Hystrix输出的stream数据。

接下来，新建一个监控的Web项目，名称为 hystrix-dashboard,对应的代码路径为codes\06\6.4\hystrix-dashboard,

为该项目加入以下依赖：


　　org.springframework.cloud
　　spring-cloud-starter-hystrix-dashboard


　　org.springframework.cloud
　　spring-cloud-starter-hystrix


　　org.springframework.boot
　　spring-boot-starter-actuator
　　l.5.3.RELEASE

该项目的启动类代码如下：

@SpringBootApplication
@EnableHystrixDashboard
public class MyApplication {
　　public static void main(String[] args) {
　　　　//设置启动的服务器端口
　　　　new SpringApplicationBuilder(MyApplication.class).properties("server.port=8082").run(args);
　　}
}

使用了@EnableHystrixDashboard注解开启Hystrix控制台，启动的端口为8082；

完成后，启动整个集群,最后再启动监控项目，在浏览器输入以下地址http://localhost:8082/hystrix, 可以看到界面如图6.5所示

在文本框中输入需要监控的地址，本例需要监控的地址是http://localhost:9000/ hystrix.streamo单击监控按钮后，可看到界面如图所示。

如图6-6所示，名称为HelloClient#hello()的命令，断路器被打开，该命令主要用于测试Feign的断路器(请见6.4.6节)。

其他断路器状态正常，读者可以访问本节案例中的各个URL来测试这些命令的健康情况。

本节案例所监测的是单节点的健康情况，如果需要监控整个集群的情况，可以使用 Turbine框架，该框架将在后面章节中讲述。

6.5 本章小结

　　本章主要讲解了 Hystrix框架，包括Hystrix的使用、运行机制等内容。如果你希望改造旧系统，让其拥有更好的容错能力，可以学习本章的6.3节。如果你正在搭建新的项目，想让项目拥有更好的性能，

可结合Spring Cloud 一起使用Hystrix;

　　由于Spring Cloud对Hystrix的封装，使得我们平时在使用Spring Cloud时，几乎感觉不到Hystrix的存在，但在高并发的场景下，Hystrix的作用就会很明显。

　　如果能理解Hystrix 的工作原理，将会对解决实际环境中的复杂问题有很好的帮助。

book 读书笔记