我們知道，應(yīng)用系統(tǒng)在分布式的情況下，在通信時會有著一個顯著的問題，即一個業(yè)務(wù)流程往往需要組合一組服務(wù)，且單單一次通信可能會經(jīng)過 DNS 服務(wù)，網(wǎng)卡、交換機(jī)、路由器、負(fù)載均衡等設(shè)備，而這些服務(wù)于設(shè)備都不一定是一直穩(wěn)定的，在數(shù)據(jù)傳輸?shù)恼麄€過程中，只要任意一個環(huán)節(jié)出錯，都會導(dǎo)致問題的產(chǎn)生。

這樣的事情在微服務(wù)下就更為明顯了，因為業(yè)務(wù)需要在一致性上的保證。也就是說，如果一個步驟失敗了，要么不斷重試保證所有的步驟都成功，要么回滾到以前的服務(wù)調(diào)用。

因此我們可以對業(yè)務(wù)補償?shù)倪^程進(jìn)行一個定義，即當(dāng)某個操作發(fā)生了異常時，如何通過內(nèi)部機(jī)制將這個異常產(chǎn)生的「不一致」?fàn)顟B(tài)消除掉。

一、關(guān)于業(yè)務(wù)補償機(jī)制

1、什么是業(yè)務(wù)補償

我們知道，應(yīng)用系統(tǒng)在分布式的情況下，在通信時會有著一個顯著的問題，即一個業(yè)務(wù)流程往往需要組合一組服務(wù)，且單單一次通信可能會經(jīng)過 DNS 服務(wù)，網(wǎng)卡、交換機(jī)、路由器、負(fù)載均衡等設(shè)備，而這些服務(wù)于設(shè)備都不一定是一直穩(wěn)定的，在數(shù)據(jù)傳輸?shù)恼麄€過程中，只要任意一個環(huán)節(jié)出錯，都會導(dǎo)致問題的產(chǎn)生。

這樣的事情在微服務(wù)下就更為明顯了，因為業(yè)務(wù)需要在一致性上的保證。也就是說，如果一個步驟失敗了，要么不斷重試保證所有的步驟都成功，要么回滾到以前的服務(wù)調(diào)用。

因此我們可以對業(yè)務(wù)補償?shù)倪^程進(jìn)行一個定義，即當(dāng)某個操作發(fā)生了異常時，如何通過內(nèi)部機(jī)制將這個異常產(chǎn)生的「不一致」?fàn)顟B(tài)消除掉。

2、業(yè)務(wù)補償設(shè)計的實現(xiàn)方式

業(yè)務(wù)補償設(shè)計的實現(xiàn)方式主要可分為兩種：

回滾（事務(wù)補償） ，逆向操作，回滾業(yè)務(wù)流程，意味著放棄，當(dāng)前操作必然會失??；

重試 ，正向操作，努力地把一個業(yè)務(wù)流程執(zhí)行完成，代表著還有成功的機(jī)會。

一般來說，業(yè)務(wù)的事務(wù)補償都是需要一個工作流引擎的。這個工作流引擎把各式各樣的服務(wù)給串聯(lián)在一起，并在工作流上做相應(yīng)的業(yè)務(wù)補償，整個過程設(shè)計成為最終一致性的。

Ps：因為「補償」已經(jīng)是一個額外流程了，既然能夠走這個額外流程，說明時效性并不是第一考慮的因素。所以做補償?shù)暮诵囊c是：寧可慢，不可錯。

二、關(guān)于回滾

“回滾” 是指當(dāng)程序或數(shù)據(jù)出錯時，將程序或數(shù)據(jù)恢復(fù)到最近的一個正確版本的行為。在分布式業(yè)務(wù)補償設(shè)計到的回滾則是通過事務(wù)補償?shù)姆绞剑氐椒?wù)調(diào)用以前的狀態(tài)。

1、顯示回滾

回滾一般可分為 2 種模式：

顯式回滾 ；調(diào)用逆向接口，進(jìn)行上一次操作的反操作，或者取消上一次還沒有完成的操作（須鎖定資源）；

隱式回滾 ：隱式回滾意味著這個回滾動作你不需要進(jìn)行額外處理，往往是由下游提供了失敗處理機(jī)制的。

最常見的就是「顯式回滾」。這個方案無非就是做 2 個事情：

首先要確定失敗的步驟和狀態(tài)，從而確定需要回滾的范圍。一個業(yè)務(wù)的流程，往往在設(shè)計之初就制定好了，所以確定回滾的范圍比較容易。但這里唯一需要注意的一點就是：如果在一個業(yè)務(wù)處理中涉及到的服務(wù)并不是都提供了「回滾接口」，那么在編排服務(wù)時應(yīng)該把提供「回滾接口」的服務(wù)放在前面，這樣當(dāng)后面的工作服務(wù)錯誤時還有機(jī)會「回滾」。

其次要能提供「回滾」操作使用到的業(yè)務(wù)數(shù)據(jù)?！富貪L」時提供的數(shù)據(jù)越多，越有益于程序的健壯性。因為程序可以在收到「回滾」操作的時候可以做業(yè)務(wù)的檢查，比如檢查賬戶是否相等，金額是否一致等等。

2、回滾的實現(xiàn)方式

對于跨庫的事務(wù)，比較常見的解決方案有：兩階段提交、三階段提交（ACID）但是這 2 種方式，在高可用的架構(gòu)中一般都不可取，因為跨庫鎖表會消耗很大的性能。

高可用的架構(gòu)中一般不會要求強一致性，只要達(dá)到最終的一致性就可以了?？梢钥紤]：事務(wù)表、消息隊列、補償機(jī)制、TCC 模式（占位 / 確認(rèn)或取消）、Sagas模式（拆分事務(wù) + 補償機(jī)制）來實現(xiàn)最終的一致性。

三、關(guān)于重試

“重試” 的語義是我們認(rèn)為這個故障是暫時的，而不是永久的，所以，我們會去重試。這個操作最大的好處就是不需要提供額外的逆向接口。這對于代碼的維護(hù)和長期開發(fā)的成本有優(yōu)勢，而且業(yè)務(wù)是變化的。逆向接口也需要變化。所以更多時候可以考慮重試。

1、重試的使用場景

相較于回滾，重試使用的場景要少一些：下游系統(tǒng)返回請求超時，被限流中等臨時狀態(tài)的時候，我們就可以考慮重試了。而如果是返回余額不足，無權(quán)限的明確業(yè)務(wù)錯誤，就不需要重試。一些中間件或者 RPC 框架，返回 503，404 這種沒有預(yù)期恢復(fù)時間的錯誤，也不需要重試了。

2、重試策略

重試的時間和重試的次數(shù)。這種在不同的情況下要有不同的考量，主流的重試策略主要是以下幾種：

策略 1 - 立即重試 ：有時候故障是暫時性的，可能因為網(wǎng)絡(luò)數(shù)據(jù)包沖突或者硬件組件高峰流量等事件造成的，在這種情況下，適合立即重試的操作。不過立即重試的操作不應(yīng)該超過一次，如果立即重試失敗，應(yīng)該改用其他策略；

策略 2 - 固定間隔 ：這個很好理解，比如每隔 5 分鐘重試一次。PS：策略 1 和策略 2 多用于前端系統(tǒng)的交互操作中；

策略 3 - 增量間隔 ：每一次的重試間隔時間增量遞增。比如，第一次 0 秒、第二次 5 秒、第三次 10 秒這樣，使得失敗次數(shù)越多的重試請求優(yōu)先級排到越后面，給新進(jìn)入的重試請求讓路；

return(retryCount-1)*incrementInterval;

策略 4 - 指數(shù)間隔： 每一次的重試間隔呈指數(shù)級增加。和增量間隔一樣，都是想讓失敗次數(shù)越多的重試請求優(yōu)先級排到越后面，只不過這個方案的增長幅度更大一些；

return2^retryCount;

策略 5 - 全抖動： 在遞增的基礎(chǔ)上，增加隨機(jī)性（可以把其中的指數(shù)增長部分替換成增量增長。）適用于將某一時刻集中產(chǎn)生的大量重試請求進(jìn)行壓力分散的場景；

returnrandom(0,2^retryCount);

策略 6 - 等抖動： 在「指數(shù)間隔」和「全抖動」之間尋求一個中庸的方案，降低隨機(jī)性的作用。適用場景和「全抖動」一樣。

intbaseNum=2^retryCount;
returnbaseNum+random(0,baseNum);

策略 - 3、4、5、6 的表現(xiàn)情況大致是這樣（x軸為重試次數(shù)）：

3、重試時的注意事項

首先對于需要重試的接口，是需要做成冪等性的，即不能因為服務(wù)的多次調(diào)用而導(dǎo)致業(yè)務(wù)數(shù)據(jù)的累計增加或減少。

滿足「冪等性」其實就是需要想辦法識別重復(fù)的請求，并且將其過濾掉。思路就是：

給每個請求定義一個唯一標(biāo)識。

在進(jìn)行「重試」的時候判斷這個請求是否已經(jīng)被執(zhí)行或者正在被執(zhí)行，如果是則拋棄該請求。

Ps：此外重試特別適合在高負(fù)載情況下被降級，當(dāng)然也應(yīng)當(dāng)受到限流和熔斷機(jī)制的影響。當(dāng)重試的“矛”與限流和熔斷的“盾”搭配使用，效果才是最好。

四、業(yè)務(wù)補償機(jī)制的注意事項

1、ACID 還是 BASE

ACID 和 BASE 是分布式系統(tǒng)中兩種不同級別的一致性理論，在分布式系統(tǒng)中，ACID有更強的一致性，但可伸縮性非常差，僅在必要時使用；BASE的一致性較弱，但有很好的可伸縮性，還可以異步批量處理；大多數(shù)分布式事務(wù)適合 BASE。

而在重試或回滾的場景下，我們一般不會要求強一致性，只要保證最終一致性就可以了！

2、業(yè)務(wù)補償設(shè)計的注意事項

業(yè)務(wù)補償設(shè)計的注意事項：

因為要把一個業(yè)務(wù)流程執(zhí)行完成，需要這個流程中所涉及的服務(wù)方支持冪等性。并且在上游有重試機(jī)制；

我們需要小心維護(hù)和監(jiān)控整個過程的狀態(tài)，所以，千萬不要把這些狀態(tài)放到不同的組件中，最好是一個業(yè)務(wù)流程的控制方來做這個事，也就是一個工作流引擎。所以，這個工作流引擎是需要高可用和穩(wěn)定的；

補償?shù)臉I(yè)務(wù)邏輯和流程不一定非得是嚴(yán)格反向操作。有時候可以并行，有時候，可能會更簡單?？傊?，設(shè)計業(yè)務(wù)正向流程的時候，也需要設(shè)計業(yè)務(wù)的反向補償流程；

我們要清楚地知道，業(yè)務(wù)補償?shù)臉I(yè)務(wù)邏輯是強業(yè)務(wù)相關(guān)的，很難做成通用的；

下層的業(yè)務(wù)方最好提供短期的資源預(yù)留機(jī)制。就像電商中的把貨品的庫存預(yù)先占住等待用戶在 15 分鐘內(nèi)支付。如果沒有收到用戶的支付，則釋放庫存。然后回滾到之前的下單操作，等待用戶重新下單。

審核編輯：劉清