前言:目前我們的項目是微服務架構,基于dubbo框架,服務之間的調用是通過rpc調用的。剛開始沒有任何問題，項目運行健康、良好。可是過了一段時間，線上總有人反應查詢訂單失敗，等過了一段時間才能查到。這是怎么回事呢?打開后臺的日志一看出現了一些rpcexception和timeoutexception,原來是遠程調用超時了，可能某個服務在請求的高發期訪問數據庫異常，io阻塞,返回接口異常了。后來這個問題越來越頻繁，如何解決這個棘手的問題呢？
一：hystrix是什么？
1.1:基本解釋
hystrix最開始由netflix(看過美劇的都知道,它是一個美劇影視制作的巨頭公司)開源的，后來由spring cloud hystrix基于這款框架實現了斷路器、線程隔離等一系列服務保護功能,該框架的目標在于通過控制訪問遠程系統、服務和第三方庫的節點，從而延遲和故障提供更強大的容錯能力。hystrix具備服務降級、服務熔斷、線程和信號隔離、請求緩存、請求合并以及服務監控等強大功能。起到了微服務的保護機制,防止某個單元出現故障.從而引起依賴關系引發故障的蔓延，最終導致整個系統的癱瘓。
1.2:斷路器的概念
斷路器本身是一個開關裝置，用在電路上保護線路過載，當線路中有電器發生短路的時候。“斷路器”能夠及時切斷故障，防止發生過載、發熱甚至起火等嚴重后果。當分布式架構中，斷路器模式起到的作用也是類似的。當某個服務發生故障的時候，通過斷路器的故障監控向調用方返回一個錯誤響應，而不是長時間的線程掛機，無限等待。這樣就不會使線程因故障服務被長時間占用不釋放，避免了故障在分布式系統中的蔓延。如下圖是現實中的斷路器，它是一個開關裝置：
二：hystrix解決超時問題
2.1：問題
假設我們前端提供了用戶查詢訂單的功能，首先請求映射到ordercontroller，控制器通過調用服務orderservice獲取訂單信息，前端傳過來兩個參數：一個是訂單id,一個是用戶id,orderservice需要通過用戶id調取用戶服務來獲取用戶的相關信息返回給訂單服務去組裝信息，假設這里是通過http請求的，我們有一個單獨的工程叫做：userservice部署在其他的服務器上。但是這個服務器宕機了，這時候訂單服務調取用戶信息就失敗了，然后查詢訂單整個請求就失敗了！由一個服務的宕機就導致整個查詢都失敗了，牽一發而動全身。流程見下圖：
2.2：使用hystrix進行服務降級
2.2.1:引入hystrix依賴 這里引入了spring-cloud-starter-netflix-hystrix，springboot的starter里面整合了hystrix
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
|
<properties> <java.version>1.8</java.version> <spring-cloud.version>greenwich.sr1</spring-cloud.version> </properties> <dependencies> <dependency> <groupid>org.springframework.cloud</groupid> <artifactid>spring-cloud-starter-netflix-hystrix</artifactid> </dependency> <dependency> <groupid>org.springframework.cloud</groupid> <artifactid>spring-cloud-starter-netflix-hystrix-dashboard</artifactid> </dependency> <dependency> <groupid>cn.hutool</groupid> <artifactid>hutool-all</artifactid> <version>4.5.1</version> </dependency> <dependency> <groupid>org.springframework.boot</groupid> <artifactid>spring-boot-starter-test</artifactid> <scope>test</scope> </dependency> </dependencies> <dependencymanagement> <dependencies> <dependency> <groupid>org.springframework.cloud</groupid> <artifactid>spring-cloud-dependencies</artifactid> <version>${spring-cloud.version}</version> <type>pom</type> <scope>import</scope> </dependency> </dependencies> </dependencymanagement> |
2.2.2:模擬訂單請求
首先通過ordercontroller映射/order請求，獲取前端傳入的參數orderid和useid,然后調用orderdetailservice方法,
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
|
@restcontrollerpublic class ordercontroller { @resource private orderservice orderservice; /** * 獲取訂單信息 * * @param orderno * @return */ @postmapping("/order") public resultvo<orderdetail> getorderinfo(@requestparam("orderid") long orderno, @requestparam("userid") long userid) { orderdetail orderdetail = orderservice.orderdetailservice(orderno, userid); resultvo resultvo = new resultvo<>(); resultvo.setcode(100); resultvo.setmessage("請求成功"); resultvo.setdata(orderdetail); return resultvo; }} |
2.2.3:訂單服務調取其他服務
這里引入了resttemplate,它是一個spring封裝的http映射請求工具類，然后通過http請求訪問url = "http://192.168.80.153:8070/user/getuser"獲取用戶名，將值給訂單對象。不過假如在這其中發生了調用異常，請求用戶服務異常的話，那么返回給前端就是一串空的訂單信息，導致用戶看到的訂單為空。在使用hystrix之后，可以用@hystrixcommand(fallbackmethod = "orderfallback")注解，在fallbackmethod中指定回退的方法，這里必須注意在@hystrixcommand上的方法其指定的回調方法必須和原方法的參數保持一致，這里包括參數類型、參數個數、參數順序。我們在回調用法中模擬去查詢緩存數據，返回給訂單。有人又要問了，如果查詢緩存服務器再異常呢？不排除這種可能性。如果是這樣的話，依然可以使用@hystrixcommand注解在回調方法中，再指定其他的回調方法：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
|
@servicepublic class orderservice { @autowired private resttemplate resttemplate; /** * 根據訂單id獲取訂單詳情 * * @param orderid * @param userid * @return */ @hystrixcommand(fallbackmethod = "orderfallback") public orderdetail orderdetailservice(long orderid, long userid) { if (objects.isnull(orderid)) { return null; } orderdetail orderdetail = orderdbsource.getorderdb().get(orderid); //調用user服務 final string url = "http://192.168.80.153:8070/user/getuser"; string username = ""; responseentity<string> responseentity = resttemplate.postforentity(url, userid, string.class); string returncontent = responseentity.getbody(); if (objects.nonnull(responseentity) && strutil.isnotempty(returncontent)) { username = returncontent; } if (objectutil.isnotnull(orderdetail)){ orderdetail.setusername(username); } return orderdetail; } /** * 異常調用的回調方法 * * @return */ public orderdetail orderfallback(long orderid, long userid) { orderdetail orderdetail = orderdbsource.getordercache().get(orderid); final string unknown = "未知用戶"; orderdetail.setusername(unknown); return orderdetail; }} |
2.3.4：模擬測試
為了方便測試，首先我們將請求服務暫時先注釋，然后用postman測試看正常的返回應該是這樣的，這里使用了備注為數據庫獲取的訂單，表明它沒有走回調方法，因為這里沒有訪問用戶url獲取用戶信息，程序可以正常訪問。我再放開
加上獲取用戶服務的鏈接，實際上用戶服務是無法訪問到的，訪問的話就會超時，超時會被hystrix捕捉到，然后走fallback指定的方法，我們來測試一下，可以看到實際上走的是緩存中查詢到的訂單，可以看到用戶服務已經成功的降級了，降級后的訂單信息雖然是緩存獲取到的，可能會存在延時等問題（當然只要維護好緩存就可以避免這個問題）。但是比沒有任何數據帶來的用戶一點會更好！
三：hystrix的流程
hystrix實際上的工作原理是這樣的:通過command來解耦請求與返回操作，在具體的實例中就是，hystrix會對依賴的服務進行觀察,通過command.toobservable調用返回一個觀察的對象，同時發起一個事件，然后用subscriber對接受到的事件進行處理。在command命令發出請求后，它通過一系列的判斷，順序依次是緩存是否命中、斷路器是否打開、線程池是否占滿，然后它才會開始對我們編寫的代碼進行實際的請求依賴服務的處理，也就是hystrix.run方法，如果在這其中任一節點出現錯誤或者拋出異常，它都會返回到fallback方法進行服務降級處理，當降級處理完成之后，它會將結果返回給,際的調用者,經過一系列流程處理的，它的具體工作流程如下：
四：總結
本篇博客講述了hystrix是什么？然后解釋了hystrix如何進行服務降級處理以及簡單的處理流程,講到的內容是最為常用的功能，還有一些關于hystrix的緩存、線程池的隔離技術等由于篇幅的原因,沒有詳細的講解到，不過作為一篇入門級的hystrix教程博客是基本夠的。在實際的開發中，如何保持服務的健壯性、服務的可用性、盡量的減少bug，提升用戶體驗都是我們開發者的使命，這條優化和提升之路永遠沒有盡頭，go ahead!
參考資料《spring cloud微服務實戰》
以上就是本文的全部內容，希望對大家的學習有所幫助，也希望大家多多支持服務器之家。
