Retry & Fallback 是利器還是魔咒?
1. 概覽
在分布式場(chǎng)景中,Retry 和 Fallback 是最常見(jiàn)的容災(zāi)方案。
- Retry 就是在調(diào)用遠(yuǎn)程接口失敗時(shí),Client 主動(dòng)發(fā)起重試請(qǐng)求,以期待獲得最終結(jié)果,從而完成整個(gè)流程
- Fallback 是在調(diào)用遠(yuǎn)程接口失敗時(shí),Client 不進(jìn)行重試而是調(diào)用一個(gè)特殊的 fallback 方法,從這個(gè)方法中獲取結(jié)果,使流程能夠繼續(xù)下去
那 Retry 和 Fallback 該怎么抉擇呢?
1.1. 背景
首先,先看下 Retry 和 Fallback 都是怎么幫助流程進(jìn)行自我恢復(fù)的。
1.1.1. Retry
現(xiàn)在有一個(gè)生產(chǎn)流程:
核心流程如下:
- 從商品服務(wù)中獲取商品信息
- 根據(jù)商品信息創(chuàng)建訂單
- 將訂單保存到數(shù)據(jù)庫(kù)
如果發(fā)生網(wǎng)絡(luò)抖動(dòng),將導(dǎo)致生產(chǎn)失敗。
- 在調(diào)用商品服務(wù)獲取商品時(shí),由于網(wǎng)絡(luò)異常,接口調(diào)用失敗
- 由于無(wú)法獲取商品信息,生產(chǎn)流程被異常中斷
由于上產(chǎn)流程太過(guò)重要,系統(tǒng)需盡最大努力保障用戶能夠完成下單操作,那針對(duì)網(wǎng)絡(luò)抖動(dòng)這個(gè)問(wèn)題,可以通過(guò) Retry 進(jìn)行修復(fù)。
image
- 在第一次獲取商品信息時(shí),由于網(wǎng)絡(luò)問(wèn)題導(dǎo)致獲取失敗
- 系統(tǒng)不會(huì)直接拋出異常,而是在等待一段時(shí)間后,重新發(fā)起第二次請(qǐng)求,也就是 Retry 操作
- 網(wǎng)絡(luò)恢復(fù),第二次請(qǐng)求成功獲取商品信息
- 流程繼續(xù)運(yùn)行,最終完成用戶生產(chǎn)
Retry 機(jī)制非常適合服務(wù)短時(shí)間不可用,或某個(gè)服務(wù)節(jié)點(diǎn)異常 這類場(chǎng)景。
1.1.2. Fallback
一個(gè)生產(chǎn)驗(yàn)證接口,主流程如下:
- 調(diào)用商品服務(wù)的接口獲取商品信息
- 根據(jù)商品和用戶信息判斷用戶是否能夠購(gòu)買該商品
同樣,假設(shè)在訪問(wèn)商品服務(wù)時(shí)出現(xiàn)網(wǎng)絡(luò)異常:
由于無(wú)法獲取商品信息,從而導(dǎo)致整個(gè)驗(yàn)證流程被異常中斷,用戶操作被迫終止。
聰明的你估計(jì)會(huì)說(shuō)那就使用 Retry 呀,是的:
如果是短時(shí)不可用,通過(guò) Retry 機(jī)制便可以恢復(fù)流程。
但,如果是商品服務(wù)壓力過(guò)大,響應(yīng)時(shí)間過(guò)長(zhǎng)呢?比如,商品服務(wù)流量激增,導(dǎo)致 DB CPU 飆升,出現(xiàn)大量的慢 SQL,這時(shí)觸發(fā)了系統(tǒng)的 Retry 會(huì)是怎樣?
image
- 在獲取商品失敗后,系統(tǒng)自動(dòng)觸發(fā) Retry 機(jī)制
- 由于是商品服務(wù)本身出了問(wèn)題,第二次請(qǐng)求仍舊失敗
- 服務(wù)又觸發(fā)了第三次請(qǐng)求,仍未獲取結(jié)果
- 達(dá)到最大重試次數(shù),仍舊無(wú)法獲取商品,只能通過(guò)異常中斷用戶請(qǐng)求
通過(guò) Retry 機(jī)制未能將流程從異常中恢復(fù)過(guò)來(lái),也給下游的 商品服務(wù) 造成了巨大傷害。
- 商品服務(wù)壓力大,響應(yīng)時(shí)間長(zhǎng)
- 上游系統(tǒng)由于超時(shí)觸發(fā)自動(dòng)重試
- 自動(dòng)重試增大了對(duì)商品服務(wù)的調(diào)用
- 商品服務(wù)請(qǐng)求量更大,更難以從故障中恢復(fù)
這就是常說(shuō)的“讀放大”,假設(shè)用戶驗(yàn)證是否能夠購(gòu)買請(qǐng)求的請(qǐng)求量為 n,那極端情況下 商品服務(wù)的請(qǐng)求量為 3n (其中 2n 是由 Retry 機(jī)制造成)
此時(shí),Retry 就不是一個(gè)好的方案。我們先退回業(yè)務(wù)場(chǎng)景進(jìn)行思考,如果無(wú)法獲取商品,驗(yàn)證接口是否可以直接放行,先讓用戶完成購(gòu)買?
如果,這個(gè)業(yè)務(wù)假設(shè)能夠接受的話,那就到了 Fallback 上場(chǎng)的時(shí)候了。
- 調(diào)用商品服務(wù)獲取商品信息失敗
- 系統(tǒng)不會(huì)進(jìn)行重試,而是觸發(fā) fallback 機(jī)制
- fallback 會(huì)調(diào)用指定的一個(gè)方法,并將返回值作為遠(yuǎn)程接口的返回值
- 接下來(lái)的流程使用 fallback 方法的返回值完成業(yè)務(wù)邏輯
1.1.3. 場(chǎng)景思考
同樣是對(duì)商品服務(wù)接口(同一個(gè)接口)的調(diào)用,在不同的場(chǎng)景需要使用不同的策略用以恢復(fù)業(yè)務(wù)流程,通常情況下:
- Command 場(chǎng)景優(yōu)先使用 Retry
- 這種流量極為重要,最好能保障流程的完整性
- 通常寫流量比較小,小范圍 Retry 不會(huì)對(duì)下游系統(tǒng)造成巨大影響
- Query 場(chǎng)景優(yōu)選使用 Fallabck
- 大多數(shù)展示場(chǎng)景,哪怕部分信息沒(méi)有獲取到對(duì)整體的影響也比較小
- 通常讀場(chǎng)景流量較高,Retry 對(duì)下游系統(tǒng)的傷害不容忽視
那面對(duì)一個(gè)遠(yuǎn)程接口被多個(gè)場(chǎng)景使用,我們?cè)撛趺刺幚砟兀?/p>
- 提供兩組接口,一個(gè)具有 Retry 能力,一個(gè)具有 Fallback 能力,由使用方根據(jù)業(yè)務(wù)場(chǎng)景進(jìn)行選擇?
- 還是…
1.2. 目標(biāo)
- 遠(yuǎn)程接口具備 Retry 和 Fallback 能力
- 能夠根據(jù)上下文不同場(chǎng)景,在發(fā)生調(diào)用異常時(shí)動(dòng)態(tài)選擇 Retry 或 Fallback 進(jìn)行流程恢復(fù)
2. 快速入門
2.1. 準(zhǔn)備環(huán)境
項(xiàng)目主要依賴 spring retry 和 lego starter
首先,引入 spring-retry 依賴
此次,引入 lego-starter 依賴
最后新建 RetryConfiguration 以開(kāi)啟 Retry 能力
2.2. 構(gòu)建 ActionTypeProvider
在完成基本配置后,需要準(zhǔn)備一個(gè) ActionTypeProvider 用以提供上下文信息。
ActionTypeProvider 接口定義如下:
通常情況下,我們會(huì)使用 ThreadLocal 組件將 ActionType 存儲(chǔ)于線程上下文,在使用時(shí)從上下中獲取相關(guān)信息。
有了上下文之后,
ActionBasedActionTypeProvider 直接從 Context 中獲取 ActionType 具體如下
上下文中的 ActionType 又是怎么進(jìn)行管理的呢,包括信息綁定和信息清理?
最常用的方式便是:
- 提供一個(gè)注解,在方法上添加注解用于對(duì) ActionType 的配置;
- 提供一個(gè)攔截器,對(duì)方法調(diào)用進(jìn)行攔截。方法調(diào)用前,從注解中獲取配置信息并綁定到上下文;方法調(diào)用后,主動(dòng)清理上下文信息;
核心實(shí)現(xiàn)為:
在這些組件的幫助下,我們只需在方法上基于 @Action 注解進(jìn)行標(biāo)記,便能夠?qū)?ActionType 綁定到上下文。
2.3. 使用 @SmartFault
在將 ActionType 綁定到上下文之后,接下來(lái)要做的便是對(duì) 遠(yuǎn)程接口 進(jìn)行配置。遠(yuǎn)程接口的配置工作主要由 @SmartFault 來(lái)完成。
其核心配置項(xiàng)包括:
配置項(xiàng) | 含義 | 默認(rèn)配置 |
recover | fallback 方法名稱 | |
maxRetry | 最大重試次數(shù) | 3 |
include | 觸發(fā)重試的異常類型 | |
exclude | 不需要重新的異常類型 |
接下來(lái),看一個(gè) demo
測(cè)試代碼如下:
運(yùn)行 retry 測(cè)試,日志如下:
可見(jiàn),當(dāng) action type 為 COMMAND 時(shí):
- 第一次調(diào)用時(shí),觸發(fā)異常,打?。?Error-0
- 此時(shí) SmartFaultExecutor 主動(dòng)進(jìn)行重試,打印: Retry method xxxx
- 方法重試成功,RetryService3 打?。?Success-0
方法主動(dòng)進(jìn)行重試,流程從異常中恢復(fù),處理過(guò)程和效果符合預(yù)期。
運(yùn)行 fallback 測(cè)試,日志如下:
可見(jiàn),當(dāng) action type 為 QUERY 時(shí):
- 第一次調(diào)用時(shí),觸發(fā)異常,打印: Error-0
- SmartFaultExecutor 執(zhí)行 Fallback 策略,打印:recover From ERROR for method xxxx
- 調(diào)用RetryService3的 recover 方法,獲取最終返回值。RetryService3 打?。簉ecover-0
異常后自動(dòng)執(zhí)行 fallback,將流程從異常中恢復(fù)過(guò)來(lái),處理過(guò)程和效果符合預(yù)期。
3. 設(shè)計(jì)&擴(kuò)展
3.1 核心設(shè)計(jì)
image
整體流程如下:
- ActionAspect 從 @Action 中讀取配置信息,將請(qǐng)求類型綁定到線程上下文
- 然后執(zhí)行正常業(yè)務(wù)邏輯
- 當(dāng)調(diào)用 @SmartFault 注解的方法時(shí),會(huì)被 SmartFaultMethodInterceptor 攔截器攔截
- 攔截器通過(guò) ActionTypeProvider 獲取當(dāng)前的 ActionType
- 根據(jù) ActionType 對(duì)請(qǐng)求進(jìn)行路由
- 如果是 COMMAND 操作,將使用 RetryTemplate 執(zhí)行請(qǐng)求,在發(fā)生異常時(shí),通過(guò)重試配置進(jìn)行請(qǐng)求重發(fā),從而最大限度的獲得遠(yuǎn)程結(jié)果
- 如果是 QUERY 操作,將使用 FallbackTemplate(重試次數(shù)為0的 RetryTemplate)執(zhí)行請(qǐng)求,當(dāng)發(fā)生異常時(shí),調(diào)用 fallback 方法,執(zhí)行配置的 recover 方法,直接使用返回結(jié)果
- 獲取遠(yuǎn)程結(jié)果后,執(zhí)行后續(xù)的業(yè)務(wù)邏輯
- 最后,ActionAspect 將 ActionType 從線程上下文中移除
4. 項(xiàng)目信息
項(xiàng)目倉(cāng)庫(kù)地址:https://gitee.com/litao851025/lego
項(xiàng)目文檔地址:https://gitee.com/litao851025/lego/wikis/support/smart-fault