實(shí)際業(yè)務(wù)場(chǎng)景下服務(wù)快速失敗實(shí)戰(zhàn)

1. 前言

我們知道，服務(wù)快速失敗分為普通版本和斷路器版本。在本節(jié)中，我將繼續(xù)為大家介紹，在真實(shí)業(yè)務(wù)場(chǎng)景下的，服務(wù)快速失敗的應(yīng)用方法及代碼實(shí)現(xiàn)。

本節(jié)主要內(nèi)容：

• 服務(wù)快速失敗真實(shí)業(yè)務(wù)場(chǎng)景描述；

• 業(yè)務(wù)場(chǎng)景實(shí)現(xiàn)思路分析與實(shí)操。

2. 服務(wù)快速失敗真實(shí)業(yè)務(wù)場(chǎng)景描述

業(yè)務(wù)場(chǎng)景描述

我們繼續(xù)以某大廠的用戶注冊(cè)服務(wù)為例，只不過(guò)所在的業(yè)務(wù)場(chǎng)景發(fā)生了變化。

有這樣一個(gè)真實(shí)的業(yè)務(wù)場(chǎng)景，在用戶請(qǐng)求用戶注冊(cè)服務(wù)時(shí)，該服務(wù)要求用戶上傳自己的注冊(cè)頭像，在單體項(xiàng)目架構(gòu)下，我們上傳多次頭像都沒(méi)有任何問(wèn)題，服務(wù)可以正常的進(jìn)行。但是，將我們把項(xiàng)目架構(gòu)進(jìn)行演進(jìn)，項(xiàng)目由單體架構(gòu)演變?yōu)榱宋⒎?wù)的分布式架構(gòu)之后，時(shí)不時(shí)地會(huì)出現(xiàn)因?yàn)橛脩糇?cè)頭像上傳失敗而導(dǎo)致整個(gè)用戶注冊(cè)服務(wù)無(wú)法繼續(xù)進(jìn)行的情況。

問(wèn)題原因分析

在解決問(wèn)題之前，我們首先來(lái)分析一下這種問(wèn)題產(chǎn)生的原因。

當(dāng)項(xiàng)目架構(gòu)由傳統(tǒng)的單體架構(gòu)演變?yōu)榛谖⒎?wù)的分布式架構(gòu)之后，我們需要處理很多由于微服務(wù)架構(gòu)所帶來(lái)的已知問(wèn)題，在將這些已知問(wèn)題處理好后，我們的項(xiàng)目才能正常運(yùn)行，而上述業(yè)務(wù)場(chǎng)景中的問(wèn)題就包括在這些已知問(wèn)題中，下面我們來(lái)介紹一下問(wèn)題產(chǎn)生的原因（至于其他已知問(wèn)題，這里不做介紹）。

無(wú)論是傳統(tǒng)的用戶注冊(cè)服務(wù)，還是分布式的用戶注冊(cè)服務(wù)，其用戶注冊(cè)處理邏輯都大同小異。在處理用戶注冊(cè)邏輯時(shí)，一般會(huì)將用戶注冊(cè)頭像上傳的業(yè)務(wù)邏輯與用戶注冊(cè)的處理邏輯相分離，即將用戶注冊(cè)頭像上傳作為一個(gè)單獨(dú)的服務(wù)存在，同時(shí)用戶注冊(cè)的處理邏輯也作為一個(gè)單獨(dú)的服務(wù)接口。

當(dāng)正式調(diào)用用戶注冊(cè)服務(wù)時(shí)，會(huì)對(duì)用戶注冊(cè)頭像上傳服務(wù)做一個(gè)校驗(yàn)，如果用戶成功上傳了所注冊(cè)的頭像，那么用戶注冊(cè)頭像上傳服務(wù)會(huì)返回一個(gè)頭像地址，并且在最后的用戶注冊(cè)邏輯中，將該地址與當(dāng)前注冊(cè)的用戶相關(guān)聯(lián)，這就完成了整個(gè)用戶注冊(cè)的流程。

上述業(yè)務(wù)場(chǎng)景的問(wèn)題就出現(xiàn)在用戶注冊(cè)頭像上傳服務(wù)中，當(dāng)外界因素或者由于我們處理用戶注冊(cè)頭像格式時(shí)的處理邏輯不嚴(yán)謹(jǐn)時(shí)，就會(huì)出現(xiàn)用戶注冊(cè)頭像上傳失敗的情況， 其中，由處理邏輯不嚴(yán)謹(jǐn)所引起的錯(cuò)誤可以直接通過(guò)修改源碼邏輯來(lái)規(guī)避這種錯(cuò)誤，但是由外界因素所引起的錯(cuò)誤就不好規(guī)避了。

由外界因素引起的錯(cuò)誤，可能是項(xiàng)目所在服務(wù)器網(wǎng)絡(luò)波動(dòng)的影響，也可能是各微服務(wù)所在節(jié)點(diǎn)間數(shù)據(jù)通信丟失或堵塞的影響，也可能是沒(méi)有對(duì)分布式事務(wù)做處理的影響。

我們不需要知道這種錯(cuò)誤具體是由于什么外界因素所引起的，我們只需要關(guān)心，在外界因素對(duì)服務(wù)造成影響時(shí)，我們有兜底的解決方案即可。那么接下來(lái)就讓我們來(lái)看一下如何設(shè)計(jì)這個(gè)兜底的方案。

3. 業(yè)務(wù)場(chǎng)景實(shí)現(xiàn)思路分析與實(shí)操

實(shí)現(xiàn)思路分析

鑒于上述業(yè)務(wù)場(chǎng)景中所描述的問(wèn)題，我們可以在用戶注冊(cè)頭像上傳服務(wù)中，添加對(duì)服務(wù)快速失敗的支持，接下來(lái)讓我們來(lái)看一下如何操作。

在為用戶注冊(cè)頭像上傳服務(wù)配置了快速失敗之后，當(dāng)服務(wù)再次受到外界因素影響時(shí)，用戶注冊(cè)頭像服務(wù)會(huì)返回一個(gè)兜底的地址，并將該地址與當(dāng)前注冊(cè)的用戶相關(guān)聯(lián)，之后，用戶可以在個(gè)人中心修改自己的注冊(cè)頭像，直到注冊(cè)頭像上傳成功為止。

實(shí)操

我們需要先在項(xiàng)目的啟動(dòng)類上，配置 Hystrix 的斷路器：

@EnableHystrix
@EnableHystrixDashboard
@EnableCircuitBreaker
public class UserApplication {

    public static void main(String[] args) {
        SpringApplication.run(UserApplication.class, args);
    }
}

代碼解釋

第 3 行，我們通過(guò)在項(xiàng)目啟動(dòng)類上添加 EnableCircuitBreaker 注解，來(lái)啟動(dòng) Hystrix 的斷路器，這是在真實(shí)項(xiàng)目中使用快速失敗的前提，如果沒(méi)有在項(xiàng)目中打開(kāi)斷路器，則項(xiàng)目中就不會(huì)存在服務(wù)快速失敗的概念。

接著，我們來(lái)配置用戶注冊(cè)頭像上傳服務(wù)：

@RequestMapping("upload_user_icon.do")
@ResponseBody
@HystrixCommand(fallbackMethod = "uploadUserIcon_failed")
public CommonResponse<String> uploadUserIcon(@Param("userIcon") MultipartFile file){
    return userService.uploadUserIcon(file);
}
    
public CommonResponse<String> uploadUserIcon_failed(){
    // 在用戶注冊(cè)頭像上傳失敗后，返回項(xiàng)目臨時(shí)頭像地址，并提示用戶
}

代碼解釋

此段代碼和我們上節(jié)中的服務(wù)容錯(cuò)與降級(jí)的配置相似，唯一不同的是，當(dāng)用戶注冊(cè)頭像上傳服務(wù)無(wú)法正常處理時(shí)，會(huì)訪問(wèn) uploadUserIcon_failed 方法，且返回一個(gè)臨時(shí)的頭像地址，并提示用戶注意。

在經(jīng)過(guò)上述配置之后，當(dāng)用戶注冊(cè)頭像上傳服務(wù)無(wú)法正常處理時(shí)，通過(guò)返回這個(gè)兜底的臨時(shí)頭像地址來(lái)滿足整體的用戶注冊(cè)服務(wù)的業(yè)務(wù)需要，保證了用戶注冊(cè)服務(wù)的繼續(xù)進(jìn)行。

Tips: 我們?cè)诮榻B服務(wù)快速失敗時(shí)，是將普通版本的和斷路器分開(kāi)進(jìn)行的介紹，因?yàn)槭莾蓚€(gè)不同的版本，但是在實(shí)際項(xiàng)目中，往往會(huì)結(jié)合這兩個(gè)版本共同使用，這樣才能充分發(fā)揮服務(wù)快速失敗的作用。

4. 小結(jié)

本小節(jié)以一個(gè)真實(shí)業(yè)務(wù)場(chǎng)景下的服務(wù)，為大家介紹了如何在真實(shí)業(yè)務(wù)場(chǎng)景下配置 Hystrix 的服務(wù)快速失敗，并且做了代碼實(shí)操，針對(duì)容易出現(xiàn)問(wèn)題的地方，也做了注意事項(xiàng)的補(bǔ)充，希望同學(xué)們可以對(duì)真實(shí)業(yè)務(wù)場(chǎng)景下，服務(wù)快速失敗的應(yīng)用方法有所了解。