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 的微服務監控平臺，已經高可用實現方案，希望各位同學能夠運用到真實項目中去。

本套課程就到這里了，希望同學們學的開心，碼的快樂。最后，感謝各位同學的支持與關注，江湖路遠，我們有緣再會！