-
https://github.com/Netflix/Hystrix
-
在分布式環境中，許多服務依賴項不可避免地會失敗，Hystrix是一個庫，它通過添加延遲容忍和容錯邏輯來幫助您控制這些分布式服務之間的互動，Hystrix通過隔離服務之間的訪問點、停止它們之間的級聯故障以及提供后備選項來實作這一點，所有這些都可以提高系統的整體彈性，
-
通俗定義: Hystrix是一個用于處理分布式系統的延遲和容錯的開源庫，在分布式系統中，許多依賴不可避免的會呼叫失敗，超時、例外等，Hystrix能夠保證在一個依賴出問題的情況下，不會導致整體服務失敗，避免級聯故障(服務雪崩現象)，提高分布式系統的彈性，
1.服務雪崩
1.服務雪崩
- 在微服務之間進行服務呼叫是由于某一個服務故障，導致級聯服務故障的現象，稱為雪崩效應，雪崩效應描述的是提供方不可用，導致消費方不可用并將不可用逐漸放大的程序，
2.圖解雪崩效應
- 如存在如下呼叫鏈路:
- 而此時，Service A的流量波動很大，流量經常會突然性增加！那么在這種情況下，就算Service A能扛得住請求，Service B和Service C未必能扛得住這突發的請求，此時，如果Service C因為抗不住請求，變得不可用，那么Service B的請求也會阻塞，慢慢耗盡Service B的執行緒資源，Service B就會變得不可用，緊接著，Service A也會不可用，這一程序如下圖所示
2.服務熔斷
1.服務熔斷
- “熔斷器”本身是一種開關裝置，當某個服務單元發生故障之后，通過斷路器的故障監控，某個例外條件被觸發，直接熔斷整個服務，向呼叫方法回傳一個符合預期的、可處理的備選回應(FallBack),而不是長時間的等待或者拋出呼叫方法無法處理的例外，就保證了服務呼叫方的執行緒不會被長時間占用，避免故障在分布式系統中蔓延，乃至雪崩，如果目標服務情況好轉則恢復呼叫，服務熔斷是解決服務雪崩的重要手段，
2.服務熔斷圖示
3.服務降級
1.服務降級說明
-
服務壓力劇增的時候根據當前的業務情況及流量對一些服務和頁面有策略的降級，以此環節服務器的壓力，以保證核心任務的進行，同時保證部分甚至大部分任務客戶能得到正確的相應，也就是當前的請求處理不了了或者出錯了，給一個默認的回傳，
-
通俗: 關閉系統中邊緣服務 保證系統核心服務的正常運行 稱之為服務降級
淘寶 洗掉地址 確認識訓 洗掉訂單 取消支付 節省cpu 記憶體
4.降級和熔斷總結
1.共同點
- 目的很一致，都是從可用性可靠性著想，為防止系統的整體緩慢甚至崩潰，采用的技術手段；
- 最終表現類似，對于兩者來說，最終讓用戶體驗到的是某些功能暫時不可達或不可用；
- 粒度一般都是服務級別，當然，業界也有不少更細粒度的做法，比如做到資料持久層（允許查詢，不允許增刪改）；
- 自治性要求很高，熔斷模式一般都是服務基于策略的自動觸發，降級雖說可人工干預，但在微服務架構下，完全靠人顯然不可能，開關預置、配置中心都是必要手段；
2.異同點
- 觸發原因不太一樣，服務熔斷一般是某個服務（下游服務）故障引起，而服務降級一般是從整體負荷考慮；
- 管理目標的層次不太一樣，熔斷其實是一個框架級的處理，每個微服務都需要（無層級之分），而降級一般需要對業務有層級之分（比如降級一般是從最外圍服務開始）
3.總結
- 熔斷必會觸發降級,所以熔斷也是降級一種,區別在于熔斷是對呼叫鏈路的保護,而降級是對系統過載的一種保護處理
5.服務熔斷的實作
服務熔斷的實作思路
- 引入hystrix依賴,并開啟熔斷器(斷路器)
- 模擬降級方法
- 進行呼叫測驗
1.專案中引入hystrix依賴
在商品服務下面
<!--引入hystrix-->
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-netflix-hystrix</artifactId>
</dependency>
2.開啟斷路器
@SpringBootApplication
@EnableCircuitBreaker //用來開啟斷路器
public class Products9998Application {
public static void main(String[] args) {
SpringApplication.run(Products9998Application.class, args);
}
}
3.使用HystrixCommand注解實作斷路
//服務熔斷
@GetMapping("/product/break")
@HystrixCommand(fallbackMethod = "testBreakFall" )
public String testBreak(int id){
log.info("接收的商品id為: "+ id);
if(id<=0){
throw new RuntimeException("資料不合法!!!");
}
return "當前接收商品id: "+id;
}
// 觸發熔斷的方法
public String testBreakFall(int id){
return "當前資料不合法: "+id;
}
4.訪問測驗
- 正常引數訪問
- 錯誤引數訪問
一直使用錯誤引數訪問，那么再使用正常引數訪問也會顯示不合法，因為觸發了斷路器，但過一點時間又會自動的關閉，訪問又合法了
5.總結
- 從上面演示程序中會發現如果觸發一定條件斷路器會自動打開,過了一點時間正常之后又會關閉，那么斷路器打開條件是什么呢？
6.斷路器打開條件
- 官網: https://cloud.spring.io/spring-cloud-netflix/2.2.x/reference/html/#circuit-breaker-spring-cloud-circuit-breaker-with-hystrix
A service failure in the lower level of services can cause cascading failure all the way up to the user. When calls to a particular service exceed circuitBreaker.requestVolumeThreshold (default: 20 requests) and the failure percentage is greater than circuitBreaker.errorThresholdPercentage (default: >50%) in a rolling window defined by metrics.rollingStats.timeInMilliseconds (default: 10 seconds), the circuit opens and the call is not made. In cases of error and an open circuit, a fallback can be provided by the developer. --摘自官方
原文翻譯之后,總結打開關閉的條件:
- 1 當滿足一定的閥值的時候（默認10秒內超過20個請求次數）
- 2、當失敗率達到一定的時候（默認10秒內超過50%的請求失敗）
- 3、到達以上閥值，斷路器將會開啟
- 4、當開啟的時候，所有請求都不會進行轉發
- 5、一段時間之后（默認是5秒），這個時候斷路器是半開狀態，會讓其中一個請求進行轉發，如果成功，斷路器會關閉，若失敗，繼續開啟，重復4和5，
7.默認的服務FallBack處理方法
- 如果為每一個服務方法開發一個降級,對于我們來說,可能會出現大量的代碼的冗余,不利于維護,這個時候就需要加入默認服務降級處理方法
@GetMapping("/product/hystrix")
@HystrixCommand(defaultFallback = "testHystrixFallBack") //通過HystrixCommand降級處理 指定出錯的方法
public String testHystrix(String name) {
log.info("接收名稱為: " + name);
int n = 1/0;
return "服務[" + port + "]回應成功,當前接收名稱為:" + name;
}
//服務降級處理
public String testHystrixFallBack(String name) {
return port + "當前服務已經被降級處理!!!,接收名稱為: "+name;
}
6.服務降級的實作
還是再之前專案的基礎之上
1.客戶端openfeign + hystrix實作服務降級實作
- 引入hystrix依賴
- 組態檔開啟feign支持hystrix
- 在feign客戶端呼叫加入fallback指定降級處理
- 開發降級處理方法
2.開啟openfeign支持服務降級
feign.hystrix.enabled=true #開啟openfeign支持降級
3.在openfeign客戶端中加如Hystrix
// 創建一個ProductClientFallBack類實作這個介面，并實作這個介面的所有方法，為了對每個方法做不同的回應錯略
// 指定當前的介面是openfeign組件，value是呼叫的服務名
@FeignClient(value = "https://www.cnblogs.com/mengd/p/products",fallback = ProductClientFallBack.class)
public interface ProductClient {
@GetMapping("/product/findOne")
Map<String, Object> findOne(@RequestParam("productId") String productId);
}
4.開發fallback處理類
package com.md.fallback;
@Component
public class ProductClientFallBack implements ProductClient {
@Override
public Map<String, Object> findOne(String productId) {
HashMap<String, Object> map = new HashMap<>();
map.put("status","false");
map.put("msg","當前查詢不可以使用，服務已經被降級");
return map;
}
}
正常訪問
然后直接將產品服務關閉，再進行訪問
注意:如果服務端降級和客戶端降級同時開啟,要求服務端降級方法的回傳值必須與客戶端方法降級的回傳值一致!!!
7.Hystrix Dashboard
0.說明
- Hystrix Dashboard的一個主要優點是它收集了關于每個HystrixCommand的一組度量，Hystrix儀表板以高效的方式顯示每個斷路器的運行狀況，
只是一個有UI頁面的組件，創建一個新的專案，還是根據之前的springcloud的環境搭建
1.專案中引入依賴
<!--引入hystrix dashboard 依賴-->
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-netflix-hystrix-dashboard</artifactId>
</dependency>
2.入口類中開啟hystrix dashboard
@SpringBootApplication
@EnableHystrixDashboard //開啟監控面板
public class Hystrixdashboard9990Application {
public static void main(String[] args) {
SpringApplication.run(Hystrixdashboard9990Application.class, args);
}
}
在組態檔中指定埠號9990
3.啟動hystrix dashboard應用
- http://localhost:9990(dashboard埠)/hystrix
4.監控的專案中入口類中加入監控路徑配置[新版本坑],并啟動監控專案
@Bean
public ServletRegistrationBean getServlet() {
HystrixMetricsStreamServlet streamServlet = new HystrixMetricsStreamServlet();
ServletRegistrationBean registrationBean = new ServletRegistrationBean(streamServlet);
registrationBean.setLoadOnStartup(1);
registrationBean.addUrlMappings("/hystrix.stream");
registrationBean.setName("HystrixMetricsStreamServlet");
return registrationBean;
}
5.通過監控界面監控
后面的hystrix.stream是固定的
6.點擊監控,一致loading,打開控制臺發現報錯[特別坑]
# 解決方案
- 新版本中springcloud將jquery版本升級為3.4.1，定位到monitor.ftlh檔案中，js的寫法如下：
$(window).load(function()
- jquery 3.4.1已經廢棄上面寫法
- 修改方案 修改monitor.ftlh為如下呼叫方式：
$(window).on("load",function()
- 編譯jar源檔案，重新打包引入后，界面正常回應，
8.Hystrix停止維護
官方地址:https://github.com/Netflix/Hystrix
- 翻譯:Hystrix（版本1.5.18）足夠穩定，可以滿足Netflix對我們現有應用的需求，同時，我們的重點已經轉移到對應用程式的實時性能作出反應的更具適應性的實作，而不是預先配置的設定（例如，通過自適應并發限制），對于像Hystrix這樣的東西有意義的情況，我們打算繼續在現有的應用程式中使用Hystrix，并在新的內部專案中利用諸如resilience4j這樣的開放和活躍的專案，我們開始建議其他人也這樣做，
- Dashboard也被廢棄
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/234616.html
標籤：Java