首先，介绍下问题：

一个plat-gateway工程，配置了Hystrix。按照通用的配置，如下验证：

@RestController
public class SelfHystrixController {
    @RequestMapping("/defaultfallback")
    public Map<String,String> defaultfallback(){
    	log.info(LogMessage.getMessage("", "请求被熔断了"));
        Map<String,String> map = new HashMap<>();
        map.put("msg","网络繁忙服务降级请稍后再访问");
        map.put("code","GW0001");
        return map;
    }

    /**
     * 发起Get 请求 ：localhost:8000/gateway/timeout
     * 会进行熔断
     * @return
     */
    @RequestMapping("/timeout")
    public String timeout(){
        try {
            Thread.sleep(15000);
        } catch (Exception e) {
            e.printStackTrace();
        }
        return "Hello, I am timeout return. If normal, you can not find me.";
    }
}

Yml配置如下：

  cloud:
    # Gateway routes config
    gateway:
      default-filters:
        - name: Hystrix
          args:
            name: fallbackcmd
            fallbackUri: forward:/defaultfallback
      routes:
        # 走 fsp 的路由
        - id: wish.plat-gateway.fsp
          uri: http://127.0.0.1:80
          order: 2
          #网关断言匹配
          predicates:
            - Path=/gateway/**
          filters:
            # - StripPrefix=4
            - FspAdapt

如上，在controller中验证是没有问题的。但是发现，在 FspAdaptGatewayFilterFactory 的过滤器中，是无法熔断。

配置 10s熔断， 在过滤器中休眠 15s，执行post请求。期望是：到10s后，主动熔断，返回前端信息。but，现实情况是，到达10秒后，继续执行，执行完后，才返回前端。此时信息是：

{
    "timestamp": "2019-10-31T00:54:57.352+0000",
    "path": "/gateway/04320/07/B70001/arrange/newBusiness/1233333",
    "status": 504,
    "error": "Gateway Timeout",
    "message": "Response took longer than configured timeout"
}

本人想过很多方案，第一：修改spring-cloud-gateway-core中的TimeoutException，为RuntimeException，这样就可以终止继续执行了。第二：自定义一个  HystrixGatewayFilterFactory 来实现该功能。但是思来想去，spring cloud hystrix不应该这样。因为根本未达到熔断的目的，猜想是对使用不够深入了解。

在这样一篇文章中，Spring Cloud Hystrix设计原理。请认真阅览，发现如下是跟我相关的描述：

如果run() 或者construct()方法 的真实执行时间超过了Command设置的超时时间阈值, 则当前则执行线程（或者是独立的定时器线程）将会抛出TimeoutException。抛出超时异常TimeoutException，后，将执行步骤8的Fallback降级处理。即使run()或者construct()执行没有被取消或中断，最终能够处理返回结果，但在降级处理逻辑中，将会抛弃run()或construct()方法的返回结果，而返回Fallback降级处理结果。

需要注意的是，Hystrix无法强制 将正在运行的线程停止掉--Hystrix能够做的最好的方式就是在JVM中抛出一个InterruptedException。如果Hystrix包装的工作不抛出中断异常InterruptedException, 则在Hystrix线程池中的线程将会继续执行，尽管调用的客户端已经接收到了TimeoutException。这种方式会使Hystrix 的线程池处于饱和状态。大部分的Java Http Client 开源库并不会解析 InterruptedException。所以确认HTTP client 相关的连接和读/写相关的超时时间设置。

3.1 断路器相关配置：
circuitBreaker.forceOpen    是否强制将断路器设置成开启状态    false

心想，这不就是说的我这种情况吗？于是觉得可以查阅http的超时或者circuitBreaker.forceOpen来试一下。

美好的事情，总会发生。增加如下配置，生效了：

#熔断相关配置            
hystrix:
  command:
    default:
      circuitBreaker:
        # 强制将断路器设置成开启状态
        forceOpen: true

此刻，整个世界都好了。等等，本以为到此结束，万万没想到。

接下来，配置  timeoutInMilliseconds: 10000 ，去掉过滤器中的休眠，打算正常测试下。结果：熔断，熔断，熔断。是的，连正常功能都不好使了，吓得我赶紧去掉了这个参数。仔细一想，这个参数是，强制熔断。so，不能随便乱用。

http请求的超时，未找到相关设置。

结论：可能与设计原理，不是很一致，因此通过配置可能无法实现。暂时搁置/自定义过滤器实现/考虑下其他方案，如Sentinel等。

不急，时间会说明一切。（未完，待续）