SOA架構(gòu)設(shè)計(jì)經(jīng)驗(yàn)分享—架構(gòu)、職責(zé)、數(shù)據(jù)一致性

.背景介紹

最近一段時(shí)間都在做系統(tǒng)分析和設(shè)計(jì)工作，面對(duì)的業(yè)務(wù)是典型的重量級(jí)企業(yè)應(yīng)用方向。突然發(fā)現(xiàn)很多以往覺得很簡單的問題變得沒有想象的那么容易，最大的問題就是職責(zé)如何分配。論系統(tǒng)架構(gòu)設(shè)計(jì)的最大的問題，其實(shí)也就是職責(zé)的分配，分配的合理，實(shí)現(xiàn)起來就會(huì)很柔性，反之就會(huì)使架構(gòu)很混亂。

軟件的生命周期大概可以歸納為四個(gè)基本的過程，分析、設(shè)計(jì)、實(shí)現(xiàn)、測試，當(dāng)然這僅僅是一個(gè)最為粗略的表示而已。不同的方法論有著不同的使用這幾個(gè)過程的方式。RUP使用快速迭代的過程，在這個(gè)幾個(gè)子過程中適當(dāng)?shù)妮敵鲆恍┻^程制品，每次迭代都是進(jìn)行相同的分析、設(shè)計(jì)、實(shí)現(xiàn)、測試。而在Scrum中，不提倡輸出任何文檔形式的過程制品，也同樣有著上述幾個(gè)過程，強(qiáng)調(diào)以人為中心，通過溝通來解決大部分的問題。

不能用好與不好來判斷哪一種方法論，只能根據(jù)目前的實(shí)際情況綜合權(quán)衡。RUP的每次迭代中有幾個(gè)關(guān)鍵的制品對(duì)系統(tǒng)分析、設(shè)計(jì)很重要，可以說是非常重要，如：詞匯表、業(yè)務(wù)規(guī)則文檔、用例、領(lǐng)域草圖。這幾個(gè)制品對(duì)分析、設(shè)計(jì)很重要，需要從這幾個(gè)制品中提煉出設(shè)計(jì)模型最終才能落地。這主要用在業(yè)務(wù)復(fù)雜的應(yīng)用系統(tǒng)中。而Scrum更加的輕量級(jí)，可以用在互聯(lián)網(wǎng)項(xiàng)目中，業(yè)務(wù)不是太復(fù)雜的情況下。

其實(shí)我為什么要強(qiáng)調(diào)軟件工程及開發(fā)方法論，是因?yàn)槲易罱l(fā)現(xiàn)，做設(shè)計(jì)其實(shí)是建立在分析的基礎(chǔ)上的，但是這里面又有很多問題。大型企業(yè)級(jí)應(yīng)用，并不能通過一次性分析就可以得出準(zhǔn)確和全部的需求，初期階段建立的需求70%都是不準(zhǔn)確的。所以做架構(gòu)需要有分析的能力才行且是建立在適當(dāng)?shù)拈_發(fā)方論上的分析，什么時(shí)候該用RUP，什么時(shí)候該用Scrum，什么時(shí)候該用XP都很有講究。分析與設(shè)計(jì)都需要有一個(gè)執(zhí)行上下文，不同的上下文對(duì)分析、設(shè)計(jì)的執(zhí)行有著不同的要求。

有句話我覺得對(duì)架構(gòu)者來說很有啟發(fā)：分析就是做正確的事，設(shè)計(jì)就是正確的做事。架構(gòu)跟語言跟平臺(tái)關(guān)系不大，畢竟架構(gòu)是設(shè)計(jì)過程中的子過程，我想如果你的設(shè)計(jì)不合理，你用任何語言任何平臺(tái)都解決不了問題。（這里的架構(gòu)上下文指：企業(yè)應(yīng)用架構(gòu)不是基礎(chǔ)設(shè)施的系統(tǒng)架構(gòu)）

2.SOA的架構(gòu)層次

進(jìn)行SOA類型的架構(gòu)設(shè)計(jì)就需要搞清楚SOA架構(gòu)模型才行。并不能想當(dāng)然的對(duì)系統(tǒng)進(jìn)行簡單的拆分就行，需要搞清楚SOA的架構(gòu)模型是怎樣的，每一塊是干什么用的，這樣設(shè)計(jì)由分析階段輸出的需求時(shí)才能正確的劃分職責(zé)。

如果把SOA的架構(gòu)簡單的理解為是多個(gè)子系統(tǒng)之間的整合其實(shí)有點(diǎn)太過于簡單，也沒有真正搞清楚SOA的架構(gòu)模型。按照SOA的正確方法論及目標(biāo)模型，其實(shí)SOA在實(shí)現(xiàn)架構(gòu)落地上，需要考慮到對(duì)服務(wù)的組合，不斷的重用現(xiàn)有的服務(wù)，讓企業(yè)應(yīng)用可以逐步集成，快速實(shí)現(xiàn)業(yè)務(wù)的迭代。其實(shí)這就是本節(jié)要講的服務(wù)的分層，通過分層將服務(wù)按照使用類型進(jìn)行分配，上層服務(wù)對(duì)下層服務(wù)的包裝，下層服務(wù)負(fù)責(zé)原子性的操作，上層服務(wù)對(duì)下層服務(wù)進(jìn)行業(yè)務(wù)性的組合。

我們來看具體的每一層的作用及主要職責(zé)。

2.1.應(yīng)用服務(wù)（原子服務(wù)）

應(yīng)用服務(wù)就是諸如：訂單服務(wù)、倉庫服務(wù)、銷售服務(wù)、客戶管理服務(wù)，這些服務(wù)直接對(duì)應(yīng)不同的應(yīng)用系統(tǒng)，直接服務(wù)這些應(yīng)用系統(tǒng)的原子操作。訂單服務(wù)直接原子性的插入訂單，沒有任何跨其他服務(wù)的分支邏輯。倉庫服務(wù)只管自己的倉庫邏輯。同樣其他的應(yīng)用服務(wù)只管好自己的職責(zé)，杜絕對(duì)其他服務(wù)的調(diào)用。

圖1：

應(yīng)用服務(wù)位于UI與后臺(tái)之間，后臺(tái)我們可以認(rèn)為它是一異構(gòu)的系統(tǒng)或者是數(shù)據(jù)庫之類的。應(yīng)用服務(wù)的位置位于前端與后端之間，起到類似一個(gè)服務(wù)API的作用，但是SOA中的服務(wù)還遠(yuǎn)遠(yuǎn)不止這一個(gè)應(yīng)用服務(wù)，如果我們的SOA架構(gòu)中只有一種類型的服務(wù)，那么這會(huì)增加我們系統(tǒng)的耦合程度，因?yàn)槟銢]有對(duì)系統(tǒng)的服務(wù)進(jìn)行層次的劃分，你的業(yè)務(wù)功能會(huì)直接的落到某一個(gè)應(yīng)用線上的服務(wù)，繼續(xù)往下看。

2.2.組合服務(wù)

組合服務(wù)是對(duì)應(yīng)用服務(wù)的一個(gè)組合,根據(jù)實(shí)際項(xiàng)目的規(guī)模大小,不一定非要進(jìn)行物理的隔離,在代碼層面的服務(wù)化也是可以的,在將來的某一天有必要的情況下再進(jìn)行物理的拆分,畢竟物理的拆分有著嚴(yán)重的成本和代價(jià)，對(duì)系統(tǒng)的穩(wěn)定性帶來很多挑戰(zhàn)。所以經(jīng)驗(yàn)告訴我們必要的時(shí)候在進(jìn)行拆分。”分布式系統(tǒng)設(shè)計(jì)的第一個(gè)原則就是盡量不要分布式“，這是馬丁.福勒大師說的，現(xiàn)在理解確實(shí)感同身受。

圖2：

組合服務(wù)對(duì)下層的應(yīng)用服務(wù)進(jìn)行了組合，完成了一個(gè)基本的業(yè)務(wù)動(dòng)作，應(yīng)用服務(wù)中是最基本的基礎(chǔ)性的原子性的操作。但是在復(fù)雜的業(yè)務(wù)需求下大部分業(yè)務(wù)功能都需要跨越多個(gè)應(yīng)用線來完成一個(gè)最外層的企業(yè)動(dòng)作。提交訂單可能需要穿過很多應(yīng)用線，訂單管理、倉庫、財(cái)務(wù)等等環(huán)節(jié)。所以這里我們還需要一個(gè)能在最外層對(duì)組合服務(wù)進(jìn)行編排的業(yè)務(wù)服務(wù)。這個(gè)編排服務(wù)可以完全是自動(dòng)化的，通過工作流引擎進(jìn)行組合自動(dòng)化來完成，這對(duì)企業(yè)應(yīng)用的自動(dòng)化流程很有意義。

2.3.業(yè)務(wù)服務(wù)（編排服務(wù)）

業(yè)務(wù)服務(wù)是最外層的服務(wù)，向下編排了組合服務(wù)。業(yè)務(wù)服務(wù)位于最上層，當(dāng)需要有跨越多個(gè)應(yīng)用線來完成的業(yè)務(wù)，這個(gè)業(yè)務(wù)就放入業(yè)務(wù)服務(wù)中。比如提交訂單，先檢查庫存、扣減庫存（凍結(jié)庫存），然后下單，再往后通知財(cái)務(wù)，再往后通知物流等等都是一個(gè)復(fù)雜的企業(yè)服務(wù)線。這種最外層的業(yè)務(wù)邏輯如果你不進(jìn)行SOA分層然后將其放入最外層的業(yè)務(wù)服務(wù)中，你把它放入任何一個(gè)應(yīng)用線都會(huì)使系統(tǒng)調(diào)用混亂不堪。所以問題就是需要進(jìn)行縱向的劃分層次。如果進(jìn)行了SOA的層次劃分后就不會(huì)出現(xiàn)互相亂用的情況。其實(shí)這里可以參考阿里的服務(wù)設(shè)計(jì)方法。（李智慧寫的一本大型互聯(lián)網(wǎng)架構(gòu)與實(shí)踐里面也講到了服務(wù)要?jiǎng)澐謱哟危?/span>

圖3：

當(dāng)在業(yè)務(wù)服務(wù)中執(zhí)行的業(yè)務(wù)邏輯時(shí)，需要跨越多個(gè)應(yīng)用線來完成。這部分的邏輯也說是職責(zé)，如果不放入這個(gè)位置，放在哪個(gè)應(yīng)用線都不合適，放入哪個(gè)應(yīng)用線都會(huì)使系統(tǒng)調(diào)用出現(xiàn)混亂。其實(shí)這里的問題就是我們不能用一個(gè)維度來進(jìn)行SOA系統(tǒng)的設(shè)計(jì)，本來服務(wù)就具有組合特性，所以適當(dāng)?shù)奶嵘?wù)的層次是有好處的，但是應(yīng)用服務(wù)和組合服務(wù)可以在代碼層面上進(jìn)行構(gòu)建，而業(yè)務(wù)服務(wù)也叫編排服務(wù)是需要進(jìn)行物理隔離的，畢竟考慮到系統(tǒng)復(fù)雜度和穩(wěn)定性問題這是值得的。在排查問題，系統(tǒng)性能、穩(wěn)定性等等方面，物理的隔離有一定的作用，畢竟業(yè)務(wù)服務(wù)本來就是來組合多個(gè)應(yīng)用線的，這樣做會(huì)使整個(gè)系統(tǒng)架構(gòu)很清晰。