手把手學習springcloudalibaba：❤️‍服務熔斷降級Hystrix的實戰總結，學習完保你不在懵逼❤️‍

通過我前面章節的學習，大家應該可以利用Springcloud搭建一個基本的微服務架構。對于高可用的分布式架構，能夠完成服務提供和調用是不夠的，為了使我們的服務更加健壯，我們還希望服務有抵擋異常的能力和自我修複的能力，比如服務調用逾時、運作時異常、當機等情況下，我們的系統依然可以對使用者提供友好可用的服務。這些是如何做到的，那麼我們來一起學習下Hystrix，俗稱“豪豬哥”。

Hystrix簡介

Hystrix是一個用于處理分布式系統的延遲和容錯的開源庫，在分布式系統裡，許多依賴不可避免的會調用失敗，比如逾時、異常等，Hystrix能夠保證在一個依賴出問題的情況下，不會導緻整體服務失敗，避免級聯故障，以提高分布式系統的彈性。

Hystrix主要功能指：

• 服務降級
• 服務熔斷
• 服務限流

Hystrix通過上述三個功能，在服務異常情況下，保證服務調用方可以擷取到符合預期的結果，而不是直接展示伺服器異常，避免拖垮調用方，防止雪崩效應的出現。

服務雪崩：

多個微服務之間調用的時候，假設微服務A調用B和C，B和C又調用其它的微服務，這就是所謂的“扇出”。如果扇出的鍊路上某個微服務的調用響應時間過長或者不可用，對微服務A的調用就會占用越來越多的系統資源，進而引起系統崩潰，就是所謂的“雪崩效應”。

對于高流量的應用來說，單一的後端依賴可能會導緻所有伺服器上的所有資源在很短的時間内達到飽和。比失敗更糟糕的是，這些應用程式還可能導緻服務之間的延遲增加，備份隊列，線程和其他系統資源緊張，導緻整個系統發生更多的級聯故障。這些都表示需要對故障和延遲進行隔離和管理，以便單個依賴關系的失敗，不能取消整個應用程式和系統。

通常當發現一個子產品下的某個執行個體失敗後，這時候這個子產品依然還會接收流量，然後這個有問題的子產品還調用了其他的子產品，這樣就會發生級聯故障，或者叫雪崩。

服務異常

通常我們所說的異常主要分為如下三類：

• 運作時異常
• 逾時
• 當機

這三類異常大家都可以做到見名知意，我就不展開說明了。後面在實戰環節，我會講如何根據這些異常做服務降級和熔斷處理。

Hystrix停更 

目前Netflix公司宣布對Hystrix停更，進入維護階段。但是它的設計思想非常先進和完善，出道即巅峰，其他替代品都是在它的基礎上設計和加強。它非常優秀，在各大公司應用廣泛，是以我還是要講一下它在項目中如何使用，後續我也會講解下，我們的國産替代品--阿裡開源的Sentinel。 

Sentinel的使用比Hysrix更友善快捷，Hystrix真正運作起來需要啟動一堆小元件，實時監控也需要臨時配置，比較麻煩，很多同學可能因為其複雜的流程而很難入門，隻要你用起來後，還是很簡單的。是以大家在新起項目的時候，建議直接使用alibaba SpringCloud的相關元件，一次引入友善快捷。

Hystrix實戰

我們可以引入Hystrix的依賴庫，直接使用相應注解使服務具備處理異常的能力，也可以通過引入圖形化元件HystrixDashboard做接口的實時狀态監控。

服務降級實戰

服務降級就是隻服務調用出現異常，比如運作時異常、逾時、當機情況時，快速傳回事先定義好的傳回結果，防止服務調用方因服務提供方出問題被拖死。

• 建立兩個Module，分别是服務生産者和消費者。如何建構參考我以前的文章
• 生産者和消費者的pom檔案都要引入Hystrix的jar包依賴

<dependency>
     <groupId>org.springframework.cloud</groupId>
     <artifactId>spring-cloud-starter-netflix-hystrix</artifactId>
</dependency>
           

• 修改消費者yml檔案，服務調用使用OpenFeign，是以要開啟feign的hystrix功能。（這裡是不是看着很别扭，因為OpenFeign是從Feign而來，是以沿用很多feign的配置。），服務生産者不需要這個配置。

feign:
  hystrix:
    enabled: true
           

• 修改啟動類，開啟Hystrix的配置，使用@EnableHystrix注解

/**
*服務生産者
*/
@SpringBootApplication
@EnableEurekaClient
@EnableHystrix
public class HystrixApplication8001 {
    public static void main(String[] args) {
        SpringApplication.run(HystrixApplication8001.class,args);
    }
}

/**
*服務消費者
*/
@SpringBootApplication
@EnableEurekaClient
@EnableFeignClients
@EnableHystrix
public class HystrixApplication8080 {
    public static void main(String[] args) {
        SpringApplication.run(HystrixApplication8080.class,args);
    }
}
           

• 修改業務類，服務生産者和服務消費者使用Hysrix的方式略有不同。服務提供方一般加在controller上；服務消費者一般加在Service上，因為再Service上使用Feign封裝服務調用。說重點：在實際代碼編寫過程中，我們在服務提供方和服務消費方都要加上降級邏輯，因為存在多級調用的情況，即存在功能1用A服務，A服務調用B服務，B服務又調用C服務；功能2調用B；在這兩個功能請求中B服務既是服務提供方，又是服務消費方，是以隻在消費方就不合理了。原則上兩邊都加上，在服務治理時，通過日志監控可以快速定位是哪個服務出的問題。
• 服務生産者代碼實作

@RestController
@RequestMapping("/payment")
public class PayMentController {
    @Autowired
    private PaymentService paymentService;

    @Value("${server.port}")
    private String port;



    @GetMapping("/getPayment/{id}")
    @HystrixCommand(fallbackMethod = "getPaymentOut", commandProperties = {
            @HystrixProperty(name = "execution.isolation.thread.timeoutInMilliseconds", value = "3000")
    })
    public MsgResponseBody getPayment(@PathVariable("id") Long id) {
        Payment payment = paymentService.getById(id);
        String a = "查詢"+port+"成功";
        String code ="200";
            return new MsgResponseBody().setMsg(a).setResultCode(code).setData(payment);
    }

    /**
    *
    *跟getPayment對應的降級方法
    */
    public MsgResponseBody getPaymentOut(Long id) {
        System.out.println("服提供方降級： "+id);
        MsgResponseBody msgResponseBody = new MsgResponseBody();
        msgResponseBody.setMsg("服務提供方降級");
        msgResponseBody.setResultCode("500");
        msgResponseBody.setData(null);
        return msgResponseBody;

    }
}
           

• 服務消費者代碼實作

/**
*
*服務調用的Service
*/
@Component
@FeignClient(value = "CLOUD-HYSTRIX-PAYMENT-SERVICE", fallback = PaymentFeignFallbackService.class)
public interface PaymentFeignService {
    @GetMapping("/payment/getPayment/{id}")
    public MsgResponseBody getById(@PathVariable("id") Long id);
}


/**
*
*服務降級采用統一傳回，
*/
@Component
public class PaymentFeignFallbackService implements PaymentFeignService{
    @Override
    public MsgResponseBody getById(Long id) {
        System.out.println("提供方服務降級");
        MsgResponseBody msgResponseBody = new MsgResponseBody();
        msgResponseBody.setMsg("提供方服務降級");
        msgResponseBody.setResultCode("500");
        msgResponseBody.setData(null);
        return msgResponseBody;
    }
}


@RestController
@RequestMapping("/consumer")
public class OpenFeignConsumerController {
    @Resource
    private PaymentFeignService paymentFeignService;

    @GetMapping("/getPayment/{id}")
    @HystrixCommand(fallbackMethod = "fallBack", commandProperties = {
            @HystrixProperty(name = "execution.isolation.thread.timeoutInMilliseconds", value = "3000")
    })
    public MsgResponseBody getPaymet(@PathVariable("id") Long id){
        int age = 1/0;
        return paymentFeignService.getById(id);
    }

    /**
    *
    *消費方本身出現問題時服務降級的快速傳回
    */
    public MsgResponseBody fallBack(){
        System.out.println("調用方服務降級");
        MsgResponseBody msgResponseBody = new MsgResponseBody();
        msgResponseBody.setMsg("調用方服務降級");
        msgResponseBody.setResultCode("500");
        msgResponseBody.setData(null);
        return msgResponseBody;
    }
}
           

服務熔斷實戰

熔斷機制是應對雪崩效應的一種微服務鍊路保護機制，當扇對外連結路的某個微服務不可用或者響應時間太長時，會進行服務的降級，進而熔斷該節點微服務的調用，快速傳回”錯誤”的響應資訊，當檢測到該節點微服務響應正常後恢複調用鍊路。

參數配置

使用@HystrixCommand注解，涉及的參數如下：

• 是否開啟斷路器，必須要設定成true

@HystrixProperty(name = "circuitBreaker.enabled", value = "true"),

• 請求次數

@HystrixProperty(name = "circuitBreaker.requestVolumeThreshold", value = "10"),

• 時間視窗期

@HystrixProperty(name = "circuitBreaker.sleepWindowInMilliseconds", value = "10000"),

• 失敗率達到多少後跳閘

@HystrixProperty(name = "circuitBreaker.errorThresholdPercentage", value = "60")

打開斷路器之後，在10秒内，請求10次，出現60%失敗率的時候，觸發斷路器生效，服務開始做降級處理，當失敗率低于60%時，服務調用開始恢複，正常傳回結果。 

總結

重點：

服務講解熔斷我們使用的都是@HystrixCommand注解，是方法級注解，加在哪個方法上，哪個方法就生效。通常都加在Controller上，即服務的入口上，這樣就能覆寫求情的整個生命周期。

掃碼請關注

同時也歡迎大家添加個人微信【shishuai860505】，我拉大家進我的讀者交流群。