1.背景介紹
最近一段時間都在做系統(tǒng)分析和設(shè)計工作，面對的業(yè)務(wù)是典型的重量級企業(yè)應(yīng)用方向。突然發(fā)現(xiàn)很多以往覺得很簡單的問題變得沒有想象的那么容易，最大的問題就是職責(zé)如何分配。論系統(tǒng)架構(gòu)設(shè)計的最大的問題，其實(shí)也就是職責(zé)的分配，分配的合理，實(shí)現(xiàn)起來就會很柔性，反之就會使架構(gòu)很混亂。
軟件的生命周期大概可以歸納為四個基本的過程，分析、設(shè)計、實(shí)現(xiàn)、測試，當(dāng)然這僅僅是一個最為粗略的表示而已。不同的方法論有著不同的使用這幾個過程的方式。RUP使用快速迭代的過程，在這個幾個子過程中適當(dāng)?shù)妮敵鲆恍┻^程制品，每次迭代都是進(jìn)行相同的分析、設(shè)計、實(shí)現(xiàn)、測試。而在Scrum中，不提倡輸出任何文檔形式的過程制品，也同樣有著上述幾個過程，強(qiáng)調(diào)以人為中心，通過溝通來解決大部分的問題。
不能用好與不好來判斷哪一種方法論，只能根據(jù)目前的實(shí)際情況綜合權(quán)衡。RUP的每次迭代中有幾個關(guān)鍵的制品對系統(tǒng)分析、設(shè)計很重要，可以說是非常重要，如：詞匯表、業(yè)務(wù)規(guī)則文檔、用例、領(lǐng)域草圖。這幾個制品對分析、設(shè)計很重要，需要從這幾個制品中提煉出設(shè)計模型最終才能落地。這主要用在業(yè)務(wù)復(fù)雜的應(yīng)用系統(tǒng)中。而Scrum更加的輕量級，可以用在互聯(lián)網(wǎng)項(xiàng)目中，業(yè)務(wù)不是太復(fù)雜的情況下。
其實(shí)我為什么要強(qiáng)調(diào)軟件工程及開發(fā)方法論，是因?yàn)槲易罱l(fā)現(xiàn)，做設(shè)計其實(shí)是建立在分析的基礎(chǔ)上的，但是這里面又有很多問題。大型企業(yè)級應(yīng)用，并不能通過一次性分析就可以得出準(zhǔn)確和全部的需求，初期階段建立的需求70%都是不準(zhǔn)確的。所以做架構(gòu)需要有分析的能力才行且是建立在適當(dāng)?shù)拈_發(fā)方論上的分析，什么時候該用RUP，什么時候該用Scrum，什么時候該用XP都很有講究。分析與設(shè)計都需要有一個執(zhí)行上下文，不同的上下文對分析、設(shè)計的執(zhí)行有著不同的要求。
有句話我覺得對架構(gòu)者來說很有啟發(fā)：分析就是做正確的事，設(shè)計就是正確的做事。架構(gòu)跟語言跟平臺關(guān)系不大，畢竟架構(gòu)是設(shè)計過程中的子過程，我想如果你的設(shè)計不合理，你用任何語言任何平臺都解決不了問題。(這里的架構(gòu)上下文指：企業(yè)應(yīng)用架構(gòu)不是基礎(chǔ)設(shè)施的系統(tǒng)架構(gòu))
2.SOA的架構(gòu)層次
進(jìn)行SOA類型的架構(gòu)設(shè)計就需要搞清楚SOA架構(gòu)模型才行。并不能想當(dāng)然的對系統(tǒng)進(jìn)行簡單的拆分就行，需要搞清楚SOA的架構(gòu)模型是怎樣的，每一塊是干什么用的，這樣設(shè)計由分析階段輸出的需求時才能正確的劃分職責(zé)。
如果把SOA的架構(gòu)簡單的理解為是多個子系統(tǒng)之間的整合其實(shí)有點(diǎn)太過于簡單，也沒有真正搞清楚SOA的架構(gòu)模型。按照SOA的正確方法論及目標(biāo)模型，其實(shí)SOA在實(shí)現(xiàn)架構(gòu)落地上，需要考慮到對服務(wù)的組合，不斷的重用現(xiàn)有的服務(wù)，讓企業(yè)應(yīng)用可以逐步集成，快速實(shí)現(xiàn)業(yè)務(wù)的迭代。其實(shí)這就是本節(jié)要講的服務(wù)的分層，通過分層將服務(wù)按照使用類型進(jìn)行分配，上層服務(wù)對下層服務(wù)的包裝，下層服務(wù)負(fù)責(zé)原子性的操作，上層服務(wù)對下層服務(wù)進(jìn)行業(yè)務(wù)性的組合。
我們來看具體的每一層的作用及主要職責(zé)。
2.1.應(yīng)用服務(wù)(原子服務(wù))
應(yīng)用服務(wù)就是諸如：訂單服務(wù)、倉庫服務(wù)、銷售服務(wù)、客戶管理服務(wù)，這些服務(wù)直接對應(yīng)不同的應(yīng)用系統(tǒng)，直接服務(wù)這些應(yīng)用系統(tǒng)的原子操作。訂單服務(wù)直接原子性的插入訂單，沒有任何跨其他服務(wù)的分支邏輯。倉庫服務(wù)只管自己的倉庫邏輯。同樣其他的應(yīng)用服務(wù)只管好自己的職責(zé)，杜絕對其他服務(wù)的調(diào)用。
圖1：
應(yīng)用服務(wù)位于UI與后臺之間，后臺我們可以認(rèn)為它是一異構(gòu)的系統(tǒng)或者是數(shù)據(jù)庫之類的。應(yīng)用服務(wù)的位置位于前端與后端之間，起到類似一個服務(wù)API的作用，但是SOA中的服務(wù)還遠(yuǎn)遠(yuǎn)不止這一個應(yīng)用服務(wù)，如果我們的SOA架構(gòu)中只有一種類型的服務(wù)，那么這會增加我們系統(tǒng)的耦合程度，因?yàn)槟銢]有對系統(tǒng)的服務(wù)進(jìn)行層次的劃分，你的業(yè)務(wù)功能會直接的落到某一個應(yīng)用線上的服務(wù)，繼續(xù)往下看。
2.2.組合服務(wù)
組合服務(wù)是對應(yīng)用服務(wù)的一個組合,根據(jù)實(shí)際項(xiàng)目的規(guī)模大小,不一定非要進(jìn)行物理的隔離,在代碼層面的服務(wù)化也是可以的,在將來的某一天有必要的情況下再進(jìn)行物理的拆分,畢竟物理的拆分有著嚴(yán)重的成本和代價，對系統(tǒng)的穩(wěn)定性帶來很多挑戰(zhàn)。所以經(jīng)驗(yàn)告訴我們必要的時候在進(jìn)行拆分。”分布式系統(tǒng)設(shè)計的第一個原則就是盡量不要分布式“，這是馬丁.福勒大師說的，現(xiàn)在理解確實(shí)感同身受。