以往開(kāi)發(fā)、測試、産品設計、項目管理的工作經(jīng)曆，對(duì)于架構工作來說(shuō)都(dōu)是财富。而那些架構理論、模式及案例，就(jiù)好(hǎo)比一顆顆珍珠，每顆都(dōu)光彩奪目，但在 具體實踐過(guò)程中，似乎理論和實踐無法很好(hǎo)地銜接，就(jiù)像缺少一根串起(qǐ)珍珠的線。本文梳理了平安科技首席應用架構師蔡學(xué)镛的架構設計方法論，這(zhè)套方法論整合了 多種(zhǒng)架構設計理論，能(néng)夠讓架構設計工作變得更加流暢和高效。

　　在職業規劃中，程序“猿”會(huì)有多個進(jìn)化方向(xiàng)：項目經(jīng)理、産品經(jīng)理、技術專家、架構師、售前經(jīng)理等。不同的選擇有不同的憧憬，但也預示著(zhe)不同的挑戰。站在人生的十字路口踯躅不前時(shí)，你的腦海中是否曾掠過(guò)這(zhè)樣(yàng)一個念頭——沒(méi)的選擇有時(shí)也是一種(zhǒng)幸福。

　　這(zhè)是我曾經(jīng)曆過(guò)的一種(zhǒng)狀态。缺什麼(me)補什麼(me)，網絡上職業規劃相關的信息就(jiù)會(huì)引起(qǐ)我的注意。偶然的機會(huì)，看到了蔡學(xué)镛老師這(zhè)方面(miàn)的坦誠分享。一路走來， 有堅持，也有放棄，而這(zhè)些取舍的背後(hòu)就(jiù)是興趣，強化優勢，然後(hòu)圍繞著(zhe)興趣去突破自己，放棄彌補非緻命缺陷。在痛苦面(miàn)前，人的本能(néng)反應就(jiù)是退縮，懷疑之前的 選擇是否正确，一旦開(kāi)始懷疑就(jiù)會(huì)讓你停滞不前。如果是外物促使你選擇了某條路線，那你極有可能(néng)就(jiù)放棄了。而如果這(zhè)條路線是你的興趣所在，那情況就(jiù)會(huì)完全不 同，它會(huì)讓你樂在其中，在遭受挫折之後(hòu)很快滿血，熱情投入，不斷突破自己。

　　古人雲：知之者不如好(hǎo)之者，好(hǎo)知者不如樂之者。愛因斯坦曾說(shuō)：興趣，是最好(hǎo)的老師。排除外部幹擾、傾聽内心，我選擇架構師作爲我下一個階段的進(jìn)化方向(xiàng)。

“高大上”的架構師之路

　　當金融遇見互聯網會(huì)發(fā)生什麼(me)？移動支付業務保持高位增長(cháng)，10年内60%的信用卡將(jiāng)會(huì)被(bèi)移動支付取代，15年内90%中小金融機構的前台將(jiāng)被(bèi)取代。 移動化、智能(néng)化、雲計算和大數據將(jiāng)成(chéng)爲主流，這(zhè)就(jiù)是颠覆式的互聯網金融。變革的時(shí)代，孕育著(zhe)無限機遇，但同時(shí)也隐藏著(zhe)巨大的挑戰。相比于傳統的企業級系 統，互聯網系統有著(zhe)不同的特點，如表1所示。

 

 

　　可見，架構工作對(duì)素質和技能(néng)的要求更“高”了，以往更多是做精做專，現在是要在精專基礎上尋求廣博；要求具備更“大”的眼界，不僅隻關注一個階段的 細節，而要關注整個産品生命周期；爲輸出高質量的架構設計，需要面(miàn)對(duì)的“上”遊客戶更多了，還(hái)涉及各類幹系人及制度規則、商業環境、政策法規等。高、大、 上，架構師之路任重而道(dào)遠！

　　這(zhè)些年，我也讀了不少架構書籍，參加了一些專業交流和培訓。這(zhè)當中有介紹架構理論的，有介紹架構模式的，有分享架構案例的，也有培訓分視圖做架構 的。業界也出現很多新的理論和模式，其中有些非常經(jīng)典，例如DDD、REST、SEDA等。而這(zhè)些理論、模式及案例，就(jiù)好(hǎo)比一顆顆珍珠，每顆都(dōu)光彩奪目， 但在實踐過(guò)程中，我覺得理論和實踐無法很好(hǎo)的銜接，就(jiù)像缺少一根串起(qǐ)珍珠的線。

　　俗話說(shuō)：讀萬卷書不如行萬裡(lǐ)路，行萬裡(lǐ)路不如閱人無數，閱人無數不如名師指路，名師指路不如自己開(kāi)悟。閱讀經(jīng)典、項目實踐、同行交流，短期内都(dōu)不能(néng) 幫自己突破瓶頸，如果能(néng)夠得到名師的指點，或許就(jiù)可以打通任督二脈。與往次不同的是，這(zhè)次蔡老師是作爲平安集團互聯網架構師、平安科技首席應用架構師的身 份做架構設計方法論培訓。據個人了解，業界從規格到實現的方法和經(jīng)驗分享非常多，但銜接需求和規格的可操作方法論比較少。而這(zhè)套方法論既整合了多種(zhǒng)理論技 術，又具備很強的可操作性。

蔡氏架構設計方法

　　針對(duì)問題域的特點，這(zhè)套方法論采用與之相對(duì)應的多維度、立體化、分層次、動态演進(jìn)的策略，通過(guò)空間（X、Y、Z）三個維度及時(shí)間（T）維度將(jiāng)問題域 解構成(chéng)可以輕松應對(duì)的小方塊，分而治之。同時(shí)，空間（X、Y、Z）三個維度聯動，專門爲單個維度解決不了的問題提供解決方案。時(shí)間（T）維度將(jiāng)問題分解到 一個時(shí)間範圍内，分步驟按節奏逐一解決，如圖1所示。接下來，讓我們進(jìn)入這(zhè)個四維的架構時(shí)空一探究竟吧！

 

 

【四維座标系統】

1. 前後(hòu)端維度（X1 … X7）

 

 

　　前後(hòu)端維度被(bèi)分解爲交互、業務、領域、資源四大層，其中業務可以細分爲應用X2、框架X3，領域可以細分爲服務X4、核心X5，資源也可以細分爲代 理X6、數據X7，共七個層次，如圖2所示。服務X4可以實現API，如果公開(kāi)，就(jiù)是開(kāi)放接口，調用服務層的接口，通常需要授權。代理X6可以實現 SPI，隔離耦合，避免核心X5依賴特定的外部系統或數據庫。每個層次做到高内聚，層與層之間做到低耦合，詳見表2中的X軸七層架構模型及定位所示。

 

 

　　在系統實現過(guò)程中，可以綜合考慮現狀，X2應用和X3框架可以不分拆，X4服務和X5核心可以不分拆，待後(hòu)續時(shí)機成(chéng)熟可以再重構分層，這(zhè)樣(yàng)變更範圍僅在内部。

2. 業務維度（Y1 … Yn）

　　從業務維度進(jìn)行劃分，按照業務類型對(duì)系統進(jìn)行分類。業務系統的劃分更多依賴業務領域的知識。這(zhè)個維度的設計方法，本文暫不深入介紹。

　　當Y軸的一個業務系統需要調用Y軸的另外一個業務系統時(shí)，兼顧效率和耦合，這(zhè)套架構設計方法論給出了具體的架構原則，如圖3所示。

 

 

（1）當被(bèi)調用的是公共系統時(shí)，那麼(me)調用將(jiāng)被(bèi)視爲内部調用，即服務可以直接調用服務。考慮到公共系統比較穩定，不會(huì)經(jīng)常改變，直接調用可以減少調用環節，保障效率。

（2）當被(bèi)調用的是非公共系統時(shí)，那麼(me)調用將(jiāng)會(huì)被(bèi)視爲外部調用，即通過(guò)代理層去調用被(bèi)調用系統的對(duì)外服務接口。這(zhè)相當于把兩(liǎng)個系統後(hòu)台進(jìn)行了串聯，降低了系統之間的耦合，後(hòu)續被(bèi)調用系統發(fā)生變更，對(duì)調用系統的影響也可以借由其代理層進(jìn)行了隔離。

 

 

3. 系統維度（Z1 … Zn）

　　該維度主要關注軟件、容器、運行時(shí)、操作系統、虛拟機、硬件等這(zhè)些與業務無關系統的架構。Z軸的系統可以分别用于前端優化、應用優化、平台優化、資源優化等層面(miàn)，如圖4所示。

4. 時(shí)間維度（T1 … Tn）

　　對(duì)于一個新産品來說(shuō)，架構不是一次成(chéng)型的，從初始到成(chéng)熟要經(jīng)過(guò)一個不斷演進(jìn)的過(guò)程。對(duì)于一個已有産品來說(shuō)，架構的優化也是要結合實際情況分步驟實施。

　　除了技術上的考慮之外，我們還(hái)需要考慮市場及投資等方面(miàn)的情況。通常在研發(fā)初期，産品本身的定位還(hái)不太清晰，需要快速地叠代投放市場獲取先發(fā)優勢以 及驗證想法，不斷地明确産品的定位。這(zhè)個階段産品需求變動非常頻繁，許多架構的驅動因素尚未明确，如果過(guò)于關注架構，那産品推向(xiàng)市場就(jiù)會(huì)遙遙無期。随著(zhe)産 品定位的逐步清晰，架構的驅動因素及約束條件都(dōu)逐漸浮出水面(miàn)，這(zhè)時(shí)架構設計的重要性就(jiù)顯現出來了。另外，我們還(hái)需要根據投資預算來調整架構設計。如果投入 比較充裕，那我們就(jiù)可以投入更多的人力來提前將(jiāng)架構驅動因素研究清楚，甚至可以針對(duì)不确定的約束提供多套備選方案。

【X軸設計——架構設計流程】

　　如圖5的架構設計流程圖所示。

　　第一步，結合現實情況，將(jiāng)系統劃分成(chéng)多個層次。

　　第二步，确定層與層之間的關系，梳理出層與層之間的交互接口。

　　第三步，將(jiāng)功能(néng)相近的接口劃歸到一個模塊，确保模塊高内聚，對(duì)外低耦合。

　　第四步，以上面(miàn)爲基礎，進(jìn)一步明晰接口的參數列表。

 

 

　　僅僅四個步驟就(jiù)完成(chéng)了架構設計嗎？這(zhè)會(huì)不會(huì)太簡單空洞了呢？各位看官，不要著(zhe)急，請聽蔡老師慢慢道(dào)來，每個步驟都(dōu)有極具可操作性的方法及工具。

1. 層次的切分方法

　　面(miàn)對(duì)一個龐然大物，你該如何下手呢？不用擔心，這(zhè)已給你準備了庖丁解牛的方法，輕輕松松把一個複雜的大系統變得可以掌控了。

　　第一刀：按照這(zhè)套方法論來進(jìn)行架構設計，最理想的情況是將(jiāng)X軸切分成(chéng)七層。而第一刀應該先切在業務和領域之間，即通過(guò)API把兩(liǎng)邊解耦。交互和業務跟用戶關聯度高，經(jīng)常随需求變化而改動，而領域和資源相對(duì)比較穩定。

　　第二刀：考慮到要完成(chéng)某些業務功能(néng)，系統可能(néng)需要調用外部系統來協同完成(chéng)，爲了保證領域層相對(duì)穩定，我們需要隔離外部系統或數據持久層變化帶來的影響，第二刀應該切在領域和資源之間。

　　第三刀：考慮到同樣(yàng)的一個業務可能(néng)會(huì)有多套界面(miàn)，例如有Web版、桌面(miàn)版、移動版等，爲了提高重用，隔離變更，接下來要把交互和業務切開(kāi)。

　　通過(guò)上面(miàn)這(zhè)“溫柔的三刀”，我們就(jiù)可以把一個大塊頭切分成(chéng)七個層次。

2. 接口的設計方法

　　在确定分層之後(hòu)，我們可以把每個業務需求的交互時(shí)序圖畫出來，而分層就(jiù)是交互時(shí)序圖的主角，如圖6所示，這(zhè)時(shí)我們就(jiù)可以清晰地找出層與層之間的交互接口，以及可以初步确定每個接口的參數列表。

 

 

　　考慮到API、領域模型接口、SPI是最爲關鍵的接口，那良好(hǎo)的設計就(jiù)顯得更爲重要。如何能(néng)夠設計出良好(hǎo)的接口？如圖7所示。

 

 

（1）找出領域對(duì)象：通過(guò)多輪領域訪談，與業務專家一起(qǐ)分析出領域對(duì)象。另外，也可以通過(guò)研究外部接口及數據字典來明晰領域對(duì)象，反過(guò)來也可以豐富外部接口和數據字典。

（2）設計領域模型、資源模型、數據模型：在挖掘領域對(duì)象的過(guò)程中，我們就(jiù)可以開(kāi)始設計領域模型了，确定領域對(duì)象之間的關聯關系。當關聯關系逐步清 晰之後(hòu)，我們還(hái)可以根據關聯關系的密集程度對(duì)領域對(duì)象的組織方式做一些調整，找出核心的領域對(duì)象集合，其他領域對(duì)象可以歸類到圍繞核心領域對(duì)象集合的衛星 集合裡(lǐ)面(miàn)。通過(guò)多輪調整，可以得到一個能(néng)夠映射業務、關系簡化的領域模型。然後(hòu)兵分兩(liǎng)路啓動資源模型和數據模型的設計工作。上述三個模型之間的關系及區 别，請參見下文。

（3）設計領域模型接口、API、SPI、數據庫：在設計領域模型接口時(shí)，要盡量做到不多不少，這(zhè)些接口都(dōu)是對(duì)外提供服務所必需的，也是全面(miàn)的，并 且粒度要細。在設計API時(shí)，要考慮内外客戶的需求和特點，做到方便易用，可以參考RESTful API設計相關的資料。在設計SPI時(shí)，要盡量隔離資源層對(duì)領域層的影響。

在完成(chéng)上述工作後(hòu)，我們就(jiù)可以進(jìn)入實施階段，開(kāi)始啓動代理層、核心層和服務層的代碼設計工作。另外，如果是對(duì)線上已有系統進(jìn)行升級，那還(hái)要開(kāi)始制訂數據的遷移計劃。

3. 三個模型之間的關系及區别

　　領域模型，映射特定業務領域當中核心領域對(duì)象及其關聯關系，這(zhè)些對(duì)象及關系的存在都(dōu)是完成(chéng)業務規則所必需的，甚至是法律法規等明文要求的，不會(huì)輕易變動。

　　資源模型，基于領域模型，從爲内外客戶提供服務的角度分析定義出來的，包含了資源對(duì)象及其關聯關系。根據内外客戶的特點及需求，我們可以調整資源模型中的内容。

　　數據模型，基于領域模型，從存儲（持久化或緩存）信息的角度分析定義出來的，包含數據對(duì)象及其關聯關系。根據存儲載體的特點及需求，我們可以調整數據模型中的内容。

4. 接口類型的分類方法

　　如何确定圖形用戶接口（GUI）和應用編程接口（API）的分工呢？如圖8所示，在收集業務需求的過(guò)程中，我們可以标識出發(fā)起(qǐ)這(zhè)個需求的角色是人還(hái)是程序。如果發(fā)起(qǐ)需求的是人，那就(jiù)需要通過(guò)GUI來滿足；而如果發(fā)起(qǐ)需求的是程序，那就(jiù)要通過(guò)API來滿足。

 

 

5. 模塊的設計方法

　　架構設計流程第三步，按照功能(néng)相近的原則將(jiāng)接口劃歸到不同的模塊當中。劃分模塊就(jiù)會(huì)涉及業務拆分。如圖9所示，跟分層第一刀位置一樣(yàng)，我們選擇業務 層和領域層的交界處來做業務拆分。業務拆分需要跟業務專家一起(qǐ)來完成(chéng)，通過(guò)這(zhè)個過(guò)程可以确定出Y軸包含哪些業務系統，而這(zhè)些業務系統的公用模塊或系統將(jiāng)會(huì) 被(bèi)劃分到業務層X2、領域層X4當中。

 

 

　　在做完第一輪業務拆分之後(hòu)，就(jiù)可以進(jìn)入設計階段，确定業務的交互流程，進(jìn)一步明确業務層X2、領域層X4。然後(hòu)并行啓動交互設計和建模，其中交互設 計是爲了确定交互層X1和業務層X2，而建模是爲了明确領域層X4、X5以及資源層X6。設計和業務拆分可以叠代多次，直至可以進(jìn)入下個階段——模塊設計 及數據存儲設計。

　　根據業務設計的結果，我們可以進(jìn)行模塊設計，明确X1到X6等層的模塊組成(chéng)。而建模的結果可以用于數據存儲設計，明确X1、X3、X6、X7這(zhè)些層 次的模塊劃分。模塊設計和數據存儲設計可以互相推動。當上述設計都(dōu)完成(chéng)之後(hòu)，就(jiù)可以進(jìn)入網絡部署規劃，最後(hòu)就(jiù)可以做人員機器規劃，進(jìn)入實施階段。随著(zhe)實施 深入，發(fā)現問題後(hòu)及時(shí)重新叠代整個過(guò)程。

在實戰中踐行理論

　　誠如蔡老師所說(shuō)：幹貨甚幹，請配合開(kāi)水服用！那我想這(zhè)開(kāi)水就(jiù)是實踐吧。打鐵趁熱，我把正參與的兩(liǎng)個項目作爲實踐這(zhè)套方法論的戰場。

　　這(zhè)兩(liǎng)個項目各有特點，在實踐過(guò)程中就(jiù)會(huì)有不同的挑戰。其中，壹企業，是平安首個基于SaaS雲技術打造的企業管理平台，滿足中小企業人事(shì)、财務、客 戶關系等管理需求，是一個全新的項目。而信用卡坐席系統二代是一個升級項目，一代系統已服役了很多年，累積了許多可以繼承的子系統和模塊。

　　壹企業的系統架構如圖10所示，X軸切了兩(liǎng)刀半，這(zhè)樣(yàng)資源、領域這(zhè)兩(liǎng)層就(jiù)形成(chéng)了。資源層内部再細分爲代理和數據，其中代理負責數據訪問及調用外部系 統服務，并以SPI方式向(xiàng)領域層提供服務。領域層内部再細分爲服務和核心，其中核心就(jiù)是領域模型的實現，而服務就(jiù)是資源模型的實現，以API方式對(duì)外提 供，并計劃加入到開(kāi)放平台（Open API）當中，服務于更多合作夥伴：第三方應用提供商。

 

 

　　信用卡坐席二代，這(zhè)是我們非常熟悉的一個業務領域，市場價值也是可以預期的。基于上述前提，信用卡坐席二代在X軸上切分爲交互、業務、領域、資源四 大層。其中，交互層就(jiù)是以界面(miàn)爲主；業務層暫不分應用和框架，均統一在應用裡(lǐ)面(miàn)；領域層分爲服務和核心，其中服務將(jiāng)加入開(kāi)放平台（Open API），核心就(jiù)由信用卡開(kāi)放平台承擔；資源層分爲代理和數據，負責數據持久化，以及與信用卡業務相關的外圍系統進(jìn)行交互。

　　懂得很多道(dào)理，不一定能(néng)過(guò)好(hǎo)這(zhè)一生。而懂得這(zhè)套方法論，那架構設計就(jiù)可以做得更好(hǎo)！分享的意義更多在于梳理自己認知，加深對(duì)這(zhè)套方法論的理解。鑒于個人水平有限，文中一定存在些許偏頗之處，歡迎大家交流指正，一起(qǐ)玩轉這(zhè)套蔡氏架構設計方法論。

　　文中許多想法來自嚴雲濤、孫國(guó)勇、江琳、曾荀、王剛、許揚、顔詩超、楊果林等小夥伴們的分享與讨論，在此向(xiàng)大家表示感謝！

　　另外需要說(shuō)明的是，文中部分插圖源自蔡學(xué)镛老師的培訓教材《軟件架構入門》及書籍《編程ING》。

　　作者：徐勝勇