? ? ? 從業(yè)務(wù)到中臺(tái)，必須經(jīng)歷抽象建模的過(guò)程。這個(gè)過(guò)程分為兩個(gè)階段，分別是 0 級(jí)抽象中心建模的階段和 1 級(jí)抽象組件建模的階段。每個(gè)階段采用的建模抽象機(jī)制都是實(shí)體抽象法。下面以 0 級(jí)階段建模抽象為例進(jìn)行說(shuō)明。首先，我們梳理出企業(yè)功能需求，如某飲料企業(yè)的功能需求匯總表如下圖所示。

? ? ? 其次，找出每一個(gè)功能需求所對(duì)應(yīng)的業(yè)務(wù)對(duì)象或?qū)嶓w。這一步需要?jiǎng)冸x功能的差異性，抽象功能的共同點(diǎn)，才能保證定義合理。實(shí)體分為兩類：業(yè)務(wù)實(shí)體（叫“靜態(tài)實(shí)體”更容易理解）和過(guò)程實(shí)體。實(shí)體性質(zhì)相同或者實(shí)體結(jié)構(gòu)相似度較高，都可歸納為同一實(shí)體。在實(shí)體基礎(chǔ)上，為了滿足當(dāng)前功能需求，我們需要定義出系統(tǒng)需要提供的能力。能力就是對(duì)實(shí)體施加的操作或發(fā)出的命令，這里的能力我們稱為領(lǐng)域能力。最后，根據(jù)能力的主題、實(shí)體的密切關(guān)系，定義出主題域（也可以稱為“業(yè)務(wù)域”）。業(yè)務(wù)域的命名一般由資深業(yè)務(wù)架構(gòu)師來(lái)定義，以避免出現(xiàn)二義性。基于功能需求的抽象，輸出的產(chǎn)物見(jiàn)下表。

? ? ? 劃分出多個(gè)主題域后，技術(shù)架構(gòu)師需要結(jié)合技術(shù)的實(shí)現(xiàn)，將領(lǐng)域進(jìn)行組合規(guī)劃出中心。中心的劃分標(biāo)準(zhǔn)主要從實(shí)體的聚合度、中心的職責(zé)、中心顆粒度、能否獨(dú)立運(yùn)營(yíng)等方面來(lái)權(quán)衡。確定中心的過(guò)程也就是劃定功能邊界的過(guò)程。下圖是某企業(yè)的中心劃分結(jié)果。

? ? ? 業(yè)務(wù)中臺(tái)是一個(gè)充滿生命力的個(gè)體，它承載業(yè)務(wù)邏輯、沉淀業(yè)務(wù)數(shù)據(jù)、產(chǎn)生業(yè)務(wù)價(jià)值，并隨著業(yè)務(wù)不斷發(fā)展進(jìn)化。它的設(shè)計(jì)遵循如下圖所示的 8 個(gè)原則。

? ? ? 一、分布式運(yùn)行機(jī)制?

? ? ? 1.服務(wù)松耦合原則?

? ? ? （1）面向接口實(shí)現(xiàn)這是服務(wù)松耦合的基本要求，即每一個(gè)服務(wù)都按接口的定義進(jìn)行實(shí)現(xiàn)。服務(wù)的消費(fèi)方不需要依賴某個(gè)特定的服務(wù)實(shí)現(xiàn)，避免服務(wù)提供方的內(nèi)部變更影響到消費(fèi)方。另外，在服務(wù)提供方切換到其他系統(tǒng)時(shí)，不影響服務(wù)消費(fèi)方的正常運(yùn)行。

? ? ? （2）異步事件解耦服務(wù)間的事件通信采用異步消息隊(duì)列來(lái)實(shí)現(xiàn)。由于有消息隊(duì)列這個(gè)中介，因此生產(chǎn)者和消費(fèi)者不必在同一時(shí)間都保持實(shí)時(shí)處理能力，而且消費(fèi)生產(chǎn)者也不需要馬上等到回復(fù)。

? ? ? （3）服務(wù)提供者位置解耦服務(wù)消費(fèi)者不需要直接了解服務(wù)提供者的具體位置信息，例如 IP 地址、端口。典型解決方法是服務(wù)注冊(cè)中心，服務(wù)提供者啟動(dòng)時(shí)將自己注冊(cè)到服務(wù)注冊(cè)中心，服務(wù)消費(fèi)者通過(guò)服務(wù)注冊(cè)中心查找具體服務(wù)提供者來(lái)訪問(wèn)。同時(shí)，服務(wù)注冊(cè)中心可以提供負(fù)載均衡及 fail-over 的能力。

? ? ? （4）版本松耦合消費(fèi)端不需要依賴服務(wù)契約的某個(gè)特定版本來(lái)工作，這就要求服務(wù)契約在升級(jí)時(shí)盡可能提供向下兼容性。

? ? ? 2.服務(wù)依賴原則?

? ? ? （1）有價(jià)值的領(lǐng)域模型 價(jià)值導(dǎo)向：確保業(yè)務(wù)中心的服務(wù)都與企業(yè)的商業(yè)理想保持一致，相關(guān)聯(lián)。 簡(jiǎn)捷為美：業(yè)務(wù)邏輯和流程避免復(fù)雜化。 領(lǐng)域洞察：緊貼業(yè)務(wù)的核心目的，從業(yè)務(wù)原則指導(dǎo)業(yè)務(wù)邏輯的設(shè)計(jì)。?

? ? ? （2）服務(wù)間最小依賴 高內(nèi)聚：同一類服務(wù)應(yīng)歸在一起。 低耦合：服務(wù)間保持最小聯(lián)系。 能力與接口：業(yè)務(wù)流程和業(yè)務(wù)邏輯的操作都作為中心服務(wù)實(shí)現(xiàn)，而提供給外部調(diào)用的接口數(shù)據(jù)模型都會(huì)轉(zhuǎn)化為服務(wù)。 識(shí)別通用性：識(shí)別出每個(gè)通用能力的可擴(kuò)展的類型，從設(shè)計(jì)上支持它不斷擴(kuò)展，并在接口定義上滿足其不斷升級(jí)的需求。

? ? ???（3）能力實(shí)體具有層次性 能力與接口：分離接口實(shí)體與能力實(shí)體。 接口實(shí)體與限定元素：將接口實(shí)體核心元素與接口操作的限定元素分離。 接口實(shí)體的層次結(jié)構(gòu)：建設(shè)接口實(shí)體和上下文限定元素的層次結(jié)構(gòu)。?

? ? ? （4）延遲對(duì)技術(shù)組件的依賴

? ? ? 捆綁依賴：避免在無(wú)關(guān)的技術(shù)組件之間引入新的依賴。

? ? ? 延遲綁定：在使用點(diǎn)才捆綁依賴關(guān)系。

? ? ? 3.服務(wù)設(shè)計(jì)原則?

? ? ? （1）優(yōu)化遠(yuǎn)程調(diào)用服務(wù)間的遠(yuǎn)程調(diào)用分為同步調(diào)用和異步調(diào)用兩種模式。應(yīng)當(dāng)分析服務(wù)調(diào)用場(chǎng)景，選擇較優(yōu)的調(diào)用模式。

? ? ? （2）去掉冗余數(shù)據(jù)盡量去掉接口實(shí)體中客戶端不需要的冗余字段，既能減少網(wǎng)絡(luò)開(kāi)銷，又能避免給前端解析帶去復(fù)雜性。

? ? ? （3）設(shè)計(jì)粗粒度的服務(wù)接口服務(wù)接口若能與前端一個(gè)用例或一個(gè)業(yè)務(wù)場(chǎng)景相對(duì)應(yīng)（粒度較粗），則既能減少遠(yuǎn)程調(diào)用次數(shù)，又能降低學(xué)習(xí)成本。

? ? ? （4）識(shí)別并設(shè)計(jì)通用的服務(wù)接口由于中心服務(wù)不限定應(yīng)用范圍，因此一般要支持不同的應(yīng)用。但不同應(yīng)用在功能豐富性上有很大差異，這就決定了服務(wù)接口需要盡可能保證廣泛兼容性。譬如，服務(wù)接口的參數(shù)和返回值必須是被廣泛支持的較簡(jiǎn)單的數(shù)據(jù)類型。

? ? ? （5）隔離服務(wù)內(nèi)部的變化避免服務(wù)內(nèi)部的領(lǐng)域模型直接傳導(dǎo)給客戶端。如未能提供合理的隔離措施，則當(dāng)服務(wù)進(jìn)行內(nèi)部重構(gòu)時(shí)，勢(shì)必導(dǎo)致客戶端頻繁變化。

? ? ? （6）服務(wù)接口先行詳細(xì)規(guī)定服務(wù)與客戶端雙方對(duì)接的內(nèi)容與形式等，對(duì)雙方形成強(qiáng)有力的約束和保障。

? ? ? （7）服務(wù)接口向下兼容由于應(yīng)用的廣泛性，在服務(wù)公開(kāi)發(fā)布之后就要保證相當(dāng)?shù)姆€(wěn)定性，不能隨便重構(gòu)，即使升級(jí)也要盡可能考慮向下兼容性。

? ? ? 4.服務(wù)命名原則?

? ? ? 強(qiáng)烈建議使用服務(wù)使用者專業(yè)領(lǐng)域內(nèi)有意義的名稱，優(yōu)先選用業(yè)務(wù)概念而不是技術(shù)概念。使用名詞命名服務(wù)，使用動(dòng)詞命名操作。

? ? ? 5.服務(wù)顆粒度原則?

? ? ? 服務(wù)應(yīng)是內(nèi)聚而完整的，能夠獨(dú)立完成一個(gè)職責(zé)。在服務(wù)內(nèi)部可以是由多個(gè)邏輯上密切相關(guān)的代碼塊共同組成。

? ? ? 6.服務(wù)的無(wú)狀態(tài)性原則?

? ? ?微服務(wù)體系的基本要求是服務(wù)無(wú)狀態(tài)。無(wú)狀態(tài)的服務(wù)是可伸縮、高可用性的基礎(chǔ)。

? ? ? 7.服務(wù)操作設(shè)計(jì)原則?

? ? ? 操作表示業(yè)務(wù)動(dòng)作，應(yīng)當(dāng)使用具體的業(yè)務(wù)含義而不是泛型操作來(lái)定義操作。相關(guān)的最佳實(shí)踐如下：

• 重要的服務(wù)不能依賴非重要服務(wù)。
• 任何服務(wù)調(diào)用都要設(shè)定超時(shí)時(shí)間。
• 任何服務(wù)的調(diào)用結(jié)果只有三種可能：成功、失敗或未知。
• 能異步調(diào)用的服務(wù)盡量使用異步調(diào)用，從而提高系統(tǒng)響應(yīng)速度，降低系統(tǒng)之間的耦合性。
• 系統(tǒng)拆分時(shí)，粒度大小以一個(gè)系統(tǒng) 3～8 個(gè)開(kāi)發(fā)人員維護(hù)為宜。
• 系統(tǒng)拆分時(shí)，往往先拆分?jǐn)?shù)據(jù)服務(wù)層，因?yàn)閿?shù)據(jù)服務(wù)層通常是復(fù)用性高的一層。
• 服務(wù)的實(shí)現(xiàn)不能有單點(diǎn)。
• 線上遵循 fast-fail 原則，避免服務(wù)調(diào)用時(shí)間過(guò)長(zhǎng)，導(dǎo)致性能下降。fast-fail 原則是只要發(fā)生錯(cuò)誤，則調(diào)用立即返回。
• 需要對(duì)高壓場(chǎng)景下的服務(wù)調(diào)用鏈路進(jìn)行特殊處理，可采用將鏈路縮短、預(yù)熱等方式。
• 服務(wù)設(shè)計(jì)過(guò)程中，要避免同類服務(wù)由不同服務(wù)單元提供。
• 服務(wù)要做到向后兼容，如果無(wú)法做到，則需要采取管控機(jī)制確保服務(wù)消費(fèi)者升級(jí)服務(wù)。
• 服務(wù)化架構(gòu)的變化要使組織的架構(gòu)能適應(yīng)這種變化。
• 在部署服務(wù)單元時(shí)，要將讀服務(wù)和寫服務(wù)分離，將核心服務(wù)和非核心服務(wù)分離，以保證整個(gè)服務(wù)單元的穩(wěn)定性和可靠性。
• 服務(wù)化時(shí)，要同時(shí)考慮安全。
• 靜態(tài)資源也可以實(shí)現(xiàn)服務(wù)化，實(shí)現(xiàn)靜態(tài)資源與動(dòng)態(tài)資源分離，從而提高性能。
• 通過(guò)在外層系統(tǒng)埋點(diǎn)，可以實(shí)現(xiàn)面向終端用戶服務(wù)的精細(xì)管理，比如服務(wù)的容量、服務(wù)的性能等。
• 需要將每個(gè)業(yè)務(wù)領(lǐng)域的通用規(guī)則沉淀成服務(wù)。

? ? ? 8.服務(wù)約束原則 上可依賴下。?

? ? ? 下不可依賴上。 上可跨級(jí)依賴下。 平級(jí)可允許單向調(diào)用，堅(jiān)決禁止循環(huán)依賴。 高級(jí)別不可依賴低級(jí)別。 簡(jiǎn)單就是美。 重要的服務(wù)不能依賴非重要服務(wù)。?

? ? ? 二、分布式運(yùn)行機(jī)制?

? ? ? 中臺(tái)采用微服務(wù)風(fēng)格進(jìn)行建設(shè)，每一個(gè)業(yè)務(wù)中心都是獨(dú)立部署的，因此分布式運(yùn)行機(jī)制是保障業(yè)務(wù)中臺(tái)正常運(yùn)行的基礎(chǔ)。無(wú)狀態(tài)的微服務(wù)易于擴(kuò)展和部署，對(duì)彈性伸縮、灰度發(fā)布等互聯(lián)網(wǎng)場(chǎng)景有良好的支持。同時(shí)微服務(wù)架構(gòu)也帶來(lái)了復(fù)雜性，一個(gè)微服務(wù)應(yīng)用一般由多個(gè)服務(wù)組成，每個(gè)服務(wù)又有多個(gè)實(shí)例，因此一套中臺(tái)系統(tǒng)部署上線后，至少有幾十個(gè)節(jié)點(diǎn)提供服務(wù)。為了管理眾多的微服務(wù)，我們需要解決諸如如何使配置一致、如何實(shí)時(shí)監(jiān)控、如何發(fā)現(xiàn)新服務(wù)、錯(cuò)誤如何定位等問(wèn)題。

? ? ? 1.服務(wù)注冊(cè)與發(fā)現(xiàn)?

? ? ? 服務(wù)注冊(cè)是服務(wù)發(fā)現(xiàn)機(jī)制的核心，服務(wù)實(shí)例將自己的服務(wù)信息（包括網(wǎng)絡(luò) IP、端口、服務(wù)名）注冊(cè)到服務(wù)注冊(cè)中心，服務(wù)注冊(cè)中心將服務(wù)信息以及服務(wù)健康狀態(tài)通過(guò) API 暴露出來(lái)。服務(wù)消費(fèi)方通過(guò)注冊(cè)中心獲取到服務(wù)實(shí)例信息，并通過(guò) IP、端口、服務(wù)名的組合去請(qǐng)求服務(wù)提供方提供的服務(wù)。除了完成以上核心功能外，服務(wù)注冊(cè)與發(fā)現(xiàn)還需要實(shí)時(shí)監(jiān)控服務(wù)實(shí)例的健康狀態(tài)，一旦服務(wù)實(shí)例不可用，將通知各服務(wù)消費(fèi)方移除無(wú)效服務(wù)實(shí)例。另外，一個(gè)服務(wù)可能存在多個(gè)服務(wù)實(shí)例，需要根據(jù)不同的負(fù)載均衡算法來(lái)保持服務(wù)調(diào)用的均衡。

? ? ? 2.彈性伸縮?

? ? ? 在分布式集群里通過(guò)服務(wù)探針，可以監(jiān)控應(yīng)用和服務(wù)容器的狀態(tài)，自動(dòng)調(diào)整服務(wù)實(shí)例的數(shù)量。擴(kuò)容，在監(jiān)控到服務(wù)容器出現(xiàn)瓶頸，包括負(fù)載、CPU、RT 指標(biāo)都出現(xiàn)緊張時(shí)，能夠自動(dòng)增加應(yīng)用實(shí)例到集群中。縮容，在監(jiān)控到服務(wù)容器負(fù)載減少出現(xiàn)資源浪費(fèi)時(shí)，自動(dòng)釋放服務(wù)實(shí)例減少成本。調(diào)整彈性伸縮的規(guī)則支持用戶靈活配置。

? ? ? 3.限流降級(jí)?

? ? ? 在互聯(lián)網(wǎng)應(yīng)用場(chǎng)景下，用戶的訪問(wèn)并不總是均勻平穩(wěn)的，時(shí)常會(huì)出現(xiàn)瞬時(shí)的高峰，比如活動(dòng)期間。分布式應(yīng)用服務(wù)需要提供限流功能，時(shí)刻感知流量的變化，并做出相應(yīng)調(diào)整。限流的策略可分為限制訪問(wèn)的絕對(duì)數(shù)量和控制流速（整流）。整流的算法有令牌桶算法，限制總數(shù)可通過(guò)設(shè)置規(guī)則來(lái)實(shí)現(xiàn)。降級(jí)是指某個(gè)服務(wù)被調(diào)低級(jí)別后，本服務(wù)的消費(fèi)者在調(diào)用時(shí)即刻返回失敗，這樣服務(wù)實(shí)例將不會(huì)被調(diào)用。當(dāng)然，也可以設(shè)置一個(gè)默認(rèn)返回值。降級(jí)的規(guī)則支持用戶靈活配置。

? ? ? 4.灰度發(fā)布

? ? ? ?灰度發(fā)布的技術(shù)用于兩個(gè)不同版本同時(shí)在線上并行的情形，既可用于業(yè)務(wù)試錯(cuò)，也可用于版本發(fā)布。一旦確認(rèn)新版本達(dá)到目的，就可以平滑地從舊版本切換到新版本上。灰度發(fā)布需要解決兩個(gè)方面的問(wèn)題，才能順利達(dá)成目的。

? ? ? （1）多版本部署多版本部署分為客戶端部署和服務(wù)端部署兩個(gè)方面。客戶端如果是原生系統(tǒng)，可以用熱更新技術(shù)實(shí)現(xiàn)，比如 Android 的 CodePush。客戶端如果是 H5，則需要在服務(wù)器端部署一套 CSS 和頁(yè)面。服務(wù)端部署要求應(yīng)用服務(wù)、中臺(tái)服務(wù)都要單獨(dú)部署一套，通過(guò)版本來(lái)區(qū)分。如果需要對(duì) MQ 的數(shù)據(jù)消費(fèi)進(jìn)行隔離，則需要重新定義 Topic 或 Tag。

? ? ? （2）流量切分流量切分包括入口流量切分和中臺(tái)服務(wù)流量切分。入口流量的切分策略通常包括按服務(wù)器權(quán)重、IP 地址段或用戶標(biāo)簽等來(lái)切分流量。中臺(tái)服務(wù)流量切分通過(guò)分布式服務(wù)發(fā)現(xiàn)機(jī)制，植入流量切分規(guī)則，控制流量的方向。

? ? ? 5. 消息隊(duì)列服務(wù)?

? ? ? 消息隊(duì)列服務(wù)是互聯(lián)網(wǎng)應(yīng)用場(chǎng)景下非常重要的一個(gè)技術(shù)中間件。在業(yè)務(wù)上，通過(guò)消息隊(duì)列既可以提高用戶體驗(yàn)，又可以支撐 IM 業(yè)務(wù)等；在技術(shù)上既可以解耦系統(tǒng)，又可以削峰填谷等。消息隊(duì)列具有高性能、高可用、最終一致性等技術(shù)特點(diǎn)，是技術(shù)架構(gòu)的重要組成部分。

? ? ? （1）異步通信消息發(fā)送方將耗時(shí)較長(zhǎng)且無(wú)須實(shí)時(shí)處理的操作封裝為消息，發(fā)送給消息隊(duì)列服務(wù)。發(fā)送方無(wú)須等待消息被消費(fèi)方處理完成，可以繼續(xù)做其他事情。消費(fèi)方則可以按自己的節(jié)奏完成消息的消費(fèi)。異步通信可用于系統(tǒng)間的解耦，各系統(tǒng)獨(dú)立自主，互不影響；也可用于減少請(qǐng)求響應(yīng)時(shí)間，提升用戶體驗(yàn)。

? ? ? （2）高可用消息隊(duì)列服務(wù)以集群的方式部署，常見(jiàn)的有 1 主多備或 2 主 2 備等。消息服務(wù)接收到消息后，會(huì)同時(shí)分發(fā)給多個(gè)備份服務(wù)各自創(chuàng)建一個(gè)備份。當(dāng)一臺(tái)消息隊(duì)列服務(wù)掛掉后，另一臺(tái)消息備份服務(wù)可以無(wú)縫對(duì)接，及時(shí)提供服務(wù)。在 RPC 調(diào)用方面，提供了負(fù)載均衡、服務(wù)注冊(cè)與發(fā)現(xiàn)功能，保證了消息隊(duì)列服務(wù)在高并發(fā)場(chǎng)景下的高可用。

? ? ? （3）高可靠消息隊(duì)列服務(wù)提供了極高的可靠性，不過(guò)應(yīng)用開(kāi)發(fā)時(shí)還需要統(tǒng)一提供 retry 機(jī)制，進(jìn)一步提高可靠性，降低應(yīng)用開(kāi)發(fā)的復(fù)雜性。消息隊(duì)列服務(wù)在收到消息后，會(huì)立即執(zhí)行消息的持久化處理。比較常見(jiàn)的持久化方式包括存儲(chǔ)到文件和存儲(chǔ)到數(shù)據(jù)庫(kù)兩種。持久化機(jī)制包括同步雙寫和異步復(fù)制，保證了數(shù)據(jù)的高可靠性。

? ? ? （4）基于消息的最終一致性使用半消息技術(shù)，保證只要一個(gè)事件發(fā)生后，關(guān)聯(lián)的結(jié)果事件一定會(huì)發(fā)生。半消息解決了如下問(wèn)題：

? ? ? 事件發(fā)生后，事件消息發(fā)送卻失敗；

? ? ? 事件消息發(fā)送成功后，消息代理推送給消息消費(fèi)方卻失敗；

? ? ? 消費(fèi)方重復(fù)消費(fèi)此消息。

? ? ? 使用半消息技術(shù)，在事件發(fā)生前，先成功發(fā)送一個(gè)半消息，這樣就保證了事件發(fā)生的消息一定能夠發(fā)送成功。消息代理增加了事件結(jié)果查詢功能，保證了事件觸發(fā)成功后一定將消息推送給消費(fèi)方。消息代理保證消息推送至少 1 次，但要求消費(fèi)方自己實(shí)現(xiàn)冪等性，避免出現(xiàn)異常。冪等性的保證，可以通過(guò)為每一個(gè)事件創(chuàng)建唯一 ID，消費(fèi)方增加一個(gè)過(guò)濾服務(wù)，每處理一個(gè)事件都會(huì)通過(guò)存儲(chǔ)這個(gè)事件 ID 來(lái)實(shí)現(xiàn)。當(dāng)消費(fèi)方收到事件消息后，過(guò)濾服務(wù)會(huì)查詢本事件 ID 是否已經(jīng)消費(fèi)過(guò)。

? ? ? 6.分布式事務(wù)

? ? ? ? 分布式事務(wù)技術(shù)（DTP）用于保證跨多個(gè)資源事務(wù)的一致性，目前 X/Open XA 標(biāo)準(zhǔn)已由眾多廠家實(shí)現(xiàn)來(lái)支持分布式事務(wù)。DTP 模型的典型應(yīng)用場(chǎng)景是兩階段提交協(xié)議，多個(gè)資源管理器（RM）由一個(gè)事務(wù)管理器（TM）進(jìn)行管理，事務(wù)管理器控制著全局事務(wù)和分支事務(wù)。DTP 模型分別通過(guò)準(zhǔn)備階段和提交階段來(lái)協(xié)作完成全局事務(wù)：準(zhǔn)備階段，由 TM 通知各 RM 準(zhǔn)備事務(wù)，并接收 RM 的準(zhǔn)備結(jié)果；提交階段，由 TM 通知各 RM 提交分支事務(wù)，并接收 RM 的執(zhí)行結(jié)果。RM 執(zhí)行結(jié)果都成功，那么 TM 返回成功，如果任意一個(gè) RM 執(zhí)行失敗，原則上 TM 都會(huì)執(zhí)行回滾。但在實(shí)踐過(guò)程中，RM 失敗的情況也有不同，TM 可按照客戶的需要判定是否回滾所有事務(wù)。目前，各大云廠商都提供了分布式全局事務(wù)，其中阿里云的 GTS 已經(jīng)實(shí)現(xiàn)了分布式全局事務(wù)。在應(yīng)用場(chǎng)景涉及的系統(tǒng)和步驟不是特別多的情況下，GTS 可以方便快速地實(shí)現(xiàn)分布式事務(wù)。