1. 從“雞同鴨講”到“同頻共振”為什么我們需要UML交互圖在軟件開(kāi)發(fā)的日常里最讓人頭疼的場(chǎng)景之一莫過(guò)于幾個(gè)開(kāi)發(fā)人員圍在一起對(duì)著一個(gè)復(fù)雜的功能模塊“各說(shuō)各話”。前端說(shuō)“我發(fā)個(gè)請(qǐng)求你那邊處理一下然后給我個(gè)狀態(tài)碼?！焙蠖苏f(shuō)“你發(fā)過(guò)來(lái)我得先校驗(yàn)再查庫(kù)可能還要調(diào)個(gè)外部服務(wù)最后才能給你?！睖y(cè)試說(shuō)“那中間如果超時(shí)了或者參數(shù)不對(duì)你們倆怎么交互的”產(chǎn)品經(jīng)理在一旁聽(tīng)得云里霧里最后只能弱弱地問(wèn)一句“所以這個(gè)功能到底是怎么跑的”這種“雞同鴨講”的局面根源在于大家對(duì)同一個(gè)業(yè)務(wù)流程中對(duì)象之間如何傳遞消息、以何種順序協(xié)作缺乏一個(gè)清晰、統(tǒng)一且可視化的共識(shí)。文字描述冗長(zhǎng)且易產(chǎn)生歧義口頭交流更是轉(zhuǎn)瞬即逝。這時(shí)候UML交互圖的價(jià)值就凸顯出來(lái)了。它就像是為這場(chǎng)混亂的討論提供了一張動(dòng)態(tài)的、時(shí)序的“作戰(zhàn)地圖”讓所有參與者都能清晰地看到在完成某個(gè)特定用例或操作時(shí)系統(tǒng)內(nèi)部各個(gè)“活”的組成部分對(duì)象是如何“動(dòng)”起來(lái)的。UML交互圖主要包括順序圖和通信圖它們都專注于描述對(duì)象之間的交互但視角和側(cè)重點(diǎn)不同。簡(jiǎn)單來(lái)說(shuō)順序圖像一部按時(shí)間順序播放的微電影它清晰地展示了消息在對(duì)象之間傳遞的時(shí)間順序是理解流程時(shí)序和生命周期的首選。通信圖則像一張靜態(tài)的組織結(jié)構(gòu)圖或通信網(wǎng)絡(luò)拓?fù)鋱D它更強(qiáng)調(diào)對(duì)象之間的結(jié)構(gòu)關(guān)系和在此結(jié)構(gòu)上發(fā)生的消息傳遞。作為一線開(kāi)發(fā)者和架構(gòu)師我深刻體會(huì)到在需求評(píng)審、架構(gòu)設(shè)計(jì)、核心流程梳理乃至排查復(fù)雜的時(shí)序性Bug時(shí)畫出一張清晰的交互圖其溝通效率遠(yuǎn)超千言萬(wàn)語(yǔ)。它不僅能讓我們自己理清思路更是團(tuán)隊(duì)內(nèi)部、乃至與上下游團(tuán)隊(duì)如前端與后端、服務(wù)與服務(wù)達(dá)成技術(shù)共識(shí)的“神器”。接下來(lái)我們就深入拆解這兩種圖看看它們具體怎么用以及在實(shí)際項(xiàng)目中如何避開(kāi)那些常見(jiàn)的“坑”。2. 順序圖為業(yè)務(wù)流程拍一部“逐幀動(dòng)畫”如果把一個(gè)軟件功能的執(zhí)行過(guò)程比作一場(chǎng)戲那么順序圖就是這場(chǎng)戲的詳細(xì)分鏡腳本。它嚴(yán)格按時(shí)間自上而下展開(kāi)清晰地告訴我們哪個(gè)對(duì)象在什么時(shí)間點(diǎn)對(duì)哪個(gè)對(duì)象說(shuō)了什么發(fā)送了什么消息以及對(duì)方如何回應(yīng)。2.1 順序圖的核心“演員”與“舞臺(tái)”在繪制順序圖之前我們需要先認(rèn)識(shí)它的基本元素參與者位于圖最頂端的矩形框代表參與交互的實(shí)體。這可以是系統(tǒng)外的角色如用戶、外部系統(tǒng)也可以是系統(tǒng)內(nèi)的對(duì)象或組件。在圖中它們用一條垂直的生命線向下延伸。生命線一條垂直的虛線代表一個(gè)對(duì)象在交互期間內(nèi)的存在。生命線的頂端對(duì)應(yīng)對(duì)象的創(chuàng)建時(shí)刻底端對(duì)應(yīng)其銷毀時(shí)刻如果交互中涉及。激活條生命線上細(xì)長(zhǎng)的矩形框代表對(duì)象執(zhí)行一個(gè)動(dòng)作或操作的時(shí)段。它直觀地顯示了對(duì)象“忙碌”的時(shí)間跨度。當(dāng)一個(gè)對(duì)象收到消息并開(kāi)始處理時(shí)激活條開(kāi)始處理完畢激活條結(jié)束。消息連接兩條生命線之間的水平箭頭代表對(duì)象之間的通信。這是順序圖的靈魂。消息有不同類型同步消息實(shí)心箭頭→表示。發(fā)送者發(fā)出消息后必須等待接收者處理完畢并返回后才能繼續(xù)執(zhí)行。這是最常見(jiàn)的函數(shù)/方法調(diào)用。異步消息開(kāi)放箭頭→表示。發(fā)送者發(fā)出消息后不等待響應(yīng)立即繼續(xù)執(zhí)行自己的操作。常見(jiàn)于事件驅(qū)動(dòng)、消息隊(duì)列等場(chǎng)景。返回消息虛線開(kāi)放箭頭- - -表示。從被調(diào)用者返回給調(diào)用者的響應(yīng)通常可省略不畫因?yàn)橥较⒈旧硪央[含了返回。組合片段用來(lái)描述更復(fù)雜的控制邏輯如條件判斷、循環(huán)、并行等。這是讓順序圖從描述簡(jiǎn)單線性流程升級(jí)為能表達(dá)復(fù)雜業(yè)務(wù)邏輯的關(guān)鍵。2.2 繪制一張實(shí)用的順序圖以“用戶登錄”為例理論總是抽象的我們用一個(gè)經(jīng)典的“用戶登錄”場(chǎng)景來(lái)實(shí)戰(zhàn)。假設(shè)我們有一個(gè)簡(jiǎn)單的三層架構(gòu)用戶界面、應(yīng)用服務(wù)層、數(shù)據(jù)訪問(wèn)層。場(chǎng)景用戶在前端界面輸入用戶名和密碼點(diǎn)擊登錄。我們一步步來(lái)構(gòu)建這個(gè)順序圖第一步確定參與者和生命線。參與者是用戶、LoginController界面控制器、AuthService認(rèn)證服務(wù)、UserRepository用戶數(shù)據(jù)倉(cāng)庫(kù)。將它們放在圖頂端畫出生命線。第二步描繪主成功流程。用戶輸入信息并點(diǎn)擊登錄按鈕這是一個(gè)來(lái)自系統(tǒng)外部的刺激我們畫一條從用戶生命線指向LoginController生命線的消息命名為submitLogin(username, password)。這是一個(gè)同步消息因?yàn)榻缑嫱ǔ?huì)等待后臺(tái)響應(yīng)來(lái)更新UI。LoginController收到請(qǐng)求后需要調(diào)用認(rèn)證邏輯。于是它向AuthService發(fā)送一條同步消息authenticate(username, password)。AuthService為了驗(yàn)證用戶需要獲取用戶信息。它向UserRepository發(fā)送同步消息findByUsername(username)。UserRepository執(zhí)行數(shù)據(jù)庫(kù)查詢?nèi)缓蠓祷匾粋€(gè)User對(duì)象或null。這里我們可以畫一條返回消息。AuthService收到User對(duì)象后進(jìn)行密碼比對(duì)。如果匹配它生成一個(gè)認(rèn)證令牌如JWT。然后它將這個(gè)令牌或簡(jiǎn)單的成功標(biāo)志返回給LoginController。LoginController將登錄成功的結(jié)果和令牌返回給前端界面。界面更新顯示登錄成功并跳轉(zhuǎn)到主頁(yè)。在這個(gè)過(guò)程中每當(dāng)一個(gè)對(duì)象收到同步消息并開(kāi)始處理時(shí)就在其生命線上啟動(dòng)一個(gè)激活條直到它處理完畢并返回。這樣誰(shuí)在什么時(shí)候“忙”一目了然。第三步處理分支和異?！褂媒M合片段。上面的流程是“理想路徑”。但登錄可能失敗密碼錯(cuò)誤、用戶不存在等。我們需要用alt抉擇組合片段來(lái)描述。在AuthService調(diào)用UserRepository之后我們用一個(gè)alt框?qū)⒑罄m(xù)流程框起來(lái)。alt框內(nèi)劃分多個(gè)區(qū)域。區(qū)域1條件[用戶存在且密碼正確]。里面是生成令牌并返回成功的流程即上述第5步的成功分支。區(qū)域2條件[用戶不存在或密碼錯(cuò)誤]。里面是AuthService直接構(gòu)造一個(gè)“認(rèn)證失敗”的異?；蝈e(cuò)誤信息返回給LoginController。LoginController收到失敗信息后再返回給界面界面顯示錯(cuò)誤提示。此外可能還有網(wǎng)絡(luò)超時(shí)、數(shù)據(jù)庫(kù)連接失敗等異常。對(duì)于這類技術(shù)異常我們通常用opt可選或另一個(gè)alt分支來(lái)處理或者更常見(jiàn)的做法是讓AuthService捕獲底層異常將其轉(zhuǎn)換為業(yè)務(wù)友好的錯(cuò)誤信息向上傳遞。第四步考慮異步與性能優(yōu)化。在更復(fù)雜的場(chǎng)景中登錄后可能需要異步記錄登錄日志、發(fā)送通知郵件等。這些操作不應(yīng)阻塞主登錄流程。我們可以在AuthService返回成功給LoginController的同時(shí)畫一條從AuthService指向AuditLogService的異步消息如async logLoginEvent(userId)。這條消息的箭頭是開(kāi)放箭頭表示AuthService發(fā)出日志記錄請(qǐng)求后無(wú)需等待其完成就可以繼續(xù)返回結(jié)果。AuditLogService的生命線上會(huì)有一個(gè)獨(dú)立的激活條與主流程并行。實(shí)操心得畫順序圖時(shí)切忌一開(kāi)始就陷入所有異常和分支的細(xì)節(jié)。應(yīng)該遵循“先主干后枝葉”的原則。先把最主要的、成功的流程畫清楚確保核心交互邏輯正確。然后再用組合片段逐步添加重要的業(yè)務(wù)分支如登錄失敗和技術(shù)異常。這樣畫出來(lái)的圖主次分明不會(huì)一團(tuán)亂麻。2.3 順序圖的進(jìn)階用法與常見(jiàn)誤區(qū)創(chuàng)建與銷毀對(duì)象如果交互中需要?jiǎng)討B(tài)創(chuàng)建對(duì)象可以用一條指向?qū)ο笊€起始點(diǎn)的消息消息名通常為create。銷毀對(duì)象則可以在其生命線末端畫一個(gè)X標(biāo)記。自調(diào)用消息一個(gè)對(duì)象調(diào)用自己的方法箭頭從自己的生命線出發(fā)再折返回自己的生命線形成一個(gè)小的激活條棧。這在描述對(duì)象內(nèi)部復(fù)雜邏輯時(shí)有用。常見(jiàn)誤區(qū)消息流過(guò)于瑣碎把每個(gè)getter/setter方法都畫出來(lái)導(dǎo)致圖形臃腫。順序圖應(yīng)關(guān)注對(duì)象間的關(guān)鍵協(xié)作對(duì)象內(nèi)部私有方法通常無(wú)需體現(xiàn)。濫用異步消息把本應(yīng)是同步調(diào)用的關(guān)系畫成異步誤導(dǎo)設(shè)計(jì)。需要明確通信機(jī)制是阻塞調(diào)用還是事件通知。忽略返回結(jié)果雖然返回消息可省略但對(duì)于重要的返回值特別是分支判斷依賴的返回值顯式地畫出來(lái)會(huì)更清晰。生命線長(zhǎng)度不合理某個(gè)對(duì)象在流程后期才參與但其生命線卻從頂部開(kāi)始畫造成誤解。生命線應(yīng)從該對(duì)象首次被創(chuàng)建或參與交互的時(shí)刻開(kāi)始。3. 通信圖揭示對(duì)象協(xié)作的“社會(huì)關(guān)系網(wǎng)絡(luò)”如果說(shuō)順序圖讓我們看清了“故事”的時(shí)序那么通信圖則讓我們看清了“演員”之間的關(guān)系網(wǎng)。它更側(cè)重于在對(duì)象結(jié)構(gòu)的上下文環(huán)境中展示消息的傳遞。3.1 通信圖與順序圖的本質(zhì)區(qū)別兩者都描述交互但側(cè)重點(diǎn)截然不同順序圖時(shí)間是第一維度。它通過(guò)生命線的垂直布局強(qiáng)有力地表達(dá)了消息的先后順序?；卮稹笆裁磿r(shí)候發(fā)生什么”的問(wèn)題。通信圖結(jié)構(gòu)是第一維度。它通過(guò)對(duì)象在平面上的布局清晰地展示了對(duì)象之間的靜態(tài)連接關(guān)系?；卮稹罢l(shuí)和誰(shuí)在通信”的問(wèn)題。在通信圖中沒(méi)有生命線的概念對(duì)象可以散落在圖的任何位置。對(duì)象之間的關(guān)聯(lián)用連接線表示。消息則沿著這些連接線傳遞并在消息上用序號(hào)標(biāo)明執(zhí)行的順序。3.2 繪制通信圖換個(gè)視角看“用戶登錄”我們沿用登錄的例子繪制其通信圖。第一步布置對(duì)象。將涉及的對(duì)象用戶、LoginController、AuthService、UserRepository以你認(rèn)為能清晰體現(xiàn)它們關(guān)系的方式擺放在圖上。通常邊界對(duì)象如Controller放一邊控制對(duì)象如Service放中間實(shí)體對(duì)象如Repository放另一邊。第二步建立連接。判斷哪些對(duì)象之間在本次交互中有關(guān)聯(lián)即存在消息傳遞。用戶和LoginController之間有一條連接線。LoginController和AuthService之間有一條連接線。AuthService和UserRepository之間有一條連接線。 這些連接線代表了在本次交互的上下文中這些對(duì)象是“認(rèn)識(shí)”的可以互相通信。第三步添加帶序號(hào)的消息。這是關(guān)鍵。我們?cè)谶B接線上添加消息并用數(shù)字序號(hào)表示順序。用戶-LoginController:1: submitLogin(...)LoginController-AuthService:2: authenticate(...)AuthService-UserRepository:3: findByUsername(...)UserRepository-AuthService:4: return user(這是一個(gè)返回消息序號(hào)通常與調(diào)用消息關(guān)聯(lián)如3.1但簡(jiǎn)單場(chǎng)景可直接用4)AuthService-LoginController:5: return authTokenLoginController-用戶:6: displayResult(...)第四步處理分支和循環(huán)。通信圖表達(dá)分支和循環(huán)不如順序圖直觀但可以通過(guò)條件子句和迭代標(biāo)記來(lái)實(shí)現(xiàn)。分支在消息序號(hào)后加方括號(hào)條件。例如從AuthService返回給LoginController的消息可以有兩個(gè)5a: [success] return authToken5b: [failure] return error循環(huán)在消息前加星號(hào)*和循環(huán)條件。例如如果AuthService需要重試查詢可能是*[i3]: 3: retryFindByUsername(...)3.3 通信圖的適用場(chǎng)景與局限通信圖非常適合在以下場(chǎng)景使用理解對(duì)象間的結(jié)構(gòu)關(guān)系當(dāng)你想強(qiáng)調(diào)哪些對(duì)象之間存在關(guān)聯(lián)并且這些關(guān)聯(lián)是交互發(fā)生的基礎(chǔ)時(shí)。例如在架構(gòu)評(píng)審中快速展示某個(gè)服務(wù)與周邊哪些服務(wù)有調(diào)用關(guān)系。補(bǔ)充類圖的動(dòng)態(tài)行為類圖只展示了靜態(tài)結(jié)構(gòu)通信圖可以附在某個(gè)用例或方法說(shuō)明旁展示這些類在特定場(chǎng)景下是如何協(xié)作的。簡(jiǎn)化簡(jiǎn)單交互對(duì)于消息流不長(zhǎng)、且更關(guān)心參與者的場(chǎng)景通信圖比順序圖更簡(jiǎn)潔。但其局限性也很明顯時(shí)序表達(dá)能力弱盡管有序號(hào)但復(fù)雜的嵌套、并行時(shí)序在通信圖上很難清晰表達(dá)容易變得混亂。不適合描述復(fù)雜流程對(duì)于包含大量條件分支、循環(huán)、并行操作的交互通信圖會(huì)顯得力不從心遠(yuǎn)不如順序圖直觀。經(jīng)驗(yàn)之談在實(shí)際項(xiàng)目中我很少單獨(dú)繪制通信圖。它的主要價(jià)值往往作為順序圖的輔助視圖或衍生視圖。很多UML工具如PlantUML、Draw.io支持從順序圖自動(dòng)生成通信圖。我的習(xí)慣是用順序圖做詳細(xì)設(shè)計(jì)確保流程正確當(dāng)需要向別人解釋“這個(gè)服務(wù)和哪些服務(wù)打交道”時(shí)快速拖出一個(gè)通信圖或者直接展示工具生成的通信圖視圖一目了然。4. 工具與實(shí)踐如何讓交互圖真正融入開(kāi)發(fā)流程圖畫得再漂亮如果不能融入團(tuán)隊(duì)的工作流產(chǎn)生實(shí)際價(jià)值那就是紙上談兵。下面分享一些讓UML交互圖“活”起來(lái)的實(shí)踐。4.1 工具選型輕量 vs. 重量輕量級(jí)繪圖工具Draw.io / diagrams.net免費(fèi)、開(kāi)源、在線/離線均可使用。組件庫(kù)豐富支持UML。最大的優(yōu)點(diǎn)是上手極快無(wú)需復(fù)雜學(xué)習(xí)適合快速草圖繪制和團(tuán)隊(duì)臨時(shí)協(xié)作評(píng)審。生成的圖片易于嵌入文檔、Confluence或Markdown中。對(duì)于大多數(shù)團(tuán)隊(duì)日常使用我首推這個(gè)。Mermaid這是一個(gè)基于文本生成圖表的工具。你可以用類似Markdown的語(yǔ)法描述順序圖、類圖等代碼可版本化管理。非常適合開(kāi)發(fā)者可以集成在GitHub Wiki、GitLab、VS Code等環(huán)境中。缺點(diǎn)是定制化外觀稍弱。PlantUML與Mermaid類似但語(yǔ)法更強(qiáng)大、更專業(yè)對(duì)UML的支持非常全面和標(biāo)準(zhǔn)。需要本地或服務(wù)器環(huán)境渲染。是很多嚴(yán)謹(jǐn)技術(shù)文檔作者的選擇。重量級(jí)建模工具Enterprise Architect, IBM Rational Software Architect功能全面的商業(yè)UML工具支持正向/逆向工程、代碼生成、模型驗(yàn)證等。適用于大型、復(fù)雜、對(duì)模型一致性要求極高的項(xiàng)目如航空、金融核心系統(tǒng)。但學(xué)習(xí)曲線陡峭價(jià)格昂貴在敏捷團(tuán)隊(duì)中可能顯得笨重。選型建議對(duì)于互聯(lián)網(wǎng)和大多數(shù)軟件公司從Draw.io開(kāi)始完全足夠。當(dāng)團(tuán)隊(duì)需要將設(shè)計(jì)文檔也納入版本控制并且追求“文檔即代碼”時(shí)可以引入Mermaid。除非項(xiàng)目有嚴(yán)格的模型驅(qū)動(dòng)開(kāi)發(fā)要求否則不建議一開(kāi)始就上重量級(jí)工具。4.2 將交互圖嵌入開(kāi)發(fā)閉環(huán)需求分析與評(píng)審階段在梳理用戶故事或用例時(shí)針對(duì)核心、復(fù)雜的業(yè)務(wù)流程產(chǎn)品經(jīng)理或技術(shù)負(fù)責(zé)人可以畫出系統(tǒng)級(jí)順序圖參與者是用戶和系統(tǒng)黑盒或前端與后端邊界。這能極大消除歧義確保大家對(duì)流程的理解一致。這張圖應(yīng)作為需求文檔的一部分。技術(shù)設(shè)計(jì)與詳設(shè)階段在拆分任務(wù)后開(kāi)發(fā)人員在開(kāi)始編碼前對(duì)自己負(fù)責(zé)的模塊或接口繪制對(duì)象級(jí)順序圖。這個(gè)過(guò)程是“逼”自己把設(shè)計(jì)想清楚的過(guò)程很多接口設(shè)計(jì)缺陷、邊界條件遺漏在畫圖時(shí)就能發(fā)現(xiàn)。這張圖可以放在代碼庫(kù)的DESIGN.md中或直接以注釋形式放在關(guān)鍵函數(shù)/類上方如果用Mermaid/PlantUML。代碼評(píng)審階段評(píng)審代碼時(shí)除了看代碼本身可以要求作者提供關(guān)鍵算法的順序圖。這能讓評(píng)審者快速理解代碼意圖和交互邏輯提升評(píng)審效率和質(zhì)量。問(wèn)題排查與知識(shí)沉淀當(dāng)遇到復(fù)雜的、涉及多模塊交互的Bug時(shí)在排查清楚后畫一張問(wèn)題發(fā)生時(shí)的順序圖附在Bug報(bào)告或事故復(fù)盤文檔里。這比文字描述直觀百倍也是極佳的知識(shí)沉淀。4.3 避免“為了畫圖而畫圖”的陷阱過(guò)度設(shè)計(jì)不要試圖為每一個(gè)方法、每一個(gè)簡(jiǎn)單的CRUD操作都畫交互圖。聚焦在核心業(yè)務(wù)邏輯、復(fù)雜算法流程、跨模塊/跨服務(wù)調(diào)用以及容易產(chǎn)生誤解的環(huán)節(jié)。不維護(hù)不更新最糟糕的文檔是過(guò)時(shí)的文檔。如果代碼改了圖卻沒(méi)更新后者就會(huì)產(chǎn)生誤導(dǎo)。建立輕量化的流程當(dāng)修改涉及已繪制交互圖的核心邏輯時(shí)更新圖表應(yīng)作為代碼提交的一部分。利用Mermaid/PlantUML這類文本化工具可以很方便地通過(guò)代碼Diff來(lái)審查圖的變更。追求形式完美忽視溝通本質(zhì)圖的目的是為了溝通和厘清思路不是藝術(shù)品。只要團(tuán)隊(duì)成員能看懂線條是否完全筆直、圖形是否絕對(duì)對(duì)齊并不重要。在會(huì)議中使用白板或Draw.io快速手繪邊畫邊講效果往往比事先準(zhǔn)備好的精美圖表更好因?yàn)榛?dòng)性更強(qiáng)。5. 從理論到實(shí)戰(zhàn)一個(gè)微服務(wù)調(diào)用鏈的交互圖剖析讓我們看一個(gè)更接近真實(shí)后端開(kāi)發(fā)的場(chǎng)景在一個(gè)電商系統(tǒng)中“用戶下單”這個(gè)操作可能涉及訂單服務(wù)、庫(kù)存服務(wù)、支付服務(wù)、優(yōu)惠券服務(wù)等多個(gè)微服務(wù)。理解它們之間的調(diào)用鏈和時(shí)序至關(guān)重要。我們使用順序圖來(lái)描述這個(gè)分布式場(chǎng)景并引入一些在微服務(wù)架構(gòu)下特有的考慮。場(chǎng)景用戶提交訂單。參與者用戶、API網(wǎng)關(guān)、訂單服務(wù)、庫(kù)存服務(wù)、支付服務(wù)、消息隊(duì)列。主流程順序圖剖析用戶向API網(wǎng)關(guān)發(fā)送POST /orders請(qǐng)求同步消息。API網(wǎng)關(guān)進(jìn)行鑒權(quán)、路由將請(qǐng)求轉(zhuǎn)發(fā)給訂單服務(wù)的創(chuàng)建訂單接口同步消息。訂單服務(wù)開(kāi)始創(chuàng)建訂單對(duì)象但首先需要預(yù)占庫(kù)存。它向庫(kù)存服務(wù)發(fā)送一個(gè)同步RPC調(diào)用lockInventory(itemId, quantity)。這里是一個(gè)關(guān)鍵設(shè)計(jì)點(diǎn)為什么是同步調(diào)用因?yàn)閹?kù)存是硬約束如果庫(kù)存不足訂單創(chuàng)建必須立即失敗。異步扣減庫(kù)存會(huì)導(dǎo)致超賣。庫(kù)存服務(wù)檢查并鎖定庫(kù)存返回成功。訂單服務(wù)庫(kù)存鎖定成功后接著調(diào)用支付。它向支付服務(wù)發(fā)送同步調(diào)用createPayment(orderId, amount)。另一個(gè)設(shè)計(jì)點(diǎn)支付通常也是同步調(diào)用因?yàn)樾枰磿r(shí)知道支付渠道是否受理成功如調(diào)起收銀臺(tái)、獲取支付狀態(tài)。但支付的成功確認(rèn)可能是異步回調(diào)。支付服務(wù)與第三方支付網(wǎng)關(guān)交互返回“支付處理中”或“支付成功”。假設(shè)支付返回“處理中”訂單服務(wù)將訂單狀態(tài)置為“待支付”并保存。然后它需要異步通知其他系統(tǒng)。它向消息隊(duì)列發(fā)送一條異步消息OrderCreatedEvent(orderId)。設(shè)計(jì)點(diǎn)為什么用消息隊(duì)列異步通知因?yàn)橄癜l(fā)送下單成功短信、更新用戶積分、通知倉(cāng)庫(kù)系統(tǒng)等操作不要求強(qiáng)一致性和實(shí)時(shí)性異步處理可以解耦、削峰、提高主流程響應(yīng)速度。訂單服務(wù)將“訂單創(chuàng)建成功等待支付”的結(jié)果返回給API網(wǎng)關(guān)再最終返回給用戶。后續(xù)優(yōu)惠券服務(wù)、物流服務(wù)等作為消息隊(duì)列的消費(fèi)者接收到OrderCreatedEvent后各自進(jìn)行異步處理。在這個(gè)圖中我們可以清晰地看到同步與異步的混合核心的庫(kù)存、支付是同步確保強(qiáng)一致性后續(xù)的通知是異步提升性能和可擴(kuò)展性。分布式事務(wù)的考量如果庫(kù)存服務(wù)鎖定成功但支付服務(wù)調(diào)用失敗怎么辦這就引入了分布式事務(wù)問(wèn)題如Saga模式需要在圖中用alt片段來(lái)描繪補(bǔ)償邏輯如調(diào)用庫(kù)存服務(wù)的unlockInventory。消息隊(duì)列作為參與者在順序圖中消息隊(duì)列可以作為一個(gè)特殊的參與者很好地體現(xiàn)了異步解耦的架構(gòu)思想。繪制這樣一張圖對(duì)于新加入團(tuán)隊(duì)的工程師理解系統(tǒng)架構(gòu)對(duì)于排查“訂單創(chuàng)建了但沒(méi)扣庫(kù)存”這類分布式問(wèn)題具有不可替代的價(jià)值。它把散落在各處的代碼和配置串聯(lián)成了一個(gè)可視化的故事。畫圖的過(guò)程本身就是一次深刻的設(shè)計(jì)評(píng)審。當(dāng)你試圖用箭頭把各個(gè)服務(wù)連接起來(lái)時(shí)你會(huì)不由自主地思考這個(gè)調(diào)用應(yīng)該是同步還是異步超時(shí)了怎么辦失敗了如何回滾這些問(wèn)題的答案最終都會(huì)體現(xiàn)在你的圖表和隨之而來(lái)的設(shè)計(jì)中。所以別再認(rèn)為畫UML圖是浪費(fèi)時(shí)間它是將模糊思路轉(zhuǎn)化為清晰設(shè)計(jì)的最短路徑。從今天起嘗試在下一個(gè)復(fù)雜功能開(kāi)發(fā)前先畫一張順序圖吧你會(huì)回來(lái)感謝這個(gè)習(xí)慣的。