1. 程式人生 > >springcloud-hystrix斷路器對微服務的容錯處理

springcloud-hystrix斷路器對微服務的容錯處理

true 導致 服務器 進一步 ping 嘗試 sco 處理 netfilx

使用Hystrix實現微服務的容錯處理

1.實現容錯的手段

如果服務提供者響應的速度特別慢,那麽消費者對提供者的請求就會強制等待,直到提供者響應或者超時。在高負載的情況下,如果不做任何處理,此類問題可能會導致服務消費者的資源耗盡甚至整個系統的崩潰。例如曾經發生的一個案例,某個電子商務網站在某個星期五發生過載,過多的並法請求,導致用戶支付請求延遲很久沒有響應,在等待很長時間後最終失敗,支付失敗又導致用戶重新刷新頁面再次嘗試支付,進一步增加了服務器的負載,最終整個系統崩潰了。

1.1雪崩效應

我們常把基礎服務故障導致級聯服務故障的現象稱為雪崩效應。雪崩效應描述的是提供方不可用導致消費方不可用並將不可用逐漸放大的過程。

如下,當請求一直得不到回應,並且新的請求不斷湧入,導致了雪崩效應
技術分享圖片

1.2.如何容錯

想要避免雪崩效應,必須有強大的容錯機制,該容錯機制需要實現以下兩點

  • 為網絡請求設置超時

  • 使用斷路器模式

    正常情況下斷路器關閉可正常請求服務,當一定時間內請求達到了一定的閾(yu)值(錯誤率達到百分之50或者100次/分鐘),斷路器就會打開此時不會再去請求依賴服務,斷路器打開一段時間之後,會自動進入半開的狀態。此時斷路器允許一個請求請求服務實例,如果該服務可以調用成功,則關閉斷路器,否則繼續保持打開狀態。

技術分享圖片

斷路器Hystrix應該在哪一方使用?
斷路器應該在消費者一方使用,這樣才能生效,如果設置在服務者一方,請求已經到達服務者,無法保護消費者和服務者。

2.使用hystrix實現容錯

hystrix是Netfilx開源的延遲和容錯庫,用於隔離訪問遠程系統,服務或者第三方庫,防止級聯失敗,從而提升系統的可用性和容錯性

3.通用方式整合Hystrix

1.為項目添加依賴
<!-- https://mvnrepository.com/artifact/org.springframework.cloud/spring-cloud-starter-hystrix -->
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-hystrix</artifactId>
</dependency>
2.在消費者的入口類上添加註解
@EnableHystrix
@EnableDiscoveryClient
@SpringBootApplication
public class HiApplication {
    public static void main(String[] args) {
        SpringApplication.run(HiApplication.class, args);
}
3.讓當前方法具備容錯的能力

使用註解:@HystrixCommand(fallbackMethod = "hystrixFallback") ,並指定當斷路器生效時調用的方法。

@RestController
@RequestMapping("/query")
public class ClientController {

    @Autowired
    private RestTemplate restTemplate;

    @Autowired
    LoadBalancerClient loadBalancerClient;

    @HystrixCommand(fallbackMethod = "hystrixFallback")
    @RequestMapping("/test")
    public String test(String name){
        String template = restTemplate.getForObject("http://EUREKA-PROVIDER/test/test1?name=" + name, String.class);
        return template;
    }

    //斷路器生效時調用的方法
    public String hystrixFallback(String name){
        return "hystrixFallback info "+name;
    }
}
4.測試
1.啟動eureka服務
2.啟動生產者
3.啟動消費者
4.訪問消費者 http://localhost:8762/query/test?name=haha
結果
xixixi 8763  :haha
5.關閉生產者
6.訪問消費者
結果
hystrixFallback info haha

我們知道,當請求失敗,被拒絕超時或者短路器打開時都會進入到回退方法,但是進入回退方法並不是意味著斷路器被打開,那怎樣才算斷路器打開呢?

5.實驗 進行健康監測實時查看斷路器是否打開
1.啟動eureka服務
2.啟動生產者
3.啟動消費者
4.訪問消費者
結果
{"name":"xiaohei","password":null,"age":null}
5.訪問 http://ip:port/health
{
    status:"up",
    hystrix:{
        status:"up"
    }
}
6.關閉生產者
7.訪問消費者
結果
{"name":"xiaohei","password":null,"age":-1}
8.訪問 http://ip:port/health
{
    status:"up",
    hystrix:{
        status:"up"
    }
}
通過這裏我們可以發現,盡管執行了fallback方法,但此時hystrix狀態依然是up,這是因為咱們的失敗率還沒有達到閥值(默認5秒20次失敗),這裏再次強調,執行回退的邏輯並不代表斷路器已經打開,請求超時,失敗,被拒絕以及斷路器打開都會執行回退邏輯
9.5秒請求20次
{
    status:"up",
    hystrix:{
        status:"CIRCUIT_OPEN"(斷路器打開的標識)
    }
}

斷路器的狀態
半開狀態
技術分享圖片

正常運行
技術分享圖片

開啟狀態
技術分享圖片

4.feign整合Hystrix

很顯然@HystrixCommand是添加到方法上的,那麽對於feign來說一定不適用,如何讓Hystrix整合feign?

1.feign方法上添加相關註解
@FeignClient(serviceId = "HI-SERVICE",fallback = FeignClientFallBack.class)
public interface feignPost {
    @RequestMapping(value = "/test/test1", method = RequestMethod.POST)
    public User sayHi(User user);
}
2.實現Feign接口
@Component  //將該類交由工廠管理
public class FeignClientFallBack implements feignPost {
    @Override
    public User sayHi(User user) {
        System.out.println("Hystrix method is invoke");
        return null;
    }
}
3.添加feign的配置文件
為feign開啟斷路器
feign.hystrix.enabled=true

springcloud-hystrix斷路器對微服務的容錯處理