本發(fā)明屬于計算機(jī)領(lǐng)域，具體涉及一種微服務(wù)架構(gòu)中分布式事務(wù)的處理方法。

背景技術(shù)：

微服務(wù)是近年來興起的一項(xiàng)新的架構(gòu)設(shè)計思想。相較SOA，微服務(wù)通過將功能進(jìn)一步分布式組件化，具有良好的擴(kuò)展性和可持續(xù)開發(fā)能力。微服務(wù)是指開發(fā)一個單個小型的但有業(yè)務(wù)功能的服務(wù)，每個服務(wù)都有自己的處理和輕量通訊機(jī)制，可以部署在單個或多個服務(wù)器上。微服務(wù)也指一種松耦合的、有一定的有界上下文的面向服務(wù)架構(gòu)。也就是說，如果每個服務(wù)都要同時修改，那么它們就不是微服務(wù)，因?yàn)樗鼈兙o耦合在一起；如果需要掌握一個服務(wù)太多的上下文場景使用條件，那么它就是一個有上下文邊界的服務(wù)。微服務(wù)的目的是有效的拆分應(yīng)用，實(shí)現(xiàn)敏捷開發(fā)和部署。

如果說SOA可以通過設(shè)計避免分布式事務(wù)問題，由于服務(wù)拆分粒度更細(xì)，與SOA不同的是，微服務(wù)對于分布式事務(wù)的要求變得不可或缺。比如一個在線支付過程，SOA可能會拆分出一個封裝了支付功能、自行維護(hù)庫存的訂單子系統(tǒng)，將更新商品數(shù)量、修改訂單狀態(tài)、記錄支付費(fèi)用等操作用單機(jī)事務(wù)完成。但是對于微服務(wù)架構(gòu)來說，很可能由于擴(kuò)展性的考慮，拆分成支付模塊、訂單模塊、商品SKU管理模塊。當(dāng)支付成功的通知到來時，需要實(shí)時更新多個模塊的DB數(shù)據(jù)。

技術(shù)實(shí)現(xiàn)要素：

為了解決現(xiàn)有技術(shù)存在的上述問題，本發(fā)明提供了一種微服務(wù)架構(gòu)中分布式事務(wù)的處理方法。

本發(fā)明所采用的技術(shù)方案為：一種微服務(wù)架構(gòu)中分布式事務(wù)的處理方法，其包括以下步驟：開啟DB實(shí)例的單機(jī)事務(wù)；執(zhí)行DB請求，更新DB；請求實(shí)時事務(wù)模塊；對實(shí)時事務(wù)模塊是否請求成功進(jìn)行判斷，如果未請求成功，則觸發(fā)回滾，拋出異常或其他DB驅(qū)動的事務(wù)回滾觸發(fā)事件；如果請求成功，則進(jìn)行提交。

進(jìn)一步地，所述請求實(shí)時事務(wù)模塊的步驟中，至多進(jìn)行一個實(shí)時事務(wù)模塊調(diào)用，如果有多個實(shí)時事務(wù)模塊，則進(jìn)行串聯(lián)調(diào)用。

進(jìn)一步地，所述對實(shí)時事務(wù)模塊是否請求成功進(jìn)行判斷的步驟中，如果請求成功，在進(jìn)行提交之前，還包括插入最終一致性處理模塊的步驟。

進(jìn)一步地，所述對實(shí)時事務(wù)模塊是否請求成功進(jìn)行判斷的步驟中，如果請求成功，在進(jìn)行提交之前，還包括插入最終一致性處理模塊的步驟。

進(jìn)一步地，所述分布式事務(wù)的處理方法采用模塊調(diào)用的拓?fù)浣Y(jié)構(gòu)來處理分布式事務(wù)。

更進(jìn)一步地，所述采用模塊調(diào)用的拓?fù)浣Y(jié)構(gòu)來處理分布式事務(wù)核心設(shè)計規(guī)則包括：一個模塊至多有一次修改類型的RPC調(diào)用，修改類型的RPC調(diào)用無需提供回滾接口。

更進(jìn)一步地，如果單流程有多次修改類型的RPC調(diào)用，同時又要保證整體的實(shí)時一致性，需將RPC調(diào)用串聯(lián)。

更進(jìn)一步地，所述采用模塊調(diào)用的拓?fù)浣Y(jié)構(gòu)來處理分布式事務(wù)核心設(shè)計規(guī)則還包括：RPC接口調(diào)用封裝在DB事務(wù)處理邏輯內(nèi)部，放在DB事務(wù)后面。

更進(jìn)一步地，所述RPC接口調(diào)用失敗或返回失敗后，拋出異常觸發(fā)DB事務(wù)回滾。

更進(jìn)一步地，如果流程中的RPC調(diào)用接受最終一致，則能夠插入隊列，但是必須放在所有調(diào)用流程結(jié)束之后。

由于采用以上技術(shù)方案，本發(fā)明的有益效果為：本發(fā)明有效地利用了DB驅(qū)動模塊的單機(jī)兩階段提交特性，創(chuàng)新地提出了一種利用服務(wù)調(diào)用的拓?fù)浣Y(jié)構(gòu)來實(shí)現(xiàn)分布式事務(wù)的方式，可以用作實(shí)時一致性的解決方案。同時，該方案有很好的延展性，通過另一種拓?fù)浣Y(jié)構(gòu)，也可以實(shí)現(xiàn)最終一致性事務(wù)。本發(fā)明只通過一次交互過程就可以實(shí)現(xiàn)事務(wù)保證，非常適合三個以內(nèi)的分布式模塊實(shí)現(xiàn)事務(wù)機(jī)制。本發(fā)明能夠通過拓?fù)湓O(shè)計明確地表示分布式事務(wù)的處理級別，串聯(lián)即是實(shí)時一致，并聯(lián)即是最終一致。

附圖說明

為了更清楚地說明本發(fā)明實(shí)施例或現(xiàn)有技術(shù)中的技術(shù)方案，下面將對實(shí)施例或現(xiàn)有技術(shù)描述中所需要使用的附圖作簡單地介紹，顯而易見地，下面描述中的附圖僅僅是本發(fā)明的一些實(shí)施例，對于本領(lǐng)域普通技術(shù)人員來講，在不付出創(chuàng)造性勞動的前提下，還可以根據(jù)這些附圖獲得其他的附圖。

圖1是典型的服務(wù)調(diào)用拓?fù)浣Y(jié)構(gòu)示意圖；

圖2是本發(fā)明微服務(wù)架構(gòu)中分布式事務(wù)的處理方法的流程圖；

圖3是各分布式事務(wù)模塊的指令執(zhí)行順序示意圖。

具體實(shí)施方式

為使本發(fā)明的目的、技術(shù)方案和優(yōu)點(diǎn)更加清楚，下面將對本發(fā)明的技術(shù)方案進(jìn)行詳細(xì)的描述。顯然，所描述的實(shí)施例僅僅是本發(fā)明一部分實(shí)施例，而不是全部的實(shí)施例?；诒景l(fā)明中的實(shí)施例，本領(lǐng)域普通技術(shù)人員在沒有做出創(chuàng)造性勞動的前提下所得到的所有其它實(shí)施方式，都屬于本發(fā)明所保護(hù)的范圍。

目前微服務(wù)架構(gòu)作為一種新的設(shè)計方式在世界范圍內(nèi)已被廣泛應(yīng)用。但是其難點(diǎn)之一，便是分布式部署導(dǎo)致的事務(wù)問題。

分布式事務(wù)處理涉及多個分布在不同地方的數(shù)據(jù)庫，但對數(shù)據(jù)庫的操作必須全部被提交或者回滾。只要任一數(shù)據(jù)庫操作時失敗，所有參與事務(wù)的數(shù)據(jù)庫都需要回滾。分布式事務(wù)可以分為實(shí)時一致和最終一致。

目前業(yè)界通用的實(shí)時一致性解決方案有基于兩階段提交或三階段提交的方案。兩階段提交的實(shí)現(xiàn)比如Atomikos庫(實(shí)現(xiàn)了JTA)、JOTM、LIXA。兩階段提交方案在實(shí)際中應(yīng)用比較廣。但是分布式場景與單機(jī)場景不同，處理時間翻倍，原本一次交互過程被劃分為prepare和commit兩次交互，性能差而且有缺點(diǎn)：協(xié)調(diào)者宕機(jī)情況下會導(dǎo)致參與者同步阻塞，需增加協(xié)調(diào)者熱備且記錄undo和redo日志。當(dāng)協(xié)調(diào)者和參與者同時宕機(jī)時，問題無解。

以分布式兩階段提交為例，收到一個事務(wù)請求后，協(xié)調(diào)者發(fā)起第一次協(xié)調(diào)請求prepare，要求全部參與者預(yù)執(zhí)行對應(yīng)的語句。當(dāng)全部反饋成功時，協(xié)調(diào)者將發(fā)起commit請求，要求全部參與者提交事務(wù)。當(dāng)兩步都完成后，事務(wù)處理完成。當(dāng)?shù)谝徊接袇⑴c方反饋失敗時，協(xié)調(diào)者發(fā)起rollback請求，要求全部參與者回滾事務(wù)。

為了解決兩階段提交的問題，XA提出了三階段提交方案。其中，XA是X/Open DTP定義的事務(wù)管理器與數(shù)據(jù)庫之間的接口規(guī)范(即接口函數(shù))。三階段提交通過增加一次canPrepare，并且增加超時來解決兩階段提交的阻塞問題，但是三階段提交方案的交互性能更差。

目前最終一致性的解決方案的主流實(shí)現(xiàn)方式是基于可重試的消息隊列，消費(fèi)者將定期重試直至所有參與方的系統(tǒng)最終實(shí)現(xiàn)數(shù)據(jù)一致。

如圖1所示，本發(fā)明提供了一種微服務(wù)架構(gòu)中分布式事務(wù)的處理方法，其采用模塊調(diào)用的拓?fù)浣Y(jié)構(gòu)來處理分布式事務(wù)，其具體包括以下步驟：

1)開啟DB(DataBase，數(shù)據(jù)庫)實(shí)例的單機(jī)事務(wù)。

2)執(zhí)行DB請求，更新DB。

3)請求實(shí)時事務(wù)模塊。

4)對步驟3)是否請求成功進(jìn)行判斷，如果未請求成功，則觸發(fā)回滾，拋出異常或其他DB驅(qū)動的事務(wù)回滾觸發(fā)事件；如果請求成功，則進(jìn)行提交。

上述步驟3)中，至多進(jìn)行一個實(shí)時事務(wù)模塊調(diào)用，如果有多個實(shí)時事務(wù)模塊，則進(jìn)行串聯(lián)調(diào)用。

上述步驟4)中，如果請求成功，在進(jìn)行提交之前，還包括插入最終一致性處理模塊的步驟。

用拓?fù)浞绞浇鉀Q分布式事務(wù)問題的核心設(shè)計規(guī)則為：

(1)一個模塊至多有一次修改類型的RPC(Remote Procedure Call Protocol，遠(yuǎn)程過程調(diào)用協(xié)議)調(diào)用。修改類型的RPC調(diào)用無需提供回滾接口。

(2)如果單流程有多次修改類型的RPC調(diào)用，同時又要保證整體的實(shí)時一致性，需將RPC調(diào)用串聯(lián)。

(3)RPC接口調(diào)用封裝在DB事務(wù)處理邏輯內(nèi)部，放在DB事務(wù)后面。

(4)RPC接口調(diào)用失敗或返回失敗后，拋出異常觸發(fā)DB事務(wù)回滾。

(5)如果流程中的某些RPC調(diào)用可以接受最終一致(比如結(jié)算對賬等后臺模塊)，可以插入隊列。但是必須放在所有調(diào)用流程結(jié)束之后。

下面舉例對本發(fā)明微服務(wù)架構(gòu)中分布式事務(wù)的處理方法進(jìn)行說明。

將微服務(wù)間的調(diào)用關(guān)系整理成拓?fù)鋱D，用拓?fù)鋱D表示事務(wù)是實(shí)時一致性還是最終一致性。如圖1所示，實(shí)時一致性處理模塊包括分布式事務(wù)模塊A、分布式事務(wù)模塊B和分布式事務(wù)模塊C。最終一致性處理模塊包括分布式事務(wù)模塊D和分布式事務(wù)模塊E。每個事務(wù)模塊均包括DB事務(wù)和RPC請求。

按照如圖2所示方式進(jìn)行調(diào)用，利用DB驅(qū)動的事務(wù)性保證整個處理邏輯的事務(wù)性。分布式事務(wù)模塊A需要修改表a(實(shí)時一致性)，分布式事務(wù)模塊B需要修改表b(實(shí)時一致性)，分布式事務(wù)模塊C需要修改表c(實(shí)時一致性)，分布式事務(wù)模塊D需要修改表d(最終一致性)，分布式事務(wù)模塊E需要修改表e(最終一致性)。

分布式事務(wù)模塊A、分布式事務(wù)模塊B和分布式事務(wù)模塊C需要保證實(shí)時一致，分布式事務(wù)模塊D和分布式事務(wù)模塊E需要保證最終一致。在拓?fù)湓O(shè)計上，依照原則(1)和原則(2)將調(diào)用順序進(jìn)行調(diào)整。分布式事務(wù)模塊A訪問分布式事務(wù)模塊B，分布式事務(wù)模塊B訪問分布式事務(wù)模塊C。依照原則(5)，分布式事務(wù)模塊D和分布式事務(wù)模塊E的訪問放在最后。

如圖3所示，各分布式事務(wù)模塊執(zhí)行指令流程為：

如果分布式事務(wù)模塊A、分布式事務(wù)模塊B和分布式事務(wù)模塊C整體運(yùn)行正常，則分布式事務(wù)提交成功。然后通知分布式事務(wù)模塊D和分布式事務(wù)模塊E，使其最終處理完成即可。

假設(shè)分布式事務(wù)模塊執(zhí)行自身DB入庫操作時失敗，則分布式事務(wù)模塊C回滾本機(jī)事務(wù)，然后返回分布式事務(wù)模塊B一個錯誤碼。分布式事務(wù)模塊B接收到分布式事務(wù)模塊C的返回，發(fā)現(xiàn)是錯誤，也回滾本機(jī)事務(wù)；分布式事務(wù)模塊A拿到分布式事務(wù)模塊B的返回，也回滾本機(jī)事務(wù)，達(dá)到整體回滾。

極端情況下，如果分布式事務(wù)模塊C執(zhí)行成功，但是返回分布式事務(wù)模塊B時失敗(比如分布式事務(wù)模塊C執(zhí)行時間過長，導(dǎo)致TCP連接斷開，或網(wǎng)絡(luò)抖動導(dǎo)致連接斷開)，則會出現(xiàn)問題。分布式事務(wù)模塊C的數(shù)據(jù)庫無法回滾。此時，可以通過增加cache使分布式事務(wù)模塊C的訪問具有冪等性，為分布式事務(wù)模塊B到分布式事務(wù)模塊C增加超時重試。

本發(fā)明提供了一種微服務(wù)架構(gòu)中分布式事務(wù)的處理方法，該方法有效地利用了DB驅(qū)動模塊的單機(jī)兩階段提交特性，創(chuàng)新地提出了一種利用服務(wù)調(diào)用的拓?fù)浣Y(jié)構(gòu)來實(shí)現(xiàn)分布式事務(wù)的方式，可以用作實(shí)時一致性的解決方案。同時，該方案有很好的延展性，通過另一種拓?fù)浣Y(jié)構(gòu)，也可以實(shí)現(xiàn)最終一致性事務(wù)。本發(fā)明只通過一次交互過程就可以實(shí)現(xiàn)事務(wù)保證，非常適合三個以內(nèi)的分布式模塊實(shí)現(xiàn)事務(wù)機(jī)制。本發(fā)明能夠通過拓?fù)湓O(shè)計明確地表示分布式事務(wù)的處理級別，串聯(lián)即是實(shí)時一致，并聯(lián)即是最終一致。

以上所述，僅為本發(fā)明的具體實(shí)施方式，但本發(fā)明的保護(hù)范圍并不局限于此，任何熟悉本技術(shù)領(lǐng)域的技術(shù)人員在本發(fā)明揭露的技術(shù)范圍內(nèi)，可輕易想到變化或替換，都應(yīng)涵蓋在本發(fā)明的保護(hù)范圍之內(nèi)。因此，本發(fā)明的保護(hù)范圍應(yīng)以所述權(quán)利要求的保護(hù)范圍為準(zhǔn)。