您好,登錄后才能下訂單哦!
這期內容當中小編將會給大家帶來有關怎么在springcloud中使用Hystrix對微服務進行降級管理,文章內容豐富且以專業的角度為大家分析和敘述,閱讀完這篇文章希望大家可以有所收獲。
一: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
<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方法,
@RestController public 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注解在回調方法中,再指定其他的回調方法:
@Service public 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方法進行服務降級處理,當降級處理完成之后,它會將結果返回給,際的調用者,經過一系列流程處理的,它的具體工作流程如下:
上述就是小編為大家分享的怎么在springcloud中使用Hystrix對微服務進行降級管理了,如果剛好有類似的疑惑,不妨參照上述分析進行理解。如果想知道更多相關知識,歡迎關注億速云行業資訊頻道。
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。