[發(fā)明專利]一種保障微服務調(diào)用數(shù)據(jù)一致性的處理方法、處理裝置

有效

• 申請?zhí)枺?/td>: 201811315384.0
• 申請日: 2018-11-06
• 公開（公告）號: CN109542639B
• 公開（公告）日: 2021-05-11
• 發(fā)明（設計）人: 劉建民
• 申請（專利權(quán)）人: 用友網(wǎng)絡科技股份有限公司
• 主分類號: G06F9/54
• 分類號: G06F9/54
• 代理公司: 北京友聯(lián)知識產(chǎn)權(quán)代理事務所(普通合伙) 11343
• 代理人: 尚志峰;汪海屏

本發(fā)明提出了一種保障微服務調(diào)用數(shù)據(jù)最終一致性的處理方法、處理裝置。其中，處理方法包括：獲取標記信息，根據(jù)標記信息確定開啟或加入的多個全局事務，其中每個全局事務包括一個或多個微服務，且每個全局事務包括的微服務不相同；對于任一全局事務，當檢測到全局事務中存在異常微服務調(diào)用時，處理異常微服務的異常信息，同時將異常信息發(fā)送給異常微服務的上游微服務和下游微服務，使上游微服務進行本地事務回滾和異常信息通知，以及使下游微服務進行本地事務回滾。以隔離事務的管理范圍以及提供異常處理機制，補償錯誤操作的數(shù)據(jù)，使得業(yè)務向前恢復或避免向下發(fā)展，達到數(shù)據(jù)最終一致的效果。

技術領域

本發(fā)明涉及計算機技術領域，具體而言，涉及一種保障微服務調(diào)用數(shù)據(jù)一致性的處理方法、處理裝置。

背景技術

微服務架構(gòu)下多個服務之間通過RestFul接口或者RPC框架進行調(diào)用，一次完整的業(yè)務調(diào)用往往需要多個微服務的參與，包括如圖1和圖2所示的兩種場景，這兩種場景下，如果中途調(diào)用出錯，會造成整體業(yè)務的失敗。此種架構(gòu)下，每個微服務使用獨立的DB(Database，數(shù)據(jù)庫)存儲數(shù)據(jù)，各個業(yè)務的DB間相互隔離，不允許直接跨庫訪問。那么，傳統(tǒng)的使用數(shù)據(jù)庫本地事務ACID(Atomicity Consistency Isolation Durability，原子性、一致性、隔離性、持久性)特性保證數(shù)據(jù)一致的方案不再適用，各個服務間可能由于網(wǎng)絡超時、業(yè)務異常等問題造成不能同步的提交或者回滾對應的數(shù)據(jù)庫操作，造成各個服務對應數(shù)據(jù)的不一致。

相關技術的解決方案中，可以使用全局數(shù)據(jù)庫事務的方式解決此問題，其解決思路如圖3所示，其提供統(tǒng)一的數(shù)據(jù)管理器，在業(yè)務最開始時，各個服務執(zhí)行第一階段，準備各個操作需要資源，開啟事務并執(zhí)行，不提交事務，如遇到異常，事務管理器通知各個業(yè)務回滾，第二階段，事務管理器統(tǒng)一協(xié)調(diào)各個節(jié)點提交事務。此種傳統(tǒng)的全局數(shù)據(jù)庫事務方案，逐步暴露出一些嚴重的問題，例如：(1)同步阻塞問題：執(zhí)行過程中，所有參與節(jié)點都是事務阻塞型的，當參與者占有公共資源時，其他第三方節(jié)點訪問公共資源處于阻塞狀態(tài)；(2)單點問題：由于協(xié)調(diào)者的重要性，一旦協(xié)調(diào)者發(fā)生故障，參與者會一直阻塞下去，尤其在第二階段，協(xié)調(diào)者發(fā)生故障，所有的參與者還都處于鎖定事務資源的狀態(tài)中，而無法繼續(xù)完成事務操作。(3)數(shù)據(jù)不一致：在二階段提交的階段二中，當協(xié)調(diào)者向參與者發(fā)送commit請求之后，發(fā)生了局部網(wǎng)絡異常或者在發(fā)送commit請求過程中協(xié)調(diào)者發(fā)生了故障，導致只有一部分參與者接受到了commit請求，整個分布式系統(tǒng)出現(xiàn)了數(shù)據(jù)部不一致性的現(xiàn)象。同時，XA規(guī)范(資源管理器與事務管理器的接口標準)下的兩階段提交方案，其性能較低，很容易成為互聯(lián)網(wǎng)應用中的瓶頸，所以，全局數(shù)據(jù)庫事務方案在微服務架構(gòu)下的互聯(lián)網(wǎng)應用不太可取。

由此，基于消息或者事件通知的方案應運而生，此方案采用消息中間件或者事件中心的方式，使用消息和事件異步的通知服務提供方執(zhí)行業(yè)務。此種方案避免了跨庫的事務管理問題，但也拋出了一些其他問題。針對消息中間件方案，問題諸如：(1)本地業(yè)務事務和消息發(fā)送任務的一致性問題：各個微服務內(nèi)部，業(yè)務操作使用本地數(shù)據(jù)庫事務控制內(nèi)部的一致性，發(fā)送消息或者接收消息應該在事務的內(nèi)部控制，但是由于網(wǎng)絡延時問題，消息未成功到達或接收，會造成本地事務和消息投遞不一致情況；(2)消息可靠發(fā)送，消息重試和冪等性問題：消息在發(fā)送和接收時，有可能不能一次性成功，會產(chǎn)生重復消息，重復消息的接收會造成業(yè)務重復執(zhí)行，造成數(shù)據(jù)錯誤；(3)消息中間件權(quán)限管理問題：服務基于消息隊列編碼，MQ(Message Queue，消息隊列)中間件需要暴露給服務調(diào)用方，MQ中間件可能由不同的團隊維護，中間件地址和端口、用戶名密碼的直接給多調(diào)用方暴露，不夠安全；(4)報錯事務上報和云端管控問題：本地事務執(zhí)行失敗，需要有統(tǒng)一的云端管控界面，查看和管理全局業(yè)務調(diào)用的情況，進行重試或者分析操作，各個端和云端的數(shù)據(jù)同步是難點問題。

除了上述兩種方案，業(yè)界還推出了TCC(Try Confirm Cancel)事務的最終一致性方案，但此方案對業(yè)務開發(fā)人員的技術要求較高，需要對Try階段進行完善的設計和代碼編寫，業(yè)務侵入性較大，不太容易實施和落地。

發(fā)明內(nèi)容