1、什么是服務的熔斷機制？
熔斷機制是對系統的防護，比如受到一些惡意攻擊，那么需要熔斷機制來保護系統的微服務，做出響應，避免資源被耗盡。既要能響應，又要能防護，當我們的請求達到一個負載閾值，就啟用熔斷，把真實接口關掉，給客戶端請求一個響應，這個響應，我們可以設置。服務熔斷就是對該服務的調用執行熔斷，對應后續請求，不在繼續調用該目標服務，而是直接返回，從而可以快速釋放資源，或者服務出現故障，會把故障信息返回給客戶端
服務熔斷的幾種方式：
斷路器，這是一個硬件設施，比如保險絲或者電子設備等等
斷路器模式，可以進行故障檢測，斷路器狀態一般包括Closed關閉，Open打開，Half-Open半打開
2、熔斷的意義？
本質上是為了保護系統，讓系統保持穩定；
減少性能損耗；
及時響應；
熔斷器的功能：異常處理、日志記錄、測試失敗的操作、手動復位、並發、加速斷路、重試失敗請求
3、熔斷與降級的區別？
相似性：目的一致、表現類似、粒度一致
區別：觸發條件不同，熔斷一般是故障引起，降級一般是整體性能。管理目標層次不同。
4、使用Hystrix，實現熔斷機制，springboot結合Hystrix
pom.xml
<!-- 集成hystrix -->
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-netflix-hystrix</artifactId>
<version>${spring.cloud.version}</version>
</dependency>
application.class，這是在原來的Feign實例上，加上熔斷器
@SpringBootApplication
@EnableDiscoveryClient
@EnableHystrix
@EnableFeignClients(clients=CityClient.class)
@ComponentScan(basePackages={"com.example.*"})
public class WeaterApiApplication {
public static void main(String[] args) {
SpringApplication.run(WeaterApiApplication.class, args);
}
}
HttpController.class
@RestController
@RequestMapping("/http")
public class HttpController {
@Autowired
CityClient cityClient;
/**
* 熔斷器的應用場景是有進行服務之間的調用。這里使用feign調用weather服務，所以這里如果無法訪問
* weather的getDataParam服務的時候，就啟動熔斷器，調用反饋方法fallback
* @param city
* @return
*/
@HystrixCommand(fallbackMethod="fallback")
@RequestMapping("/getDataParam/{city}")
public String getDataParam(@PathVariable("city")String city){
return cityClient.getDataParam(city);
}
public String fallback(String city){
return "services is not running! parameters city is:"+city;
}
}
測試，getDataParam服務正常能訪問
關閉服務
=====================================================================================
另外一種是使用類來創建熔斷器，類要實現Feign定義的接口，每個服務方法對應一個熔斷器方法
@FeignClient(name="weather",fallback=CityClientFallBack.class)
public interface CityClient {
@GetMapping("/getCityWeather")
public String listCity();
//http://localhost:8766/weath/weather/getData
//使用zuul,@GetMapping("/weath/weather/getData")
@GetMapping("/getData")
public String getData();
@GetMapping("/getDataParam/{city}")
public String getDataParam(@PathVariable("city")String city);
}
CityClientFallBack.class(這里我們使用的是接口實現，還可以直接在方法上使用注解@HystrixCommand，或者controller類使用@DefaultProperties注解)
@Component
public class CityClientFallBack implements CityClient{
@Override
public String listCity() {
/**
* 比如這里是訪問城市列表的，這個時候這個服務不能訪問。
* 就要返回默認城市列表，這里就不具體寫實現代碼
*/
return null;
}
@Override
public String getData() {
return "getData service is not running!";
}
@Override
public String getDataParam(String city) {
return "getData service is not running!";
}
}
關閉getDataParam服務，測試訪問，出現正確的反饋測試
雪崩效應
在微服務架構中，可能因為某一個基礎服務故障，而導致多個服務之間的調用，出現阻塞，無法調用，一環扣一環，導致所有服務不可用，我們稱這效應為雪崩效應。
斷路器機制
斷路器很好理解, 當Hystrix Command請求后端服務失敗數量超過一定比例(默認50%), 斷路器會切換到開路狀態(Open). 這時所有請求會直接失敗而不會發送到后端服務. 斷路器保持在開路狀態一段時間后(默認5秒), 自動切換到半開路狀態(HALF-OPEN). 這時會判斷下一次請求的返回情況, 如果請求成功, 斷路器切回閉路狀態(CLOSED), 否則重新切換到開路狀態(OPEN). Hystrix的斷路器就像我們家庭電路中的保險絲, 一旦后端服務不可用, 斷路器會直接切斷請求鏈, 避免發送大量無效請求影響系統吞吐量, 並且斷路器有自我檢測並恢復的能力.
Fallback
Fallback相當於是降級操作. 對於查詢操作, 我們可以實現一個fallback方法, 當請求后端服務出現異常的時候, 可以使用fallback方法返回的值. fallback方法的返回值一般是設置的默認值或者來自緩存。
服務降級的應用場景很多，比如我們使用app的時候，服務請求失敗，會提示服務器開小差了這種提示，就是一種服務降級的應用場景，等服務恢復正常了，就不會提示。再如雙十一、秒殺活動，查詢不到商品詳情，提示找不到商品等等類似的場景。
還有服務的訪問時間，也就是請求超時的問題，這些在Hystrix的注解里，都有配置參數，具體自查，點擊注解進去，都能看得到。
限流機制--nignx 使用網關
限流模式主要是提前對各個類型的請求設置最高的QPS閾值，若高於設置的閾值則對該請求直接返回，不再調用后續資源。這種模式不能解決服務依賴的問題，只能解決系統整體資源分配問題，因為沒有被限流的請求依然有可能造成雪崩效應。
docker通過倉壁模式，實現進程隔離，使得容器之間互不影響。而Hystrix實現線程池隔離，會為每個HystrixCommand，創建獨立的線程池，這樣就算某個在HystrixCommand下包裝的依賴服務，出現延遲過高的情況，也只是對該依賴的服務產生影響，不會影響其他服務的調用。所以使用HystrixCommand包裝的方法，Hystrix自動實現了依賴隔離、服務降級。
微服務和分布式中，容錯是必須要做的，一種是重試機制，對於預期短暫的故障，可以使用重試，是可以解決的。對於更長時間，解決的的故障問題，你不斷嘗試，也是沒有太大意義的。這個時候可以使用斷路器模式，斷路器模式是將一個受保護的服務封裝在一個斷路器對象里，當故障達到一定的值，斷路器將會跳閘，斷路器對象，返回錯誤。
斷路器模式
hystrix超時設置
controller下使用hystrix
Feign使用hystrix
使用配置項，在application.ym或者bootstrap.yml里配置
#熔斷器啟用
feign.hystrix.enabled=true
hystrix.command.default.execution.timeout.enabled=true
#斷路器的超時時間,下級服務返回超出熔斷器時間，即便成功，消費端消息也是TIMEOUT,所以一般斷路器的超時時間需要大於ribbon的超時時間，ribbon是真正去調用下級服務
#當服務的返回時間大於ribbon的超時時間，會觸發重試
#斷路器的超時時間默認為1000ms，太小了
hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds=60000
#斷路器詳細設置
#當在配置時間窗口內達到此數量的失敗后，進行短路。默認20個）
#hystrix.command.default.circuitBreaker.requestVolumeThreshold=20
#短路多久以后開始嘗試是否恢復，默認5s）
#hystrix.command.default.circuitBreaker.sleepWindowInMilliseconds=5
#出錯百分比閾值，當達到此閾值后，開始短路。默認50%）
#hystrix.command.default.circuitBreaker.errorThresholdPercentage=50%
————————————————
版權聲明：本文為CSDN博主「金麟十三少」的原創文章，遵循 CC 4.0 BY-SA 版權協議，轉載請附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/u012373281/article/details/89761656