1. 從“亂麻”到“藍(lán)圖”為什么一張圖能決定項(xiàng)目的成敗干了這么多年技術(shù)從一線碼農(nóng)到帶團(tuán)隊(duì)做架構(gòu)我越來(lái)越覺(jué)得系統(tǒng)架構(gòu)圖這東西真不是給領(lǐng)導(dǎo)匯報(bào)的“面子工程”。它更像是一份作戰(zhàn)地圖一份團(tuán)隊(duì)內(nèi)部的“技術(shù)憲法”。我見(jiàn)過(guò)太多項(xiàng)目一開(kāi)始大家拍腦袋口頭說(shuō)“這里放個(gè)服務(wù)那里連個(gè)數(shù)據(jù)庫(kù)”結(jié)果開(kāi)發(fā)到一半各種接口對(duì)不上、數(shù)據(jù)流成了死循環(huán)、擴(kuò)容時(shí)才發(fā)現(xiàn)是個(gè)“單體巨獸”無(wú)從下手。問(wèn)題出在哪往往就是缺了一張?jiān)趧?dòng)手前就反復(fù)推敲、達(dá)成共識(shí)的清晰架構(gòu)圖。最近在做一個(gè)將三個(gè)獨(dú)立業(yè)務(wù)平臺(tái)比如電商、內(nèi)容、用戶中心融合成一體的項(xiàng)目這個(gè)“三個(gè)業(yè)務(wù)平臺(tái)融合在一起的系統(tǒng)架構(gòu)圖”就成了我們前期最重要的產(chǎn)出物。沒(méi)有它三個(gè)團(tuán)隊(duì)的開(kāi)發(fā)人員根本就是在“盲人摸象”各干各的。所以今天我不講那些“什么是41視圖”的教科書(shū)理論就結(jié)合這個(gè)實(shí)際案例聊聊我們是怎么一步步把這張融合架構(gòu)圖畫(huà)出來(lái)并讓它真正發(fā)揮價(jià)值的。無(wú)論你是剛開(kāi)始接觸架構(gòu)的新手還是想優(yōu)化現(xiàn)有繪圖流程的老手希望這些踩坑總結(jié)出來(lái)的實(shí)操經(jīng)驗(yàn)?zāi)芙o你帶來(lái)點(diǎn)實(shí)在的啟發(fā)。2. 繪圖前的“靈魂三問(wèn)”明確目標(biāo)比選擇工具更重要很多人一上來(lái)就問(wèn)“該用Visio、Draw.io還是Miro”工具固然重要但在打開(kāi)任何繪圖軟件之前必須先回答三個(gè)核心問(wèn)題。方向錯(cuò)了工具再好畫(huà)出來(lái)的也是廢紙。2.1 第一問(wèn)這張圖給誰(shuí)看明確受眾與視角這是最關(guān)鍵的一步直接決定了圖的詳略和表達(dá)方式。一張?jiān)噲D滿足所有人的圖最終會(huì)讓所有人都看不懂。給技術(shù)決策者CTO、架構(gòu)師看他們關(guān)心的是技術(shù)選型的合理性、系統(tǒng)的擴(kuò)展性、容錯(cuò)能力和技術(shù)債務(wù)。圖里需要突出技術(shù)邊界比如哪些用K8s哪些用虛擬機(jī)、通信協(xié)議gRPC還是REST同步還是異步、數(shù)據(jù)一致性方案是最終一致還是強(qiáng)一致。這時(shí)你需要的是一個(gè)邏輯架構(gòu)圖或部署架構(gòu)圖。給開(kāi)發(fā)/測(cè)試工程師看他們是圖的直接使用者。他們需要清晰地知道“我負(fù)責(zé)的模塊在哪它依賴誰(shuí)又被誰(shuí)依賴”。圖里必須明確服務(wù)/模塊的邊界、接口定義、數(shù)據(jù)流向。一個(gè)組件圖或細(xì)化后的邏輯圖會(huì)更合適甚至需要配套的接口文檔目錄。給產(chǎn)品/業(yè)務(wù)方看他們關(guān)心功能如何實(shí)現(xiàn)、用戶旅程是否順暢。圖應(yīng)該以業(yè)務(wù)流程為線索展示關(guān)鍵的用戶請(qǐng)求如何在不同系統(tǒng)間流轉(zhuǎn)數(shù)據(jù)如何被創(chuàng)建和消費(fèi)。這通常是一張高度簡(jiǎn)化的上下文圖或流程圖要避免出現(xiàn)技術(shù)術(shù)語(yǔ)。在我們“三平臺(tái)融合”的項(xiàng)目里我們畫(huà)了三張圖給老板和產(chǎn)品看的全景圖一個(gè)大的方塊代表“融合后平臺(tái)”旁邊三個(gè)小方塊是舊系統(tǒng)用粗箭頭表示“數(shù)據(jù)遷移與整合”重點(diǎn)突出新平臺(tái)的能力域如“統(tǒng)一訂單中心”、“全域用戶畫(huà)像”。給技術(shù)團(tuán)隊(duì)看的邏輯架構(gòu)圖這張圖是核心詳細(xì)展示了融合后如何通過(guò)API網(wǎng)關(guān)統(tǒng)一入口身份認(rèn)證中心如何對(duì)接三個(gè)舊用戶體系消息隊(duì)列如何解耦訂單、庫(kù)存、通知等模塊。給運(yùn)維同事看的部署架構(gòu)圖標(biāo)明了哪些服務(wù)是容器化部署在K8s集群哪些中間件如Redis集群、MySQL主從是獨(dú)立部署負(fù)載均衡器如何配置。注意不要妄想用一張圖包含所有信息。分層分視角繪制并建立圖與圖之間的關(guān)聯(lián)比如在邏輯圖上標(biāo)注“此服務(wù)集群見(jiàn)部署圖A”是保持清晰度的不二法門。2.2 第二問(wèn)要解決什么核心問(wèn)題定義繪圖范圍與焦點(diǎn)畫(huà)圖不是為了好看是為了解決問(wèn)題。在動(dòng)筆前必須明確當(dāng)前階段架構(gòu)設(shè)計(jì)要解決的主要矛盾。如果是梳理現(xiàn)狀重點(diǎn)在于“As-Is”現(xiàn)狀如何。要厘清現(xiàn)有系統(tǒng)有哪些、它們之間混亂的調(diào)用關(guān)系、存在哪些煙囪式數(shù)據(jù)孤島。圖畫(huà)出來(lái)可能很“丑”但貴在真實(shí)。如果是設(shè)計(jì)新系統(tǒng)或重大改造如我們的融合項(xiàng)目重點(diǎn)在于“To-Be”未來(lái)藍(lán)圖。焦點(diǎn)應(yīng)放在邊界劃分、職責(zé)分離、數(shù)據(jù)流設(shè)計(jì)和集成模式上。例如是選擇“絞殺者模式”逐步替換還是新建一個(gè)聚合層做適配如果是討論某一個(gè)具體特性比如“如何實(shí)現(xiàn)秒殺”那么圖的范圍就縮小到訂單、庫(kù)存、緩存、隊(duì)列這幾個(gè)核心服務(wù)深度要夠要畫(huà)出具體的調(diào)用時(shí)序和緩存策略。在我們的案例中核心問(wèn)題是“整合與解耦”。因此圖的焦點(diǎn)就必須放在新舊系統(tǒng)并存的過(guò)渡態(tài)如何設(shè)計(jì)公共能力用戶、權(quán)限、消息如何下沉為共享服務(wù)業(yè)務(wù)模塊間如何通過(guò)事件驅(qū)動(dòng)來(lái)降低直接耦合2.3 第三問(wèn)需要細(xì)化到什么程度把握抽象層級(jí)架構(gòu)圖是分層的就像地圖有世界地圖、國(guó)家地圖、城市街道圖一樣。在哪個(gè)層級(jí)畫(huà)決定了細(xì)節(jié)的粒度。Level 1: 上下文圖Context Diagram系統(tǒng)與外部用戶、其他系統(tǒng)的關(guān)系。一個(gè)方塊代表整個(gè)系統(tǒng)。適合向非技術(shù)人員介紹系統(tǒng)生態(tài)位。Level 2: 容器圖Container Diagram這里“容器”不是Docker而是指可獨(dú)立運(yùn)行/部署的單元如Web應(yīng)用、移動(dòng)App、數(shù)據(jù)庫(kù)、消息隊(duì)列等。展示了系統(tǒng)的宏觀結(jié)構(gòu)。Level 3: 組件圖Component Diagram拆解單個(gè)“容器”內(nèi)部由哪些組件模塊、庫(kù)構(gòu)成以及它們之間的依賴關(guān)系。這是開(kāi)發(fā)人員最需要的一層。Level 4: 代碼圖Code Diagram通過(guò)工具如UML類圖從代碼層面生成展示類、方法之間的關(guān)系。通常用于詳細(xì)設(shè)計(jì)或重構(gòu)分析。對(duì)于融合項(xiàng)目我們大部分時(shí)間花在Level 2容器圖和Level 3組件圖。例如在“統(tǒng)一訂單中心”這個(gè)容器里我們會(huì)進(jìn)一步畫(huà)出“訂單接入組件”、“訂單處理核心組件”、“訂單狀態(tài)機(jī)組件”等并明確它們之間的調(diào)用關(guān)系。3. 核心構(gòu)圖法則讓圖形自己“說(shuō)話”明確了目標(biāo)就可以開(kāi)始構(gòu)思怎么畫(huà)了。好的架構(gòu)圖有一套通用的“視覺(jué)語(yǔ)言”遵循這些法則能極大提升溝通效率。3.1 圖形與顏色的語(yǔ)義化約定團(tuán)隊(duì)內(nèi)部必須對(duì)圖形和顏色含義達(dá)成一致并形成慣例。這是我們團(tuán)隊(duì)自用的一個(gè)簡(jiǎn)單約定圖形元素含義常用場(chǎng)景示例矩形應(yīng)用服務(wù)、進(jìn)程、微服務(wù)“用戶服務(wù)”、“訂單處理Job”圓柱體數(shù)據(jù)存儲(chǔ)“MySQL主庫(kù)”、“Redis緩存集群”、“Elasticsearch索引”立方體外部系統(tǒng)/第三方服務(wù)“微信支付”、“短信網(wǎng)關(guān)”、“物流公司API”虛線框/泳道邏輯邊界、部署邊界“K8s集群A”、“VPC網(wǎng)絡(luò)”、“舊系統(tǒng)域”箭頭數(shù)據(jù)流、調(diào)用關(guān)系、依賴方向?qū)嵕€箭頭表同步調(diào)用虛線箭頭表異步消息顏色狀態(tài)或?qū)傩苑茄b飾紅色關(guān)鍵路徑、單點(diǎn)故障黃色待重構(gòu)/技術(shù)債綠色已穩(wěn)定運(yùn)行藍(lán)色新建/規(guī)劃中在融合架構(gòu)圖中我們用藍(lán)色表示新建的融合層服務(wù)灰色表示待逐步遷移或廢棄的舊平臺(tái)模塊紅色箭頭特別標(biāo)出了跨平臺(tái)數(shù)據(jù)同步的關(guān)鍵路徑。這樣任何人拿到圖一眼就能看出重點(diǎn)和現(xiàn)狀。3.2 布局的藝術(shù)清晰展現(xiàn)層次與關(guān)系混亂的布局是架構(gòu)圖的第一殺手。好的布局能直觀體現(xiàn)系統(tǒng)的層次結(jié)構(gòu)和模塊關(guān)系。分層布局最常用從上到下或從左到右按邏輯層次排列。例如用戶接入層最上方放置負(fù)載均衡器、API網(wǎng)關(guān)、CDN。應(yīng)用服務(wù)層中間放置各個(gè)業(yè)務(wù)微服務(wù)可按業(yè)務(wù)域分組用戶域、訂單域、商品域。數(shù)據(jù)層最下方放置數(shù)據(jù)庫(kù)、緩存、消息隊(duì)列?；A(chǔ)設(shè)施層最底層或作為背景表示K8s、云服務(wù)等。中心輻射布局適用于有核心樞紐的系統(tǒng)。例如將“API網(wǎng)關(guān)”或“消息總線”放在中心周圍環(huán)繞各個(gè)業(yè)務(wù)服務(wù)。這能強(qiáng)調(diào)核心組件的集成作用。泳道布局非常適合展示跨系統(tǒng)、跨團(tuán)隊(duì)的流程。在我們的融合項(xiàng)目中我們用泳道來(lái)區(qū)分“電商平臺(tái)”、“內(nèi)容平臺(tái)”、“用戶平臺(tái)”的遺留服務(wù)以及新建的“融合中臺(tái)”這樣數(shù)據(jù)如何在泳道間流轉(zhuǎn)一目了然。實(shí)操心得畫(huà)圖時(shí)先用便簽紙或繪圖軟件的圖形塊把所有重要的組件“撒”在畫(huà)布上然后像玩拼圖一樣不斷移動(dòng)、調(diào)整尋找最能體現(xiàn)系統(tǒng)本質(zhì)關(guān)系的布局。這個(gè)過(guò)程本身就是一次深刻的架構(gòu)梳理。3.3 連接線的學(xué)問(wèn)表達(dá)豐富的交互語(yǔ)義線不是隨便連的不同的線型、箭頭和標(biāo)簽承載了不同的架構(gòu)意圖。實(shí)線 vs 虛線通常實(shí)線代表強(qiáng)依賴、同步調(diào)用如HTTP/gRPC虛線代表弱依賴、異步通信如消息隊(duì)列、事件或邏輯關(guān)聯(lián)。箭頭方向永遠(yuǎn)指向依賴方或數(shù)據(jù)/請(qǐng)求的流向。A調(diào)用B箭頭就從A指向B。這有助于分析依賴的合理性和循環(huán)依賴問(wèn)題。連線標(biāo)簽務(wù)必在關(guān)鍵連接線上添加標(biāo)簽說(shuō)明協(xié)議HTTP/1.1, gRPC、數(shù)據(jù)格式JSON Protobuf、交互性質(zhì)“查詢訂單”、“發(fā)布訂單創(chuàng)建事件”。這是圖的“血肉”。聚合關(guān)系可以用一個(gè)“容器”形狀包裹一組相關(guān)的服務(wù)表示它們共同組成一個(gè)更大的模塊或部署單元。在我們的圖中從“訂單服務(wù)”到“庫(kù)存服務(wù)”的實(shí)線箭頭標(biāo)簽是“同步HTTP調(diào)用預(yù)占庫(kù)存”而從“訂單服務(wù)”指向“消息隊(duì)列”的虛線箭頭標(biāo)簽是“異步發(fā)布o(jì)rder.created事件”。這樣同步扣庫(kù)存和異步發(fā)通知這兩種截然不同的交互模式在圖上就區(qū)分得非常清楚。4. 實(shí)戰(zhàn)繪制“三平臺(tái)融合”架構(gòu)圖的全過(guò)程下面我就以這個(gè)真實(shí)的“三個(gè)業(yè)務(wù)平臺(tái)融合”項(xiàng)目為例拆解我們從0到1繪制核心邏輯架構(gòu)圖的具體步驟。你可以把它當(dāng)作一個(gè)可復(fù)用的模板。4.1 第一步現(xiàn)狀調(diào)研與核心資產(chǎn)識(shí)別在畫(huà)未來(lái)藍(lán)圖前必須先徹底理解現(xiàn)狀。我們做了三件事列表梳理為每個(gè)舊平臺(tái)創(chuàng)建一張表格列出其核心業(yè)務(wù)功能、主要服務(wù)/模塊、數(shù)據(jù)庫(kù)和存儲(chǔ)、對(duì)外提供的API以及依賴的外部服務(wù)。接口分析找出三個(gè)平臺(tái)之間現(xiàn)有的、點(diǎn)對(duì)點(diǎn)的直接調(diào)用往往是歷史遺留的“蜘蛛網(wǎng)”并分析其調(diào)用頻率、數(shù)據(jù)量和穩(wěn)定性。數(shù)據(jù)模型對(duì)比這是融合最難的部分。對(duì)比三個(gè)平臺(tái)的“用戶表”、“商品表”、“訂單表”找出字段差異、ID體系沖突比如有的是自增ID有的是UUID和業(yè)務(wù)邏輯差異。這個(gè)階段產(chǎn)出的是零散的清單和混亂的現(xiàn)狀圖但它是一切重構(gòu)的基礎(chǔ)。4.2 第二步定義融合后的頂層架構(gòu)風(fēng)格基于現(xiàn)狀和業(yè)務(wù)目標(biāo)我們確定了融合后的頂層架構(gòu)風(fēng)格前后端分離 微服務(wù)化 事件驅(qū)動(dòng)。前后端分離統(tǒng)一前端入口為Web、App、H5提供一致的API。微服務(wù)化不是盲目拆細(xì)而是根據(jù)業(yè)務(wù)邊界如用戶、商品、訂單、營(yíng)銷和變更頻率來(lái)劃分服務(wù)。將三個(gè)平臺(tái)中重復(fù)的功能如用戶認(rèn)證、消息推送抽取為共享中臺(tái)服務(wù)。事件驅(qū)動(dòng)用于解耦強(qiáng)關(guān)聯(lián)的業(yè)務(wù)流程。例如訂單創(chuàng)建后不再同步調(diào)用積分、物流、客服系統(tǒng)而是發(fā)布一個(gè)事件讓相關(guān)服務(wù)自行訂閱處理。這個(gè)決策直接影響了我們架構(gòu)圖的整體形態(tài)中心會(huì)有一個(gè)API網(wǎng)關(guān)下方是各個(gè)業(yè)務(wù)域的服務(wù)群服務(wù)之間通過(guò)消息中間件形成松散的連接網(wǎng)絡(luò)。4.3 第三步繪制邏輯架構(gòu)圖核心產(chǎn)出這是最耗時(shí)也最關(guān)鍵的一步。我們使用 Draw.io現(xiàn)diagrams.net在線協(xié)作完成。劃定邊界放置核心樞紐在畫(huà)布頂部放置API網(wǎng)關(guān)作為所有外部流量的統(tǒng)一入口。在畫(huà)布中央偏下放置消息隊(duì)列集群如Kafka/RocketMQ作為事件總線。在底部放置共享數(shù)據(jù)層包括統(tǒng)一的用戶中心數(shù)據(jù)庫(kù)、商品中心數(shù)據(jù)庫(kù)等以及Redis緩存集群和Elasticsearch搜索集群。填充業(yè)務(wù)服務(wù)按域分組在API網(wǎng)關(guān)下方劃分幾個(gè)區(qū)域分別代表“用戶域”、“商品與內(nèi)容域”、“交易域”、“營(yíng)銷域”。將新建的微服務(wù)如User-Service,Product-Service,Order-Service,Content-Service放入對(duì)應(yīng)區(qū)域。同時(shí)將舊平臺(tái)中暫時(shí)無(wú)法遷移、需要保留的服務(wù)用灰色方塊表示放在邊緣并標(biāo)注“待遷移”。連接交互關(guān)系標(biāo)注協(xié)議所有業(yè)務(wù)服務(wù)到API網(wǎng)關(guān)的連線實(shí)線標(biāo)簽“RESTful API / HTTPS”。服務(wù)間需要強(qiáng)一致性的同步調(diào)用如訂單服務(wù)扣減庫(kù)存實(shí)線箭頭連接兩個(gè)服務(wù)標(biāo)簽“gRPC / 同步”。服務(wù)間基于事件的異步通信如訂單創(chuàng)建后觸發(fā)積分、短信虛線箭頭從生產(chǎn)者服務(wù)指向消息隊(duì)列再?gòu)南㈥?duì)列指向各個(gè)消費(fèi)者服務(wù)。標(biāo)簽寫(xiě)明事件名如“發(fā)布o(jì)rder.paid.v1”。服務(wù)與數(shù)據(jù)層的連接實(shí)線連接數(shù)據(jù)庫(kù)或緩存。突出關(guān)鍵設(shè)計(jì)點(diǎn)用醒目的顏色框出“身份認(rèn)證中心”并畫(huà)出它如何通過(guò)適配器模式兼容三個(gè)舊平臺(tái)的登錄方式。在“訂單服務(wù)”和三個(gè)舊平臺(tái)的訂單數(shù)據(jù)庫(kù)之間畫(huà)出“雙寫(xiě)”或“CDC同步”的箭頭表示數(shù)據(jù)遷移過(guò)渡期的狀態(tài)。在網(wǎng)關(guān)處畫(huà)出“路由分發(fā)”的邏輯示意如何將請(qǐng)求導(dǎo)向新服務(wù)或舊服務(wù)。4.4 第四步生成部署架構(gòu)圖與演進(jìn)路線圖邏輯圖完成后部署圖相對(duì)簡(jiǎn)單主要關(guān)注運(yùn)行態(tài)。部署圖我們基于邏輯圖將服務(wù)映射到具體的基礎(chǔ)設(shè)施上。例如所有新建的微服務(wù)都放在一個(gè)K8s Namespace里用Deployment和Service定義。舊服務(wù)可能還在獨(dú)立的虛擬機(jī)或物理機(jī)上。用不同的圖形或顏色區(qū)分容器、虛擬機(jī)、云托管服務(wù)如RDS。并畫(huà)出網(wǎng)絡(luò)拓?fù)銿PC、子網(wǎng)、安全組規(guī)則、負(fù)載均衡器如Nginx Ingress Controller。演進(jìn)路線圖這其實(shí)是一系列按時(shí)間順序排列的簡(jiǎn)化架構(gòu)圖放在項(xiàng)目文檔里。例如Phase 1圖展示新建API網(wǎng)關(guān)和認(rèn)證中心流量開(kāi)始接入但業(yè)務(wù)仍主要走舊系統(tǒng)。Phase 2圖展示商品和內(nèi)容服務(wù)完成遷移新老系統(tǒng)并存通過(guò)網(wǎng)關(guān)路由。Phase 3圖展示訂單等核心服務(wù)遷移完成舊系統(tǒng)只讀或下線。5. 常見(jiàn)“坑點(diǎn)”與優(yōu)化技巧實(shí)錄畫(huà)了這么多圖也看了無(wú)數(shù)別人畫(huà)的圖有些坑反復(fù)出現(xiàn)。這里分享幾個(gè)最典型的排查點(diǎn)和優(yōu)化技巧。5.1 問(wèn)題一圖過(guò)于復(fù)雜像“電路板”癥狀一張圖上擠滿了成百上千個(gè)組件和密密麻麻的連線沒(méi)人能看懂。根因試圖在一張圖上表達(dá)所有層級(jí)和細(xì)節(jié)。解決分層分治。嚴(yán)格按照上下文圖-容器圖-組件圖的層級(jí)來(lái)畫(huà)。在高層圖中將一個(gè)子系統(tǒng)或模塊折疊成一個(gè)方塊注明“內(nèi)部細(xì)節(jié)見(jiàn)組件圖-X”。使用“泳道”或“虛線框”來(lái)分組減少視覺(jué)交叉。5.2 問(wèn)題二連線交叉混亂流向不清癥狀連線像一團(tuán)亂麻無(wú)法追蹤數(shù)據(jù)起點(diǎn)和終點(diǎn)。根因布局隨意沒(méi)有遵循層次或分組原則。解決使用繪圖工具的“自動(dòng)布局”功能嘗試雖然通常需要手動(dòng)調(diào)整。手動(dòng)對(duì)齊和分布組件讓同一層的組件水平或垂直對(duì)齊。對(duì)于長(zhǎng)距離或跨越多層的連接使用直角連線而不是直接曲線讓線路橫平豎直更清晰?？紤]使用**“連接點(diǎn)”**讓連線從組件的固定位置如頂部、左側(cè)出發(fā)。5.3 問(wèn)題三圖形語(yǔ)義不一致需要“圖例”癥狀團(tuán)隊(duì)成員對(duì)同一個(gè)圖形理解不同比如有人認(rèn)為圓柱體一定是MySQL有人認(rèn)為是任何數(shù)據(jù)庫(kù)。根因沒(méi)有建立團(tuán)隊(duì)內(nèi)部的繪圖規(guī)范。解決在每一份架構(gòu)圖文檔的首頁(yè)或角落永遠(yuǎn)附帶一個(gè)“圖例”。明確說(shuō)明矩形、圓柱、虛線、箭頭、顏色分別代表什么。這是專業(yè)性的體現(xiàn)也能讓新成員快速上手。5.4 問(wèn)題四圖與實(shí)際嚴(yán)重脫節(jié)癥狀圖上畫(huà)的是一套精美的微服務(wù)實(shí)際代碼是“單體里打補(bǔ)丁”。根因圖沒(méi)有隨著系統(tǒng)迭代而更新成了“面子工程”。解決將架構(gòu)圖作為活文檔。將繪圖文件如.drawio文件放在項(xiàng)目代碼庫(kù)中與代碼一起進(jìn)行版本管理。建立規(guī)則每次重大的架構(gòu)變更如新增服務(wù)、改變通信方式必須先更新架構(gòu)圖并通過(guò)評(píng)審才能合并代碼?？梢钥紤]使用一些代碼即架構(gòu)的工具如PlantUML或利用Go/Java的注解生成依賴圖讓部分圖表能自動(dòng)從代碼或配置中生成保持同步。5.5 高級(jí)技巧讓架構(gòu)圖“動(dòng)”起來(lái)對(duì)于特別復(fù)雜的交互流程靜態(tài)圖可能力不從心。可以嘗試序列圖輔助對(duì)于關(guān)鍵的業(yè)務(wù)流程如“用戶下單”用一張獨(dú)立的UML序列圖來(lái)展示跨多個(gè)服務(wù)的詳細(xì)調(diào)用時(shí)序作為邏輯架構(gòu)圖的補(bǔ)充。交互式圖表使用一些支持交互的在線工具如Miro, Lucidchart可以為圖形添加鏈接點(diǎn)擊一個(gè)服務(wù)方塊可以跳轉(zhuǎn)到它的詳細(xì)設(shè)計(jì)文檔、代碼庫(kù)或監(jiān)控面板。這大大提升了圖的實(shí)用性。畫(huà)一張好的系統(tǒng)架構(gòu)圖本質(zhì)上是一次嚴(yán)謹(jǐn)?shù)倪壿嬎伎己透咝У囊曈X(jué)溝通。它強(qiáng)迫你去厘清模糊的邊界定義清晰的接口暴露隱藏的依賴。在我們那個(gè)三平臺(tái)融合項(xiàng)目里正是前期在架構(gòu)圖上反復(fù)的推敲和爭(zhēng)吵才避免了后期無(wú)數(shù)的集成噩夢(mèng)。所以別再把畫(huà)圖當(dāng)成負(fù)擔(dān)把它當(dāng)作最重要的設(shè)計(jì)工具和團(tuán)隊(duì)溝通語(yǔ)言。從現(xiàn)在開(kāi)始為你手頭的項(xiàng)目畫(huà)一張能真正指導(dǎo)行動(dòng)的“作戰(zhàn)地圖”吧。