實際業務場景下 Hystrix 資源隔離實戰

1. 前言

我們知道，服務資源隔離分為兩種實現方式，分別是基于線程池隔離的服務資源隔離、基于信號量隔離的服務資源隔離。在本節中，我將繼續為大家介紹，在真實業務場景下的，服務資源隔離的應用方法及代碼實現。

本節主要內容：

• 服務資源隔離真實業務場景描述；

• 業務場景實現思路分析與實操。

2. 服務資源隔離真實業務場景描述

業務場景描述

有這樣一個真實的業務場景：在某大廠的訂單與支付模塊，當有用戶下了訂單之后，需要在支付模塊進行支付，支付動作完成之后，支付模塊會將支付完成的結果返回給訂單模塊來通知用戶，該訂單是否支付成功，即商品是否已經成功購買了。

在微服務分布式架構模式下，上述業務場景中出現了一種異?，F象：當用戶下了訂單之后，在支付模塊進行支付時，系統一直沒有響應，無論是否成功支付，用戶都收不到任何通知信息。

程序員在排查對應的業務實現代碼時，證實了業務實現代碼沒有問題，這就導致無法定位問題所在。最終經過幾名同事一起排查，發現是訂單模塊與支付模塊之間進行數據傳輸時，支付模塊收到了訂單模塊傳遞過來的數據，但是由于服務器高壓工作，導致支付模塊始終無法處理該支付請求，這就導致系統一直沒有響應。

問題原因分析

在解決問題之前，我們首先來分析一下這種問題產生的原因。

在前面我們介紹什么是 Hystrix 資源隔離小節中，我為大家闡述了在我們的 Web 項目中，進程與線程之間的關系。我們知道，在一般情況下，一個 Web 項目中只有一個工作線程來負責處理用戶調用的請求和服務，當該工作線程所負責的請求處理緩慢時，該線程就會一直處理當前的請求，導致后續請求只能等待處理，這就是我們說的雪崩現象。

在微服務分布式架構模式下，由于我們沒有對線程進行處理，至此在處理所有業務請求時，扔是只有一個工作線程，這就導致上述業務場出現了我們所說的雪崩現象，不過還好，這種雪崩現象比較輕微，只影響到了一個業務模塊。

很多時候，當我們的項目架構演變為基于微服務的分布式架構時，服務器也需要同步進行更新，有很多企業為了節約成本，則只更新很少數量的服務器，或者壓根就不更新服務器，這就導致經常會出現由于服務器高壓工作而出現的請求處理緩慢，或請求無法繼續處理的情況。

3. 業務場景實現思路分析與實操

實現思路分析

鑒于上述業務場景中所描述的問題，我們只要為每個業務模塊分配不同的工作線程，使各模塊間不再一同共用一個工作線程，就可以有效解決上述問題。

當我們通過技術手段為每一個業務模塊都分配了不同的工作線程之后，各模塊的業務處理操作都會有專門的工作線程來完成，不會再出現各模塊共用一個工作線程的情況。如果一個模塊中的請求處理出現問題而等待，由于我們分配了不同的工作線程，所以這種情況不會影響到其他模塊，這就解決了上述業務場景中出現的問題。

Hystrix 提供了通過線程池或信號量隔離的方式來對服務資源進行隔離，以解決雪崩現象的發生，接下來讓我們分別來看一下代碼實現。

實操

以線程池隔離為例，我們先給訂單服務配置資源隔離：

@RequestMapping("make_order.do")
@ResponseBody
@HystrixCommand(threadPoolKey = "userMakeOrderThread")
public CommonResponse<String> makeOrder(@RequestBody("order")Order order, @RequestBody("user")User user){
    return orderService.makeOrder(order, user);
}

代碼解釋

第 3 行，我們用戶下訂單服務中通過添加 HystrixCommand 注解的 threadPoolKey 屬性來為用戶下訂單服務單獨分配了一個名為 userMakeOrderThread 的線程池，當我們再有用戶下訂單的請求需要處理時，就會使用這個線程池中的線程。

同樣的方法，我們為用戶支付服務配置資源隔離：

@RequestMapping("aliPay.do")
@ResponseBody
@HystrixCommand(threadPoolKey = "userAliPayThread")
public CommonResponse<String> aliPay(@RequestBody("shipping")Shipping shipping, @RequestBody("user")User user){
    return payService.aliPay(shipping, user);
}
    

可以看到，我們為支付模塊分配了一個名為 userAliPayThread 的線程池。

基于信號量隔離的服務隔離的配置，和上述基于線程池隔離的配置大同小異，下面我將關鍵代碼放到下方，各位同學只需要替換掉上述的線程池配置即可。

以用戶下訂單服務為例：

@HystrixCommand(fallbackMethod="makeOrderFailed", commandProperties = {
@HystrixProperty(name = HystrixPropertiesManager.EXECUTION_ISOLATION_STRATEGY, value = "SEMAPHORE"),
@HystrixProperty(name = HystrixPropertiesManager.EXECUTION_ISOLATION_SEMAPHORE_MAX_CONCURRENT_REQUESTS, value = "50")
})

代碼解釋

第 3- 8 行，使用信號量隔離需要顯式聲明服務資源隔離策略，SEMAPHORE 表示使用信號量隔離策略。

Tips:
1. 在實際項目開發中，像這種訂單服務和支付服務互相依賴的業務場景不在少數，各位同學在工作時，一定要在這種業務場景中配置好服務資源隔離，不要等在線上出現問題之后再解決，那就晚了;
2. 線程池隔離和信號量隔離之間的區別有很多，這里就不做介紹了，希望各位同學可以自行查閱，他們之間的區別可以幫助你確定不同業務場景下采用哪種隔離方式比較合適。

4. 小結

本小節以一個真實業務場景下的不同業務模塊間協作服務為背景，為大家介紹了如何在真實業務場景下配置 Hystrix 的服務資源隔離，并且做了代碼實操，針對容易出現問題的地方，也做了注意事項的補充，希望同學們可以對真實業務場景下，服務資源隔離的應用方法有所了解。