做一個“高大上”的架構師
以往開(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è)樣一個念頭——沒(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ì)被移動支付取代,15年内90%中小金融機構的前台將(jiāng)被取代。 移動化、智能(néng)化、雲計算和大數據將(jiāng)成(chéng)爲主流,這(zhè)就(jiù)是颠覆式的互聯網金融。變革的時(shí)代,孕育著(zhe)無限機遇,但同時(shí)也隐藏著(zhe)巨大的挑戰。相比于傳統的企業級系 統,互聯網系統有著(zhe)不同的特點,如表1所示。
![表1 互聯網系統與企業級系統的差異 表1 互聯網系統與企業級系統的差異](404.png)
可見,架構工作對(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 四維座标系統 圖1 四維座标系統](404.png)
【四維座标系統】
1. 前後(hòu)端維度(X1 … X7)
![圖2 X軸分層結構 圖2 X軸分層結構](404.png)
前後(hòu)端維度被分解爲交互、業務、領域、資源四大層,其中業務可以細分爲應用X2、框架X3,領域可以細分爲服務X4、核心X5,資源也可以細分爲代 理X6、數據X7,共七個層次,如圖2所示。服務X4可以實現API,如果公開(kāi),就(jiù)是開(kāi)放接口,調用服務層的接口,通常需要授權。代理X6可以實現 SPI,隔離耦合,避免核心X5依賴特定的外部系統或數據庫。每個層次做到高内聚,層與層之間做到低耦合,詳見表2中的X軸七層架構模型及定位所示。
![表2 X軸七層架構模型及其定位 表2 X軸七層架構模型及其定位](404.png)
在系統實現過(guò)程中,可以綜合考慮現狀,X2應用和X3框架可以不分拆,X4服務和X5核心可以不分拆,待後(hòu)續時(shí)機成(chéng)熟可以再重構分層,這(zhè)樣變更範圍僅在内部。
2. 業務維度(Y1 … Yn)
從業務維度進(jìn)行劃分,按照業務類型對(duì)系統進(jìn)行分類。業務系統的劃分更多依賴業務領域的知識。這(zhè)個維度的設計方法,本文暫不深入介紹。
當Y軸的一個業務系統需要調用Y軸的另外一個業務系統時(shí),兼顧效率和耦合,這(zhè)套架構設計方法論給出了具體的架構原則,如圖3所示。
![圖3 Y軸不同業務系統之間調用關系 圖3 Y軸不同業務系統之間調用關系](404.png)
(1)當被調用的是公共系統時(shí),那麼(me)調用將(jiāng)被視爲内部調用,即服務可以直接調用服務。考慮到公共系統比較穩定,不會(huì)經(jīng)常改變,直接調用可以減少調用環節,保障效率。
(2)當被調用的是非公共系統時(shí),那麼(me)調用將(jiāng)會(huì)被視爲外部調用,即通過(guò)代理層去調用被調用系統的對(duì)外服務接口。這(zhè)相當于把兩(liǎng)個系統後(hòu)台進(jìn)行了串聯,降低了系統之間的耦合,後(hòu)續被調用系統發(fā)生變更,對(duì)調用系統的影響也可以借由其代理層進(jìn)行了隔離。
![圖4 Z軸分層結構 圖4 Z軸分層結構](404.png)
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)一步明晰接口的參數列表。
![圖5 架構設計流程 圖5 架構設計流程](404.png)
僅僅四個步驟就(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ì)穩定,我們需要隔離外部系統或數據持久層變化帶來的影響,第二刀應該切在領域和資源之間。
第三刀:考慮到同樣的一個業務可能(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ù)可以清晰地找出層與層之間的交互接口,以及可以初步确定每個接口的參數列表。
![圖6 業務交互時(shí)序圖 圖6 業務交互時(shí)序圖](404.png)
考慮到API、領域模型接口、SPI是最爲關鍵的接口,那良好(hǎo)的設計就(jiù)顯得更爲重要。如何能(néng)夠設計出良好(hǎo)的接口?如圖7所示。
![圖7 接口設計流程圖 圖7 接口設計流程圖](404.png)
(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來滿足。
![圖8 接口類型的分類方法 圖8 接口類型的分類方法](404.png)
5. 模塊的設計方法
架構設計流程第三步,按照功能(néng)相近的原則將(jiāng)接口劃歸到不同的模塊當中。劃分模塊就(jiù)會(huì)涉及業務拆分。如圖9所示,跟分層第一刀位置一樣,我們選擇業務 層和領域層的交界處來做業務拆分。業務拆分需要跟業務專家一起(qǐ)來完成(chéng),通過(guò)這(zhè)個過(guò)程可以确定出Y軸包含哪些業務系統,而這(zhè)些業務系統的公用模塊或系統將(jiāng)會(huì) 被劃分到業務層X2、領域層X4當中。
![圖9 模塊的設計方法 圖9 模塊的設計方法](404.png)
在做完第一輪業務拆分之後(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è)樣資源、領域這(zhè)兩(liǎng)層就(jiù)形成(chéng)了。資源層内部再細分爲代理和數據,其中代理負責數據訪問及調用外部系 統服務,并以SPI方式向(xiàng)領域層提供服務。領域層内部再細分爲服務和核心,其中核心就(jiù)是領域模型的實現,而服務就(jiù)是資源模型的實現,以API方式對(duì)外提 供,并計劃加入到開(kāi)放平台(Open API)當中,服務于更多合作夥伴:第三方應用提供商。
![圖10 壹企業系統架構 圖10 壹企業系統架構](404.png)
信用卡坐席二代,這(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》。
作者:徐勝勇
![公益廣告](static/picture/201504281800.jpg)
登錄 參與評論
評論
暫無任何評論