一、Hystrix 是什么

​ 在微服務(wù)架構(gòu)中，我們將系統(tǒng)拆分成了若干弱小的單元，單元與單元之間通過HTTP或者TCP等方式相互訪問，各單元的應(yīng)用間通過服務(wù)注冊(cè)與訂閱的方式相互依賴。由于每個(gè)單元都在不同的進(jìn)程中運(yùn)行，依賴 遠(yuǎn)程調(diào)用 的方式執(zhí)行，這樣就可能引起因?yàn)榫W(wǎng)速變慢或者網(wǎng)絡(luò)故障導(dǎo)致請(qǐng)求變慢或超時(shí)，若此時(shí)調(diào)用方的請(qǐng)求在不斷增加，最后就會(huì)因等待出現(xiàn)故障的依賴方響應(yīng)形成任務(wù)積壓，最終導(dǎo)致自身服務(wù)的癱瘓。

​ Hystrix 是Netflix 中的一個(gè)組件庫(kù)，它隔離了服務(wù)之間的訪問點(diǎn)，阻止了故障節(jié)點(diǎn)之間可能會(huì)引起的雪崩效應(yīng)，并提供了后備選項(xiàng)。

​ 在微服務(wù)架構(gòu)中，存在著許多的服務(wù)單元，若單一節(jié)點(diǎn)的故障，就很容易因?yàn)橐蕾囮P(guān)系而引發(fā)故障的蔓延，最終導(dǎo)致整個(gè)生態(tài)系統(tǒng)的癱瘓。為了解決這樣的問題，產(chǎn)生了 斷路器 等一系列的保護(hù)機(jī)制措施。

​ 在 分布式架構(gòu)中 ，斷路器模式的作用也是類似的，當(dāng)某個(gè)服務(wù)單元發(fā)生故障（類似用電器發(fā)生短路）之后，通過斷路器的故障監(jiān)控（類似熔斷保險(xiǎn)絲），向調(diào)用方返回一個(gè)錯(cuò)誤響應(yīng)，而不是長(zhǎng)時(shí)間的等待。這樣就不會(huì)使得線程因調(diào)用故障服務(wù)被長(zhǎng)時(shí)間占用不釋放，避免了故障在分布式系統(tǒng)中的蔓延。

雪崩效應(yīng)

​ 雪崩效應(yīng)就像是水滴石穿，蝴蝶效應(yīng)一樣，是指微小的事物隨著時(shí)間的推移，會(huì)變得越來越巨大，從而對(duì)整個(gè)環(huán)境造成影響的現(xiàn)象。例如：在生態(tài)系統(tǒng)中，某一類物種的滅絕可能對(duì)整個(gè)生態(tài)系統(tǒng)造成不了太大的損失，但是這類物種的滅絕可能會(huì)引發(fā)其他物種的死亡，其他物種的滅絕又會(huì)影響另外一種物種的滅亡，就像雪球越滾越大，最終會(huì)導(dǎo)致整個(gè)生態(tài)系統(tǒng)的崩潰。

如上圖所示：A作為服務(wù)提供者，B為A的服務(wù)消費(fèi)者，C和D是B的服務(wù)消費(fèi)者。A不可用引起了B的不可用，并將不可用像滾雪球一樣放大到C和D時(shí)，雪崩效應(yīng)就形成了。

 雪崩效應(yīng)產(chǎn)生場(chǎng)景

流量激增 ： 比如異常流量，用戶重試導(dǎo)致系統(tǒng)負(fù)載升高；

緩存刷新 ： 假設(shè)A為 client 端，B為 Server 端，假設(shè)A系統(tǒng)請(qǐng)求都流向B系統(tǒng)，請(qǐng)求超出了B系統(tǒng)的承載能力，就會(huì)造成B系統(tǒng)崩潰

連接未釋放 ： 代碼循環(huán)調(diào)用的邏輯問題，資源未釋放引起的內(nèi)存泄漏等問題；

硬件故障 ： 比如宕機(jī)，機(jī)房斷電等

線程同步等待 ： 系統(tǒng)間經(jīng)常采用同步服務(wù)調(diào)用模式，核心服務(wù)和非核心服務(wù)共用一個(gè)線程池和消息隊(duì)列。如果一個(gè)核心業(yè)務(wù)線程調(diào)用非核心業(yè)務(wù)線程，這個(gè)非核心線程交由第三方系統(tǒng)完成，當(dāng)?shù)谌较到y(tǒng)本身出現(xiàn)問題，導(dǎo)致核心線程阻塞，一直處于等待狀態(tài)，而進(jìn)程間的調(diào)用是有超時(shí)限制的，最終這條線程將斷掉，也可能引發(fā)雪崩；

常見解決方案

​ 針對(duì)上述的雪崩問題，每一條都有一個(gè)自己的解決方案，但是任何一個(gè)解決方案能夠應(yīng)對(duì)所有場(chǎng)景

• 針對(duì)流量激增，采用自動(dòng)擴(kuò)容以應(yīng)對(duì)流量激增，或者在負(fù)載均衡器上安裝限流模塊
• 針對(duì)緩存刷新，參考Cache應(yīng)用的服務(wù)過載案例研究
• 針對(duì)硬件故障，采用多機(jī)房災(zāi)備，跨機(jī)房路由
• 針對(duì)同步等待，采用線程隔離，熔斷器等機(jī)制

通過實(shí)踐發(fā)現(xiàn)，線程同步等待是最常見引發(fā)的雪崩效應(yīng)的場(chǎng)景。

二、Hystrix斷路器搭建

​ 在開始使用Spring Cloud Hystrix斷路器之前，我們先用之前實(shí)現(xiàn)的一些內(nèi)容作為基礎(chǔ)，構(gòu)建一個(gè)如下圖所示的服務(wù)調(diào)用關(guān)系：

如圖所示，上面需要的角色有三個(gè)，服務(wù)有四個(gè)

• ribbon-connsumer： ribbon消費(fèi)者，消費(fèi)server-provider提供的服務(wù)
• server-provider： 服務(wù)提供者，提供服務(wù)供消費(fèi)者消費(fèi)(有點(diǎn)像父母默默的付出一樣)，啟動(dòng)兩個(gè)實(shí)例，還記得怎么啟動(dòng)嗎？—server.port 啟動(dòng)
• eureka-server: eureka注冊(cè)中心，提供最基本的訂閱發(fā)布功能。消費(fèi)者和服務(wù)提供者都需要往注冊(cè)中心注冊(cè)自己
  

​ 依次啟動(dòng)上面的四個(gè)服務(wù)，發(fā)現(xiàn)注冊(cè)中心已經(jīng)成功注冊(cè)了四個(gè)服務(wù)（包括自己）

​調(diào)用http://localhost:9000/ribbon-consumer 發(fā)現(xiàn)能夠通過Ribbon進(jìn)行遠(yuǎn)端調(diào)用

在未加入斷路器之前，關(guān)閉ribbon-consumer 的連接，再次調(diào)用http://localhost:9000/ribbon-consumer，發(fā)現(xiàn)服務(wù)無法提供（使用Postman 測(cè)試）

下面開始引入Hystrix

在ribbon-consumer 工程的pom.xml的dependency節(jié)點(diǎn)下引入spring-cloud-starter-hystrix依賴

在ribbon-consumer 工程的 主加載類 中添加 @EnableCircuitBreaker 開啟斷路器的功能

注意：這里也可以使用@SpringCloudApplication注解來修飾應(yīng)用主類，具體定義如下

@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Inherited
@SpringBootApplication
@EnableDiscoveryClient
@EnableCircuitBreaker
public @interface SpringCloudApplication {}

SpringCloudApplication 注解上有@EnableCircuitBreaker 注解，用來開啟斷路器的功能，其他主要注解是@SpringBootApplication ，這個(gè)注解是SpringBoot的啟動(dòng)類注解， @EnableDiscoveryClient該注解可以發(fā)現(xiàn)Eureka注冊(cè)中心

改造消費(fèi)方式，新增 HystrixService 類，并且注入 RestTemplate 實(shí)例，然后，將在RibbonController中對(duì)RestTemplate 的使用遷移到hystrixService方法中，最后，在hystrixService上添加@HystrixCommand注解來指定回掉方法。

 // HystrixService
  @Service
 public class HystrixService {

   @Resource
   RestTemplate restTemplate;
      
    // 指定回掉方法是下面的hystrixCallback
   @HystrixCommand(fallbackMethod = "hystrixCallBack")
   public String hystrixService(){
     return restTemplate.getForEntity("http://server-provider/hystrix",String.class).getBody();
   }

   public String hystrixCallBack(){
     return "error";
   }
 }

服務(wù)提供者 的業(yè)務(wù)非常簡(jiǎn)單，具體代碼如下

  @RequestMapping(value = "/hystrix", method = RequestMethod.GET)
  public String hystrix(){
    return "hystrix";
  }

下面來驗(yàn)證一下通過斷路器的回掉實(shí)現(xiàn)，重啟之前關(guān)閉的8081端口，恢復(fù)成為四個(gè)服務(wù)的狀態(tài)，并確保http://localhost:9000/ribbon-consumer/ 能夠提供服務(wù)，并且以輪詢的方式循環(huán)訪問8081 和 8082 端口的服務(wù)。此時(shí)斷開8081端口，發(fā)現(xiàn)頁面上展示的不再是 hystrix ，而是"error"，而另一個(gè)服務(wù)是正常能夠打印。

 三、斷路器優(yōu)化

​ 經(jīng)過以上服務(wù)的搭建，相信你已經(jīng)能夠搭建出來最基本的Hystrix熔斷器，并且實(shí)現(xiàn)了服務(wù)熔斷機(jī)制，下面就來對(duì)斷路器做一下簡(jiǎn)單的優(yōu)化，來模擬 服務(wù)阻塞(長(zhǎng)時(shí)間未響應(yīng)) 的情況。

優(yōu)化 server-provider 代碼如下：

 @RequestMapping(value = "/hystrix", method = RequestMethod.GET)
  public String hystrix() throws InterruptedException {
    ServiceInstance serviceInstance = discoveryClient.getLocalServiceInstance();
    // 讓線程等待幾秒鐘
    int sleepTime = new Random().nextInt(3000);
    Thread.sleep(sleepTime);
    System.out.println("weak up!!!");
    log.info("sleepTime = " + sleepTime);
    return "hystrix";
  }

依次啟動(dòng)所有的服務(wù)，在主頁上訪問 http://localhost:9000/ribbon-consumer ，多次刷新主頁，發(fā)現(xiàn)error 和 hystrix 是交替出現(xiàn)的，這是為何？

因?yàn)閔ystrix斷路器的 默認(rèn)超時(shí)時(shí)間 是2000毫秒，所以這里采用了0 - 3000 的隨機(jī)數(shù)，也就是訪問請(qǐng)求在 0 -2000 毫秒內(nèi)是不超時(shí)的，不會(huì)觸發(fā)斷路器，而> 2000 毫秒是超市的，默認(rèn)會(huì)觸發(fā)斷路器。

以上就是本文的全部?jī)?nèi)容，希望對(duì)大家的學(xué)習(xí)有所幫助，也希望大家多多支持腳本之家。

最新評(píng)論