Hystrix

為什麼要學習Hystrix呢？

在高併發領域，在分散式系統中，可能因為一個小小的功能扛不住壓力，宕機了，導致其他服務也跟隨宕機，最終導致整個系統宕機，所以在SpringCloud中採用Hystrix進行處理。

簡介

Hystrix，即熔斷器。

主頁：https://github.com/Netflix/Hystrix/

Hystrix是Netflix開源的一個延遲和容錯庫，用於隔離訪問遠端服務、第三方庫，防止出現級聯失敗。

熔斷器的工作機制：

正常工作的情況下，客戶端請求呼叫服務API介面：

當有服務出現異常時，直接進行失敗回滾，服務降級處理：

這就好比去買魚，平常超市買魚會額外贈送殺魚的服務。等到逢年過節，超市繁忙時，可能就不提供殺魚服務了，這就是服務的降級。

系統特別繁忙時，一些次要服務暫時中斷，優先保證主要服務的暢通，一切資源優先讓給主要服務來使用，在雙十一、618時，京東天貓都會採用這樣的策略。

動手實踐

引入依賴
首先在user-consumer（服務消費者）中引入Hystix依賴：

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

開啟熔斷

改造消費者
我們改造user-consumer，新增一個用來訪問的user服務的DAO，並且宣告一個失敗時的回滾處理函式：

@Component
public class UserDao {

    @Autowired
    private RestTemplate restTemplate;

    @HystrixCommand(fallbackMethod = "queryUserByIdFallback")
    public User queryUserById(Long id){
        long begin = System.currentTimeMillis();
        String url = "http://user-service/user/" + id;
        User user = this.restTemplate.getForObject(url, User.class);
        long end = System.currentTimeMillis();
        // 記錄訪問用時：
        System.out.println("訪問用時：{}", end - begin);
        return user;
    }

    public User queryUserByIdFallback(Long id){
        User user = new User();
        user.setId(id);
        user.setName("使用者資訊查詢出現異常！");
        return user;
    }
}
 

• @HystrixCommand(fallbackMethod="queryUserByIdFallback")：宣告一個失敗回滾處理函式queryUserByIdFallback，當queryUserById執行超時（預設是1000毫秒），就會執行fallback函式，返回錯誤提示。
• 為了方便檢視熔斷的觸發時機，我們記錄請求訪問時間。

在原來的業務邏輯中呼叫這個DAO：

@Service
public class UserService {

    @Autowired
    private UserDao userDao;

    public List<User> queryUserByIds(List<Long> ids) {
        List<User> users = new ArrayList<>();
        ids.forEach(id -> {
            // 我們測試多次查詢，
            users.add(this.userDao.queryUserById(id));
        });
        return users;
    }
}

改造服務提供者

@Service
public class UserService {

    @Autowired
    private UserMapper userMapper;

    public User queryById(Long id) throws InterruptedException {
        // 為了演示超時現象，我們在這裡然執行緒休眠,時間隨機 0~2000毫秒
        Thread.sleep(new Random().nextInt(2000));
        return this.userMapper.selectByPrimaryKey(id);
    }
}

啟動測試
然後執行並檢視日誌：

id為9、10、11的訪問時間分別是：

id為12的訪問時間：

因此，只有12是正常訪問，其它都會觸發熔斷，我們來檢視結果：

優化
雖然熔斷實現了，但是我們的重試機制似乎沒有生效，是這樣嗎？

其實這裡是因為我們的Ribbon超時時間設定的是1000ms:

而Hystix的超時時間預設也是1000ms，因此重試機制沒有被觸發，而是先觸發了熔斷。

所以，Ribbon的超時時間一定要小於Hystix的超時時間。

我們可以通過hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds來設定Hystrix超時時間。

hystrix:
  command:
  	default:
        execution:
          isolation:
            thread:
              timeoutInMilliseconds: 6000 # 設定hystrix的超時時間為6000ms