文章目錄
- 概述
-
- 分布式系統當中可能會面臨的問題
- 是什麼
- 官網資料
- 服務熔斷
- 服務降級
-
- 使用
- 總結
- 服務監控hystrixDashboard
-
- 官網
- 使用
-
- 7色
- 1圈
- 1線
- 整圖說明
- 搞懂一個才能看懂全套
概述
分布式系統當中可能會面臨的問題
複雜分布式系統結構中的應用程式有數十個依賴關系，每個依賴關系在某些時候将不可避免地失敗
服務雪崩
多個服務之間調用的時候，假設微服務A調用微服務B和微服務C，微服務B和微服務C又調用其它的微服務，這就是所謂的“扇出”。如果扇出的鍊路上某個微服務的調用響應時間過程或者不可用，對微服務A的調用就會占用越來越多的系統資源，進而引起系統崩潰，所謂的“雪崩效應”
扇出：A調用B，B調用C，C調用D，就像一把折扇慢慢打開，依賴的程度慢慢加深加寬。
對于高流量的應用來說，單一的後端依賴可能會導緻所有伺服器上的所有資源都在幾秒鐘内飽和，比失敗更糟糕的是，這些應用程式還可能導緻服務之間的延遲增加，備份隊列，線程和其它系統資源緊張，導緻整個系統發生更多的級聯故障。這些都表示需要對故障和延遲進行隔離和管理，以便單個依賴關系的失敗，不能取消整個應用程式或系統。
是什麼
Hystrix是一個用于處理分布式系統的延遲和容錯的開源庫，在分布式系統裡，許多依賴不可避免的會調用失敗，比如逾時、異常等，Hystrix能夠保證在一個依賴出問題的情況下，不會導緻整體服務失敗，避免級聯故障，以提高分布式系統的彈性。
“斷路器”本身是一種開關裝置，當某個服務單元發生故障之後，通過斷路器的故障監控（類似熔斷保險絲），向調用放傳回一個符合預期的、可處理的備選響應（FallBack），而不是長時間的等待或者抛出調用方無法處理的異常，這樣就保證了服務調用方的線程不會被長時間、不必要地占用，進而避免了故障在分布式系統中的蔓延，乃至雪崩
官網資料
Hystrix官網
看到Hystrix是Netflix公司下的，我們的代碼、樣例、個人的思考都可以參考Wiki
服務熔斷
熔斷機制是應對雪崩效應的一種微服務鍊路保護機制。
當扇對外連結路的某個微服務不可用或者響應時間太長時，會進行服務降級，進而熔斷該節點的微服務調用，快速傳回“錯誤”的響應資訊。 當檢測到該節點微服務調用響應正常後恢複調用鍊路。在springCloud架構裡熔斷機制通過Hystrix實作。Hystrix會監控微服務間調用的狀況，當失敗調用到一定閥值，預設是5秒内20次調用失敗就會啟動熔斷機制。熔斷機制的注解是
@HystrixCommand
使用方法
引入pom依賴
<!--hystrix-->
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-hystrix</artifactId>
</dependency>
在代碼上進行編寫，在這之前我們看下示例
示例中在Controller方法上加了一個
@HystrixCommand
注解，作用是在get方法抛出異常時候，就請調fallback中出異常了後的兜底的方法。即get方法出事了，就調用processHystrix_Get方法
在代碼上編寫
@RestController
public class DeptController
{
@Autowired
private DeptService service;
@RequestMapping(value = "/dept/get/{id}", method = RequestMethod.GET)
@HystrixCommand(fallbackMethod = "processHystrix_Get")
public Dept get(@PathVariable("id") Long id)
{
Dept dept=service.get(id);
if(dept==null){
throw new RuntimeException("該ID:"+id+"沒有對應的資訊");
}
return dept;
}
public Dept processHystrix_Get(@PathVariable("id")Long id){
return new Dept().setDeptno(id).setDname("該ID:"+id+"沒有對應的資訊，[email protected]")
.setDb_source("no this database in MySQL");
}
}
在主啟動類上加
@EnableCircuitBreaker
@SpringBootApplication
@EnableEurekaClient
@EnableDiscoveryClient//本服務啟動後會自動注冊進eureka服務中
@EnableCircuitBreaker //對Hystrix熔斷機制的支援
public class DeptProvider8001_Hystrix_App
{
public static void main(String[] args)
{
SpringApplication.run(DeptProvider8001_Hystrix_App.class, args);
}
}
運作結果
服務降級
整體資源快不夠了，忍痛将某些服務先關掉，待度過難關，再開啟回來。什麼意思呢？舉例
A、B、C三個項目組對外開發服務，每個組有5個開發在保持，突然有一天老闆說由于客戶變動及其重視A系統，現在A系統通路的壓力也極大
這個時候，從保證優先級的角度，A系統的項目經理隻好求老大從C系統去借調對應的工程師呢？同樣，這個時候整體資源快不夠了，A從C借調4個工程師
C不夠了，這時候我們是不是忍痛将C暫時關掉呢？可是這樣A保障了，C是不是還有些通路調用的請求呢？就好比銀行A、B、C三個視窗，C這個業務員要被抽掉幹别的事，是不是要挂一個暫停服務的牌子？不然給調用者一點說明都沒有，那調用者就會生氣了。我們關C支援A，但是C還是有一堆老客戶來找他的，我們這應該給老客戶一些回應，一些友好的降級處理，保證我們的服務來維系之後等A度過難關後，再重新開啟C。
服務的降級是在用戶端實作的，與服務端沒有關系
使用
上圖是服務熔斷的使用方式，我們可以看到如果再增加list、add、update方法，那麼都也會有一個
@HystrixCommand
中指定的fallbackMethod方法，這樣就有兩個問題帶來，
-
方法膨脹
加一個
@HystrixCommand
- springAOP面向切面的程式設計，Hystrix是SpringCloud的，那spring的原理概念也可以使用，上面代碼是将處理業務的邏輯和處理異常的切面整合到一起了，高度耦合
@HystrixCommand
避免上述兩點，服務降級實作是這樣
建立實作了FallbackFactory接口的DeptClientServiceFallbackFactory類
@Component //不要忘記添加，否則不好使
public class DeptClientServcieFallbackFactory implements FallbackFactory<DeptClientService> {
@Override
public DeptClientService create(Throwable throwable) {
return new DeptClientService() {
@Override
public Dept get(long id) {
return new Dept().setDname("ID"+id+"沒有對應的資訊，Consumer用戶端提供降級消息，此刻provider服務已經關閉")
.setDb_source("no this database in MYSQL");
}
@Override
public List<Dept> list() {
return null;
}
@Override
public boolean add(Dept dept) {
return false;
}
};
}
DeptClientService接口在注解
@FeignClient
中添加fallbackFactory屬性值
@FeignClient(value = "MICROSERVICECLOUD-DEPT",fallbackFactory = DeptClientServcieFallbackFactory.class)
public interface DeptClientService {
。。。
配置檔案中增加
feign:
hystrix:
enabled: true
運作時候，如果服務端關閉，consumer端就會傳回下圖
此時服務端Provider已經down了，但是我們做了服務降級處理，讓用戶端在服務端不可用時也會獲得提示資訊而不會耗死伺服器
總結
所謂降級，一般是從整體符合考慮。就是當某個服務熔斷之後，伺服器将不再被調用，此時用戶端可以自己準備一個本地的fallback回調，傳回一個預設值。
這樣做，雖然服務水準下降，但好歹可用，比直接挂掉要強
服務監控hystrixDashboard
Hystrix除了隔離依賴服務的調用外，Hystrix還提供了準實時的調用監控（Hystrix Dashboard）,Hystrix 會持續地記錄所有通過Hystrix發起的請求的執行資訊，并以統計報表和圖形的形式展示給使用者，包括每秒執行多少請求多少成功，多少失敗等。
Netflix通過hystrix-metrics-event-stream項目實作了對以上名額的監控。Spring Cloud也提供了Hystrix Dashboard的整合，對監控内容轉化成可視化界面
官網
左上角的breaker dashboard是熔斷監控，就是對微服務的健康狀态、調用狀态、壓力狀态一個直覺的圖形化界面。
使用
引入pom依賴
<!-- hystrix和 hystrix-dashboard相關-->
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-hystrix</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-hystrix-dashboard</artifactId>
</dependency>
添加application.yml配置
server:
port: 9001
寫main方法啟動類
@SpringBootApplication
@EnableHystrixDashboard
public class DeptConsumer_DashBoard_App {
public static void main(String[] args){
SpringApplication.run(DeptConsumer_DashBoard_App.class,args);
}
}
啟動項目，在浏覽器通路http://localhost:9001/hystrix ，出現下圖表示成功
上圖的小動物像什麼？像雞,那吃雞就打不過了。熊貓，那外面的刺是什麼？它全身長刺，什麼東西全身張刺？刺猬？豪豬——社會我豪豬，人狠話不多，它的意思是能夠對你的微服務提供全方位的保護和監控
我們要監控單個應用，在位址欄輸入Single Hystrix App: http://hystrix-app:port/hystrix.stream ，如http://localhost:8001/hystrix.stream ，就可以看到下圖
還可以使用面闆的形式
Delay：該參數用來控制伺服器上輪詢監控資訊的延遲時間，預設為2000毫秒，可以通過配置該屬性來降低用戶端網絡和CPU消耗
Title：該參數對應了頭部标題Hystrix Stream 之後的内容，預設會使用具體監控執行個體的URL，可以通該資訊來展示更合适的标題
可以看到出現了這樣一個面闆
上圖的面闆如何看呢？
7色
1圈
實心圓：共有兩種含義。它通過顔色的變化代表了執行個體的健康程度，它的健康度從綠色<黃色<橙色<紅色遞減
該實心圓除了顔色的變化外，它的大小也會根據執行個體的請求流量發生變化，流量越大該實作圓就越大。是以通過該實心圓的展示，就可以在大量的執行個體中快速的發現故障執行個體和高壓力執行個體
1線
曲線：用來記錄2分鐘内流量的相對變化，可以通過它來觀察到流量的上升和下降趨勢。
整圖說明
搞懂一個才能看懂全套