背景

隨著微服務化的系統越來越多，系統間的互動也呈現幾何倍增的趨勢，系統間面臨一致性問題越來越突出。為了保障服務提供方與服務消費方的一致性，特別是面臨最大努力通知型或補償性的技術需求，服務化前做法是服務提供方需手寫重試策略及各種配置->持久化訊息->定時去處理訊息等。它帶來的以下問題是：
1.客戶端(新微服務)要做的重複性工作越來越多？需每個開發者熟悉它，去實現它；
2.這個為什麼這樣個性化？標準不統一，出錯率上升；
3.說好的快速響應呢？我要做的狠簡單，最好一行程式碼就可以實現它；
4.維護成本上升；

接入須知

執行環境

• spring3.2.12(內部大多系統使用);
• springcloud Brixton系列(新系統)；

客戶端與服務端遵循規約

• 接入系統(服務消費方)retry的程式碼塊的顆粒度要求，但凡發起的remote呼叫，可獨立為一個方法，方法內不允許有前置或後置處理，確保粒度控制在遠端呼叫領域；
• 服務呼叫方的介面需滿足冪等性設計；
• 接入系統(服務消費方)，為了避免理解有歧義，使用範圍更規範，retry的作用於僅限於RetryCallable規約介面的實現方

功能特性

retry-client

1. 全域性開關，可配置自動掃描並注入；

2. 重試配置級別定義，支援類級和方法級(存在優先順序)；

3. 重試配置項支援：

   • include：支援的異常，型別：Class<? extends Throwable>[]
   • execPolicy：執行策略，默認同步
   • maxAttempts：重試次數，預設為3
   • delay：延遲執行毫秒數，預設為0
   • multiplier：重試執行間隔，預設為0
   • recoverMethod:回退的方法，重試失敗後執行的方法，預設為null
   • callbackUrl：回撥的url(相對url)，預設為null，不支援回撥
   • isSendQueue:是否傳送佇列，預設true
   • ..

4. 同步策略，支援阻塞一直到成功或失敗(最大次數)；

5. 非同步策略，首次失敗後，直接返回客戶端(需處理中間狀態)，後續一直重試，成功則回撥；

6. 回撥支援，主要是針對非同步策略，客戶端需提供回撥介面；

7. 回退支援，可自定義通常達到最大次數後執行；

8. 重試失敗訊息落地，支援傳送MQ

retry-server

1. 消費訊息並落地；
2. 定時處理庫存中的請求，直到成功；
3. 可根據errorcode進行配置終止重試；
4. 成功時支援回撥；
5. 失敗時傳送簡訊和郵件給系統責任人
6. 實現報表統計功能，可以展示top10介面呼叫失敗後重試的情況

尚未實現

1. retry-server 在執行重試或回撥時，目標服務需提供無狀態介面(不攜帶cookie)，對身份授權有依賴需關注；
2. retry-server 執行重試間隔暫時不按照retry-client宣告的定義，它統一集中化配置在專案中；
3. retry-client 目前僅限於發起的esb，feign(springcloud)呼叫，至於要支援各種業務程式碼方法的重試（遠端方面需慎重考慮）

設計要求

• 無侵入：不改動當前的業務邏輯，對於需要重試的地方，可以很簡單的實現；
• 通用性：可自定義包括重試次數，重試的間隔時間，是否使用非同步方式等配置；
• 拓展性：關鍵實現的可替換(SPI)，同時API設計滿足開放閉合原則；
• 健壯性：可監聽所以關鍵的實現，便於排查問題，支援各種異常情況的處理，支援當前springcloud及spring3.x版本系列的接入；

具體實現

元件設計

互動時序

資料模型

核心實現

主要調研了2款開源元件，spring-retry和guava-retry，從實現上來看2款基本上都可以滿足當下的需求。但最後還是選擇spring-retry，為何沒選擇guava-retry呢？首先講，它不是不好，而是功能特性太單一(10分鐘就可以讀懂原始碼)、多例項的實現(每個method都要一個Retryer)，改造成本不小。
spring-retry源於spring-batch，功能非常強大，還有熔斷機制，拓展性強，下面介紹它的一些元件：

• RetryTemplate：包含execute，有沒有種很熟悉的感覺，想想JdbcTemplate....
• RetryListener: aop切中它包含的方法，就會執行它的監聽
• RetryConfiguration：定義了切面和通知，它包含AnnotationAwareRetryOperationsInterceptor
• AnnotationAwareRetryOperationsInterceptor：它其實就是個MethodInterceptor①實現，它invoke主要構建RetryTemplate並執行execute，說起來簡單。但它又稍微對其進行了封裝，根據註解宣告，可以利用StatelessRetryInterceptorBuilder、StatefulRetryInterceptorBuilder、StatelessRetryInterceptorBuilder生成不同MethodInterceptor②的目標執行方法。最後再強調①的職責解析retry註解，並生成對應的②的例項，②的職責是執行真實的呼叫，並執行retry（注：②未必一定要定義為MethodInterceptor，其實可以把它看做一種規約而非AOP實現）。
• 最後，我們的核心實現上，如果定製化高改造①，如果定製化不高可以①->③(新增個性化)->②

快速開始

配置介紹

包含註解的說明，回撥Api的設計

可拓展實現

示例程式