Hystrix 企业级应用避坑指南

1. 前言

各位同学，学到这里呢，已经是 Hystrix 本套课程的最后一篇了，在本节中，我将结合我在工作中经常遇到的问题，以及在使用 Hystrix 时经常出现的问题，为大家做一个简单的避坑指南，各位同学通过学习本节内容，在实际工作中可能会少走一些弯路。

本节主要内容：

• Hystrix 常见坑介绍与解决方法；

• Hystrix 企业级应用使用技巧。

2. Hystrix 常见坑介绍与解决方法

2.1 关于参数配置的坑

我们在 Spring Cloud 中使用 Hystrix 时，一般会通过 HystrixCommand 注解去配置我们的 Hystrix 的各个配置参数，这个坑就出现在我们对线程池隔离所配置时，由于我们把线程池隔离的属性的值都设置为了 1 ，导致配置有时候不会生效，详见下方代码：

threadPoolProperties = {
        @HystrixProperty(name = "coreSize", value = "1"),
        @HystrixProperty(name = "maxQueueSize", value = "1"),
        @HystrixProperty(name = "queueSizeRejectionThreshold", value = "1")
}

如果像上述代码段中那样进行配置，那么 threadPoolProperties 就不会生效，所以，各位同学在编码的时候，可以适当把上述参数的值设置的大一些，比如将上述参数的值都扩大 10 倍：

threadPoolProperties = {
        @HystrixProperty(name = "coreSize", value = "10"),
        @HystrixProperty(name = "maxQueueSize", value = "10"),
        @HystrixProperty(name = "queueSizeRejectionThreshold", value = "10")
}

设置成这样的话，无论怎么测试，threadPoolProterties 都是生效的。

2.2 关于回调方法的坑

当我们在项目中需要使用 Hystrix 的服务容错或降级时，我们需要配置 fallbackMethod 属性，将该属性的值声明为我们的备用方法。这个坑就出现在我们的原方法与备用方法中间，如果我们的原方法中的参数类型和参数个数与备用方法中的不同，那么当发生服务容错或降级时，就会报下述异常：

 fallback method wasn't found

我们来看一下正确的配置原方法与备用方法的代码：

@RequestMapping("temp.do")
@ResponseBody
@HystrixCommand(fallbackMethod = "temp_failed")
public CommonResponse<String> temp(String msg, int code){
    return tempService.temp(msg, code);
}
    
public CommonResponse<String> temp_failed(String msg, int code){
    return  CommonResponse.errorResponse("服务拒绝处理，请联系系统管理员");
}

通过上述代码段，我们可以看到，temp 方法与 temp_failed 方法的参数类型与参数个数是相同的，这样我们的服务容错与降级才能配置生效。

2.3 关于 Hystrix 调用无效的坑

当我们在项目间互相调用服务时，有时候会出现请求无法执行或请求没有响应的情况，这个坑是由于 Hystrix 的超时时间引起的，如果我们没有给 Hystrix 配置一个超时时间，那么 Hystrix 默认的超时时间会很短，很容易会造成服务间互相调用失败。

针对于这种情况，我们只需要手动的去配置 Hystrix 的超时时间，如下代码所示：

hystrix:
  threadpool:
    default:
      coreSize: 200 
      maxQueueSize: 200 
      queueSizeRejectionThreshold: 50 
      execution:
        timeout:
          enabled: true
        isolation:
          strategy: THREAD
          semaphore:
            maxConcurrentRequests: 1000
          thread:
            timeoutInMilliseconds: 30000
  command:
    default:
      execution:
        timeout:
          enabled: true
        isolation:
          thread:
            timeoutInMilliseconds: 5000

各位同学只需要知道各种请求超时参数如何进行配置就行了。

3. Hystrix 企业级应用使用技巧

3.1 关于微服务监控平台

技巧 1

如果我们的微服务监控平台没有任何数据，或者说，在打开微服务平台之后，各参数一直处于 loading 状态，这个时候，我们只需要在服务端调用任意一个服务接口即可，这样在微服务监控平台，我们就能看到被监控实例的参数了。

技巧 2

如果我们在访问 /actuator/hystrix.stream 路径时，系统找不到对应的路径，即报 404 异常，那么我们需要在对应项目的启动类中添加一个 Bean ：

@Bean
public ServletRegistrationBean hystrixMetricsStreamServlet() {
    ServletRegistrationBean registration = new ServletRegistrationBean(new HystrixMetricsStreamServlet());
    registration.addUrlMappings("/hystrix.stream");
    return registration;
}

这样我们就能正常访问 /actuator/hystrix.stream 下的路径了。

3.2 关于 Hystrix 高可用

在真实项目中，我们的微服务项目往往都是由 2 个及以上的服务模块所构成，这样一来，如果我们的服务只有一个 Hystrix 节点，那么在洪峰到来时，很有可能我们的这一个 Hystrix 节点会挂掉，所以我们需要在项目中对 Hystrix 配置一个最少 2 个节点的高可用集群。

这里由于篇幅限制，我说一下实现的思路：

我们保证默认的一个 Hystrix 节点不动，然后在另一个服务中引入 Hystrix 的依赖，即将 Hystrix 引入到另一个服务中，然后我们需要将两个 Hystrix 服务全部注册到 Eureka 上，在注册到 Eureka 上后，我们需要配置默认的 Hystrix 节点与另一个 Hystrix 节点间的相互引用，即配置两个服务间的相互引用。

在相互引用配置完毕后，我们需要在具体使用 Hystrix 的接口中添加 Hystrix 的注解配置项，这样，我们就实现了一个具有 2 个节点的 Hystrix 高可用集群。

4. 小结

本小节为大家介绍了，Hystrix 这款微服务治理中间件在企业级应用时，经常遇到的一些坑，包括 Hystrix 参数配置、回调方法等常见问题，并针对这些问题都给出了相应的解决方案。在介绍常见问题的同时，结合我的实际工作经历，给大家介绍了 Hystrix 的微服务监控平台，已经高可用实现方案，希望各位同学能够运用到真实项目中去。

本套课程就到这里了，希望同学们学的开心，码的快乐。最后，感谢各位同学的支持与关注，江湖路远，我们有缘再会！