詳解SOA五種基本架構(gòu)模式

詳解SOA五種基本架構(gòu)模式

目前，面向服務(wù)的架構(gòu)（SOA）已成為連接復(fù)雜服務(wù)系統(tǒng)的主要解決方案。雖然SOA的理論很容易理解，但要部署一個(gè)設(shè)計(jì)良好、真正實(shí)用的SOA系統(tǒng)卻非常困難。本文試圖通過(guò)解析SOA的模式，提供與架構(gòu)相關(guān)的技術(shù)指導(dǎo)，進(jìn)而對(duì)以上問(wèn)題提供詳盡的的解答。

在本文中，一共提到了五種模式。表1列出了這五種模式以及各自相關(guān)的問(wèn)題。

表1：模式列表

其中服務(wù)托管（ServiceHost）與主動(dòng)式服務(wù)（Active Service）是兩種最常見(jiàn)的模式——即使服務(wù)的使用范圍很小，通常也會(huì)使用這兩種模式。這兩種模式的主要內(nèi)容都與解決服務(wù)相關(guān)問(wèn)題有關(guān)，即與具體的服務(wù)部署有關(guān)。

模式一：服務(wù)托管

服務(wù)托管是我們要討論的第一個(gè)模式。它是最基本的模式，或者至少是最基本的模式之一。服務(wù)托管模式主要負(fù)責(zé)運(yùn)行著服務(wù)實(shí)例的環(huán)境，以及與此相關(guān)的路由任務(wù)。

問(wèn)題

隨便選一個(gè)服務(wù)，任何服務(wù)都可以，別告訴我具體是哪個(gè)：）。你可以找到一些處理傳入的消息或請(qǐng)求的監(jiān)聽(tīng)代碼；你可以找到一些連接組件的代碼，還有一些初始化并激活這個(gè)服務(wù)的代碼；或許你還能找到一些能適當(dāng)?shù)嘏渲梅?wù)的代碼。有沒(méi)有覺(jué)得我很厲害？實(shí)際上，你可以在服務(wù)里找到上面的所有代碼，至少是大部分。

有許多工作都是重復(fù)性的、常見(jiàn)的。我們可以好好利用這一點(diǎn)。

如何使服務(wù)能夠適應(yīng)不同的配置，避免設(shè)置監(jiān)聽(tīng)器、組件連接等重復(fù)性常規(guī)工作？

第一個(gè)辦法（實(shí)際上也不是什么辦法），就是為每一個(gè)服務(wù)重寫(xiě)所有的連接代碼。很顯然，這不是個(gè)好方法，因?yàn)橹貙?xiě)的次數(shù)越多，就越可能產(chǎn)生一些缺陷。并且，對(duì)于維護(hù)來(lái)說(shuō)，許多重復(fù)的代碼產(chǎn)生的問(wèn)題更為嚴(yán)重。在維護(hù)的時(shí)候，你不僅要確保每一個(gè)服務(wù)中的缺陷都已經(jīng)得到修正，還要保證沒(méi)有任何疏漏、所有的服務(wù)都已經(jīng)同步更新。

另一個(gè)相對(duì)較合理的辦法，就是創(chuàng)建一個(gè)共同任務(wù)庫(kù)，所有的服務(wù)都通過(guò)API與庫(kù)相連接。這樣確實(shí)會(huì)有所幫助，但是為了充分利用庫(kù)的功能，你仍然需要編寫(xiě)連接代碼。

還有一個(gè)辦法是利用繼承創(chuàng)建一個(gè)超類(lèi)，用超類(lèi)實(shí)現(xiàn)共同的功能，然后讓各個(gè)服務(wù)繼承這個(gè)類(lèi)。然而利用繼承也有問(wèn)題，因?yàn)榉?wù)的功能通常無(wú)法通過(guò)一個(gè)單獨(dú)的類(lèi)獲得很好的實(shí)現(xiàn)。此外，不同的服務(wù)所處理的業(yè)務(wù)也完全不同——否則它們就是一樣的服務(wù)了。因此，也無(wú)法讓把這些服務(wù)歸于同一類(lèi)結(jié)構(gòu)。

繼承幾乎已經(jīng)可以解決我們面臨的問(wèn)題——因?yàn)槲覀冎恍枰獙?xiě)一次代碼，只有不同的服務(wù)才需要定制。如果想不用繼承得到相同的結(jié)果，我們就得使用框架。 解決方案 創(chuàng)建一個(gè)通用的服務(wù)托管組件，把它當(dāng)作服務(wù)的容器或者框架。容器是可以配置的，并執(zhí)行服務(wù)連接、安裝等工作。

服務(wù)托管就像是一個(gè)肩負(fù)著許多職責(zé)的迷你框架。它的第一個(gè)職責(zé)就是正確地示例服務(wù)所包含的組件或類(lèi)。服務(wù)托管還負(fù)責(zé)讀取配置信息，比如，它可以讀取服務(wù)消費(fèi)者用來(lái)連接服務(wù)的端口。其它職責(zé)包括創(chuàng)建服務(wù)環(huán)境，比如在終端創(chuàng)建監(jiān)聽(tīng)器。最后，服務(wù)托管可以負(fù)責(zé)連接組件——終端監(jiān)聽(tīng)器上的協(xié)議綁定或者創(chuàng)建一個(gè)與數(shù)據(jù)庫(kù)的連接。所有這些職責(zé)的共同特征是它們都與服務(wù)的實(shí)例化和初始化有關(guān)，并且正如我們?cè)趩?wèn)題部分所描述的一樣，你很可能會(huì)在多個(gè)服務(wù)中遇到同樣的情況。前面已經(jīng)提到，服務(wù)托管是一個(gè)框架，與第二種方法中描述的庫(kù)的概念有所不同。庫(kù)是一個(gè)實(shí)用類(lèi)或方法集，你可以調(diào)用它們來(lái)獲取特定的功能。而框架則包含了一些功能或流程，并通過(guò)調(diào)用代碼來(lái)擴(kuò)展流程或?qū)⑵滢D(zhuǎn)變?yōu)榫唧w的流程。這就是“控制反轉(zhuǎn)（Inversion of Control）”原理。這種原理已經(jīng)在面向?qū)ο蟮目蚣苤蝎@得廣泛的應(yīng)用，比如Spring或Spring.NET、Picocontainers等。

服務(wù)托管模式與其它方法相比有許多優(yōu)勢(shì)。其中一個(gè)優(yōu)勢(shì)前面已經(jīng)提到——即服務(wù)托管是一種框架，它可以調(diào)用代碼來(lái)改善性能，而無(wú)需你親自進(jìn)行編排。另一個(gè)優(yōu)勢(shì)是它能更好地實(shí)現(xiàn)開(kāi)放/封閉原則（OCP）。OCP原則認(rèn)為類(lèi)應(yīng)該是可以擴(kuò)展的，但是不能修改；而框架的概念正是這個(gè)原則的具體表現(xiàn)。

一個(gè)服務(wù)托管可以托管多個(gè)服務(wù)——雖然這種情況可能并不常見(jiàn)。我們?cè)?jīng)構(gòu)建了一個(gè)系統(tǒng)，使用的方案規(guī)模小到一臺(tái)計(jì)算機(jī)即可應(yīng)付。這真的很方便。如果換另一種方案，那么服務(wù)可能就要擴(kuò)展到多臺(tái)計(jì)算機(jī)上，這樣你就得應(yīng)用多個(gè)服務(wù)托管實(shí)例，各個(gè)主機(jī)托管服務(wù)的一部分，而不是整個(gè)服務(wù)。

服務(wù)托管模式已得到了技術(shù)供應(yīng)商的廣泛應(yīng)用，這一點(diǎn)我們可以在下面的技術(shù)相關(guān)部分看到。

模式二：主動(dòng)式服務(wù)

服務(wù)的自治性（Autonomous）很重要。自治性能夠提高服務(wù)之間的松耦合性，并使整體方案產(chǎn)生更好的靈活性。但是自治性服務(wù)有什么實(shí)際意義呢？有人說(shuō)，自治性意味著在不同的服務(wù)上工作的團(tuán)隊(duì)的自治性。這種定義表示，由于各個(gè)服務(wù)之間只有契約上的關(guān)系，因此服務(wù)之間幾乎沒(méi)有依賴(lài)性。這意味著各團(tuán)隊(duì)可以獨(dú)立工作，專(zhuān)心于自己的服務(wù)，而不會(huì)互相絆腳。雖然這是一個(gè)不錯(cuò)的“功能”，但是同時(shí)還有一個(gè)更有價(jià)值（比如說(shuō)商業(yè)價(jià)值）的定義，就是服務(wù)是非常自主（self-sufficient ）的。下面我們通過(guò)一個(gè)示例來(lái)解釋這個(gè)定義。

問(wèn)題

有一家報(bào)紙訂閱代理機(jī)構(gòu)（比如Ebsco或Blackwell），它需要為客戶(hù)創(chuàng)建一份申請(qǐng)。申請(qǐng)服務(wù)的一項(xiàng)內(nèi)容是產(chǎn)生一份形式上的清單。要得到這樣的一份清單，該機(jī)構(gòu)必須同時(shí)有給顧客的折扣率和從各出版商處能夠得到的折扣，這樣才能計(jì)算出這份申請(qǐng)是否有利潤(rùn)。 就是這樣一個(gè)流程的簡(jiǎn)單示意圖。

在場(chǎng)景示例中，申請(qǐng)服務(wù)需要等待另外兩個(gè)服務(wù)的信息。顧客服務(wù)是內(nèi)部服務(wù)，與申請(qǐng)服務(wù)是同一系統(tǒng)；但出版商的折扣服務(wù)卻很可能是外部服務(wù)——如果出版商的系統(tǒng)沒(méi)有聯(lián)機(jī)，那么會(huì)對(duì)我們的申請(qǐng)服務(wù)造成什么影響呢？會(huì)造成申請(qǐng)服務(wù)無(wú)法使用。即使我們花費(fèi)了天文數(shù)字的資金來(lái)保證申請(qǐng)服務(wù)的容錯(cuò)性，但現(xiàn)在的問(wèn)題是完全無(wú)法使用，因?yàn)樯暾?qǐng)服務(wù)是與外部的出版商的服務(wù)隨時(shí)耦合的。因此申請(qǐng)服務(wù)不具有真正的自治性。

如何提高服務(wù)的獨(dú)立性以及如何處理暫時(shí)性的問(wèn)題？

上面所描述的問(wèn)題表明，僅僅根據(jù)請(qǐng)求喚醒的被動(dòng)式服務(wù)是有問(wèn)題的，因?yàn)榉?wù)可能無(wú)法滿(mǎn)足依賴(lài)于外部服務(wù)的契約條件（或服務(wù)等級(jí)協(xié)議）。

一個(gè)解決辦法是讓服務(wù)對(duì)先前的結(jié)果進(jìn)行緩存，但這只能解決部分問(wèn)題，因?yàn)檫@樣做數(shù)據(jù)就無(wú)法得到及時(shí)更新，并且時(shí)而也會(huì)有緩存失效的情況發(fā)生，這時(shí)仍然需要連接其它服務(wù)。這種方法還有另一個(gè)問(wèn)題，那就是如果傳入的請(qǐng)求過(guò)多，在處理一個(gè)請(qǐng)求的時(shí)候，其它的請(qǐng)求就會(huì)處于“等待”的狀態(tài)，這樣又會(huì)產(chǎn)生資源問(wèn)題，因?yàn)槎@些“等待”的請(qǐng)求都需要外部服務(wù)的輸入。

即使我們解決了前面的緩存問(wèn)題，我們?nèi)匀坏锰幚砥渌臅簳r(shí)性事件。暫時(shí)性事件包括重復(fù)發(fā)生，或者與時(shí)間相關(guān)的一次性事件。比如，生成每月賬單或發(fā)布股票數(shù)據(jù)或任何其它重復(fù)性的報(bào)告都是暫時(shí)性事件。一種解決方法是從外部編排服務(wù)。這種方法的問(wèn)題是你得將服務(wù)的業(yè)務(wù)邏輯具體化。但是請(qǐng)記住，封閉的服務(wù)層是應(yīng)用SOA的一個(gè)重要原因。因此我們得另尋解決方案。

解決方案

要使服務(wù)成為主動(dòng)式服務(wù)至少需要一個(gè)主動(dòng)類(lèi)（Active Class），這個(gè)類(lèi)可以在邊界上，或者服務(wù)上，或者兩者都有。然后讓這個(gè)主動(dòng)類(lèi)處理暫時(shí)性問(wèn)題和管理自治性。 主動(dòng)服務(wù)模式意味著在服務(wù)層上執(zhí)行“主動(dòng)類(lèi)”（見(jiàn)圖4）。在Official UML定義中，“主動(dòng)類(lèi)”是指“不需要調(diào)用方法即可啟動(dòng)自身行為的對(duì)象?！边@定義對(duì)服務(wù)也適用。就是說(shuō)，服務(wù)可以有獨(dú)立的線(xiàn)程來(lái)處理循環(huán)類(lèi)事件，比如每月賬單或發(fā)布狀態(tài)。主動(dòng)式服務(wù)也可以監(jiān)控自身的情況，處理超時(shí)，甚至可以用來(lái)處理請(qǐng)求

那么，怎么使用主動(dòng)服務(wù)模式來(lái)解決我們上面提到的問(wèn)題呢？就像帕特·森田在《空手道小子》里扮演的宮城先生所說(shuō)，“最好的防守就是不要在場(chǎng)?！比绻阋苊獾却硪粋€(gè)服務(wù)這種事情發(fā)生，那么最好的辦法就是不要等待；你可以主動(dòng)地、周期性地從其它服務(wù)獲取數(shù)據(jù)，更新你的緩存。你還能給其它服務(wù)減少類(lèi)似的麻煩，并預(yù)先發(fā)布自己的變化狀態(tài)。表面上看起來(lái)，緩存數(shù)據(jù)可能會(huì)引起數(shù)據(jù)重復(fù)的問(wèn)題，但實(shí)際上這種情況是不會(huì)發(fā)生的（詳見(jiàn)下面標(biāo)注）。

緩存與數(shù)據(jù)重復(fù)問(wèn)題 我想有些人，特別是那些學(xué)過(guò)數(shù)據(jù)庫(kù)的人，看到我說(shuō)從遠(yuǎn)程服務(wù)主動(dòng)獲取緩存數(shù)據(jù)的時(shí)候，肯定會(huì)從椅子上蹦起來(lái)質(zhì)疑我遠(yuǎn)程數(shù)據(jù)復(fù)制的動(dòng)機(jī)，認(rèn)為我是不是大腦出了什么問(wèn)題。然而，在我看來(lái)，這已經(jīng)不是相同的數(shù)據(jù)了。緩存在服務(wù)上的數(shù)據(jù)是服務(wù)的數(shù)據(jù)，可以用來(lái)計(jì)算、處理甚至根據(jù)服務(wù)需要進(jìn)行修改。當(dāng)然，你也必須明白緩存數(shù)據(jù)的服務(wù)并不是負(fù)責(zé)控制數(shù)據(jù)的。

一個(gè)帶有計(jì)時(shí)器的線(xiàn)程基本上足夠應(yīng)付其它暫時(shí)性事件了（如果事件少，你可以為每一個(gè)事件安排一個(gè)定時(shí)器；或者定時(shí)喚醒，檢查哪些事件需要處理并處理它們）。

使用邊界組件的線(xiàn)程處理契約相關(guān)的暫時(shí)性問(wèn)題是一個(gè)好辦法（比如，及時(shí)發(fā)布狀態(tài)、超時(shí)等），而服務(wù)線(xiàn)程則可以處理純業(yè)務(wù)類(lèi)的問(wèn)題，比如發(fā)送每月賬單或者處理傳入的消息隊(duì)列。 現(xiàn)在我們看一下如何使用主動(dòng)服務(wù)模式重裝安排如圖的情況。簡(jiǎn)單重復(fù)一下，如圖是一個(gè)申請(qǐng)服務(wù)的流程，它需要從外部的發(fā)布服務(wù)獲取外部數(shù)據(jù)，并同顧客服務(wù)一起為顧客生成一份清單。

現(xiàn)在我們讓申請(qǐng)服務(wù)主動(dòng)地定期獲取折扣信息并緩存結(jié)果，這樣當(dāng)收到產(chǎn)生一份清單的請(qǐng)求時(shí)，申請(qǐng)服務(wù)就可以即時(shí)計(jì)算折扣，更快地返回結(jié)果，并且（在處理清單請(qǐng)求時(shí)）無(wú)需依賴(lài)外部服務(wù)。使用了主動(dòng)式服務(wù)，請(qǐng)求服務(wù)便與其它服務(wù)分離了。

主動(dòng)服務(wù)模式差不多就是一種理念，沒(méi)有太多的技術(shù)成分。

模式三：事務(wù)處理服務(wù)模式

服務(wù)構(gòu)建的另一個(gè)重要屬性是：怎么處理從邊界組件或服務(wù)中得到的信息？事務(wù)處理服務(wù)模式（Transactional Service Pattern）可以解決這種問(wèn)題，并且還能解決可靠性問(wèn)題。

可以把SOA活動(dòng)簡(jiǎn)化為服務(wù)收到服務(wù)消費(fèi)者要求做某件任務(wù)的請(qǐng)求，服務(wù)處理請(qǐng)求（可能還會(huì)請(qǐng)求其它服務(wù)一起做這件任務(wù)），然后回應(yīng)發(fā)起請(qǐng)求的服務(wù)消費(fèi)者。圖6顯示了這樣的一個(gè)商業(yè)系統(tǒng)中的活動(dòng)場(chǎng)景。前臺(tái)與訂購(gòu)服務(wù)進(jìn)行對(duì)話(huà)。訂購(gòu)服務(wù)登記訂單，把訂單發(fā)送到供應(yīng)商，然后通知賬單服務(wù)。這些事件處理完成后，訂購(gòu)服務(wù)向電子商務(wù)前臺(tái)應(yīng)用發(fā)送一條確認(rèn)信息。這一切看起來(lái)井然有序，但萬(wàn)一中途發(fā)生錯(cuò)誤怎么辦？

問(wèn)題

比如說(shuō)，訂購(gòu)服務(wù)在確認(rèn)訂單與處理的中途產(chǎn)生故障的話(huà)，也就是圖6中的步驟1.1與2.0之間，會(huì)出現(xiàn)什么情況呢？我想顧客應(yīng)該會(huì)坐在舒適的沙發(fā)上，喝著茶水，等著郵遞員把她訂購(gòu)的東西送過(guò)來(lái)。但是雖然她在等，訂單卻已經(jīng)消失得無(wú)影無(wú)蹤了。

那么如果服務(wù)是在報(bào)賬服務(wù)處理訂單之間出現(xiàn)故障呢，也就是步驟2.3之前。這種情況下，訂購(gòu)?fù)瑯訒?huì)消失——除非訂購(gòu)系統(tǒng)不等待報(bào)賬便處理了訂單，這幾乎是不可能的。更糟糕的是，我們已經(jīng)向供應(yīng)商發(fā)送了訂單，供應(yīng)商已經(jīng)把賬單發(fā)了過(guò)來(lái)，并且貨物也隨之送了過(guò)來(lái)，我們還得給貨物準(zhǔn)備庫(kù)存。

消息處理過(guò)程處處都可能出現(xiàn)前面提到的這些情況。我們可以安慰自己，說(shuō)大部分情況下系統(tǒng)會(huì)正常工作。然而就像莫非定律所說(shuō)——我們的服務(wù)最終必然會(huì)在那宗百萬(wàn)美元的訂單上垮掉?，F(xiàn)在的問(wèn)題是：

如何讓服務(wù)可靠地處理請(qǐng)求？

其中一個(gè)方案是把這個(gè)責(zé)任推給服務(wù)消費(fèi)者。在上面提到的場(chǎng)景中，這意味著如果消費(fèi)者沒(méi)有在步驟2.5中收到訂單確認(rèn)信息，那么這個(gè)訂單就是失敗的。然而首先，這個(gè)方法并不健全，并會(huì)降低服務(wù)的自治性——服務(wù)無(wú)法控制消費(fèi)者，也無(wú)法處理一些其它問(wèn)題。另外，這只能解決部分問(wèn)題——那些與服務(wù)消費(fèi)者有關(guān)的問(wèn)題。服務(wù)之間的相互作用呢？比如在上面的訂購(gòu)場(chǎng)景中提到的——即使在步驟2.1向供應(yīng)商發(fā)送訂單以后，仍然可能出現(xiàn)問(wèn)題。

其中一個(gè)方案是把這個(gè)責(zé)任推給服務(wù)消費(fèi)者。在上面提到的場(chǎng)景中，這意味著如果消費(fèi)者沒(méi)有在步驟2.5中收到訂單確認(rèn)信息，那么這個(gè)訂單就是失敗的。然而首先，這個(gè)方法并不健全，并會(huì)降低服務(wù)的自治性——服務(wù)無(wú)法控制消費(fèi)者，也無(wú)法處理一些其它問(wèn)題。另外，這只能解決部分問(wèn)題——那些與服務(wù)消費(fèi)者有關(guān)的問(wèn)題。服務(wù)之間的相互作用呢？比如在上面的訂購(gòu)場(chǎng)景中提到的——即使在步驟2.1向供應(yīng)商發(fā)送訂單以后，仍然可能出現(xiàn)問(wèn)題。

第二個(gè)辦法是同步處理消息。同步操作在性能上會(huì)產(chǎn)生很大的問(wèn)題，特別是當(dāng)服務(wù)需要與外部服務(wù)、系統(tǒng)或資源交互的時(shí)候，因?yàn)榉?wù)在返回結(jié)果之前，整個(gè)流程都要等待第三方的回應(yīng)。更主要的是，實(shí)際上這并沒(méi)有真正解決問(wèn)題。如果服務(wù)在流程中出現(xiàn)故障了，我們無(wú)法確認(rèn)是哪里的故障。我們只知道消息傳輸出現(xiàn)了故障，而要確定故障環(huán)節(jié)，則需要服務(wù)消費(fèi)者的幫忙。

表面看來(lái)，如果服務(wù)能夠使用永久性地儲(chǔ)存介質(zhì)（比如到數(shù)據(jù)庫(kù)）就可以解決這個(gè)問(wèn)題。我覺(jué)得這個(gè)方向是不錯(cuò)；但是，這還不夠。因?yàn)槿绻?wù)在儲(chǔ)存狀態(tài)之前出現(xiàn)了故障，傳入的消息仍然會(huì)丟失，并且服務(wù)對(duì)此一無(wú)所知。還應(yīng)該注意到，如果使用永久性存儲(chǔ)介質(zhì)，我們雖然可以追蹤到在過(guò)程的哪一環(huán)節(jié)出現(xiàn)故障，但是我們無(wú)法確定消息是否已經(jīng)發(fā)送到了其它服務(wù)。

要解決這些問(wèn)題，以及整體的可靠性問(wèn)題，我們需要事務(wù)處理服務(wù)。

解決方案

使用事務(wù)處理服務(wù)模式，一次性處理從讀取消息到響應(yīng)的整個(gè)流程。

事務(wù)處理服務(wù)模式的主要組件是消息泵（message pump），見(jiàn)圖7。消息泵監(jiān)聽(tīng)著終端或邊界傳入的消息。如果接收到消息，消息泵就開(kāi)始一個(gè)事務(wù)操作，讀取消息，把消息發(fā)送到其它組件/類(lèi)進(jìn)行處理，處理后，結(jié)束事務(wù)操作（完成或失敗）。如果可以以事務(wù)處理的方式發(fā)送請(qǐng)求或回應(yīng)，就可以把這些操作放入到事務(wù)處理中，否則你就需要為操作失敗準(zhǔn)備補(bǔ)償邏輯。

使用事務(wù)處理編程模型的好處是它要么是純語(yǔ)義學(xué)的，要么完全不是，因此不存在邊界效應(yīng)。由于事務(wù)的四個(gè)屬性（ACID），所有的操作和消息都一定會(huì)被完全處理完、或完全沒(méi)有被處理，所以如果有消息離開(kāi)了服務(wù)，那么觸發(fā)這個(gè)行為的傳入消息肯定是被完全處理過(guò)了。 ACID事務(wù)

一個(gè)事務(wù)是一個(gè)完整的任務(wù)單位。一個(gè)任務(wù)單位如果滿(mǎn)足ACID所定義的四個(gè)屬性，那么它就是一個(gè)事務(wù)。

* 原子：事務(wù)中的所有事件都是以一個(gè)原子單位的形式發(fā)生的（atomic unit）。這些事件要么全部發(fā)生，要么全部不發(fā)生。

* 一致：不管事務(wù)完成與否，事務(wù)的資源必需在整個(gè)過(guò)程保持一致。 * 隔離：所有外部的觀察者（不參與事務(wù)處理）都不能看到內(nèi)部的狀態(tài)。只能在事務(wù)處理開(kāi)始前或完成后查看狀態(tài)。

* 持久：事務(wù)處理過(guò)程中做出的改動(dòng)儲(chǔ)存在永久性存儲(chǔ)介質(zhì)中，因此即使系統(tǒng)重啟后也不會(huì)丟失。

當(dāng)然，你要選擇事務(wù)服務(wù)模式的重要因素肯定還是性能。由于需要準(zhǔn)備、為了持久性而做的輸入輸出和鎖定管理等，事務(wù)通常會(huì)比較慢。我一般會(huì)預(yù)告確定目標(biāo)場(chǎng)景并進(jìn)行測(cè)試，以確保能夠得到一個(gè)足夠好的方案。

實(shí)現(xiàn)事務(wù)處理服務(wù)模式的一種方法是為所有服務(wù)間的消息使用事務(wù)消息傳輸。事務(wù)消息傳輸 （transactional message transport）使得模式的實(shí)現(xiàn)變得非常簡(jiǎn)單——只要按照前面提到的步驟來(lái)就可以了：開(kāi)始事務(wù)、讀取、處理、發(fā)送、完成。另外一種方法，也是更常見(jiàn)的一種方法，是在接收到消息后把消息放到事務(wù)處理資源中（比如隊(duì)列或數(shù)據(jù)庫(kù)），然后向服務(wù)消息者發(fā)送一條確認(rèn)消息。但是這種情況下最初的消息不包括在事務(wù)處理中，因此你要準(zhǔn)備應(yīng)付服務(wù)消費(fèi)者的多次消息發(fā)送。比如，服務(wù)消費(fèi)者沒(méi)有收到確認(rèn)消息，于是“又”發(fā)送了一條請(qǐng)求消息提取100萬(wàn)美元。

在圖8中，使用事務(wù)處理服務(wù)模式，步驟2.0到2.5（訂購(gòu)服務(wù)的行為）處于同一事務(wù)中。這意味著如果你因?yàn)楣收匣蚱渌馔鉀](méi)有處理下訂單的消息，那么服務(wù)就不會(huì)發(fā)出任何消息。這是個(gè)很讓人開(kāi)心的消息，因?yàn)槲覀儾挥迷賹?xiě)復(fù)雜的補(bǔ)償邏輯了。這里有一個(gè)小問(wèn)題，那就是如果訂購(gòu)服務(wù)在步驟1.0到1.2之間出現(xiàn)故障的話(huà)會(huì)有什么情況。該場(chǎng)景不是100%安全的；它有很小的幾率在我們把消息放到隊(duì)列等待處理的時(shí)候出現(xiàn)故障，從而沒(méi)有發(fā)送確認(rèn)消息。這可能導(dǎo)致重復(fù)接收到同樣的請(qǐng)求。一個(gè)在服務(wù)這邊處理重復(fù)消息的辦法是在服務(wù)啟動(dòng)時(shí)查看消息隊(duì)列并對(duì)所有消息發(fā)送確認(rèn)消息，這種情況下，服務(wù)消費(fèi)者可能會(huì)收到多于一條的確認(rèn)消息。

請(qǐng)注意，在這個(gè)示例中，只能在賬單處理過(guò)程僅僅產(chǎn)生一個(gè)發(fā)貨單的情況下使用單獨(dú)的事件。如果賬單服務(wù)還需要處理信用卡，并且訂購(gòu)服務(wù)需要得到確認(rèn)信息才能繼續(xù)的話(huà)，就不能使用單獨(dú)的事件了。當(dāng)不能使用單獨(dú)的事件的時(shí)候，需要把過(guò)程分成較小的事務(wù)，這時(shí)整個(gè)過(guò)程就被稱(chēng)為連續(xù)操作。需要把流程分為幾個(gè)較小的事務(wù)的另一個(gè)條件是看服務(wù)是否是分布式的。

必須注意把事務(wù)的范圍定到終端/邊界和外部的消息發(fā)送者是不一樣的。雖然從表面看來(lái)，這個(gè)區(qū)別不是很重要；但是實(shí)際上它確實(shí)很重要——因?yàn)榍罢呤窃鰪?qiáng)服務(wù)的可靠性而后者是提高系統(tǒng)的耦合性并會(huì)給你帶來(lái)讓人頭痛的問(wèn)題。如果你把事務(wù)擴(kuò)展到服務(wù)之外，那將是非常大的轉(zhuǎn)變，因?yàn)槠渌姆?wù)是運(yùn)行在自己的機(jī)器的，有它自己的服務(wù)等級(jí)協(xié)議等等。把內(nèi)部資源暴露到服務(wù)信任協(xié)議之外是很冒險(xiǎn)的做法。

模式四：工作流化模式

我曾經(jīng)為一家移動(dòng)公司做過(guò)一個(gè)項(xiàng)目，構(gòu)建一個(gè)售后服務(wù)系統(tǒng)。大家應(yīng)該都知道，移動(dòng)公司之間的競(jìng)爭(zhēng)是非常激烈的。競(jìng)爭(zhēng)的結(jié)果就是，這家公司的銷(xiāo)售部門(mén)經(jīng)常要夜以繼日地工作才能制定出新的使用方案或捆綁銷(xiāo)售計(jì)劃以提高銷(xiāo)售額：比如朋友、親情、PTT的公司業(yè)務(wù)、更低的國(guó)際電話(huà)費(fèi)用等方案，3.5G網(wǎng)絡(luò)的捆綁推廣等。對(duì)于這家公司來(lái)說(shuō)，每周都會(huì)有好幾種新式應(yīng)用方案產(chǎn)生。其記賬系統(tǒng)是基于Amdocs的，SAP系統(tǒng)應(yīng)付新方案也很輕松。然而，市場(chǎng)競(jìng)爭(zhēng)通常都是從銷(xiāo)售部門(mén)開(kāi)始的，而不管IT部門(mén)的就緒度如何，因此如何盡快地支持新的銷(xiāo)售流程就成了迫切的需求。

幾乎所有企業(yè)的業(yè)務(wù)需求都是不斷變化的——雖然可能不像前面所描述的那般迫切，但它畢竟是存在的。我們必須尋找一種方式讓我們的服務(wù)適應(yīng)這些不斷變化的過(guò)程。

問(wèn)題

如何提高服務(wù)對(duì)不斷變化的業(yè)務(wù)流程的適應(yīng)性？

最容易想到的方法是每次都等待變化的需求，然后根據(jù)需求變化開(kāi)發(fā)代碼，更新服務(wù)。這里有幾個(gè)問(wèn)題。首先，為了變更需求，你需要一個(gè)完整的開(kāi)發(fā)周期。其次，代碼變更意味著系統(tǒng)的很大一部分需要重啟——想一想一些諸如此類(lèi)的問(wèn)題吧：“我們昨天的計(jì)劃會(huì)不會(huì)受到這次更新的影響？”；“會(huì)對(duì)上個(gè)周期我們添加的那個(gè)類(lèi)似的東西產(chǎn)生什么影響？”等等?？梢哉f(shuō)越多的開(kāi)發(fā)和測(cè)試就等于越長(zhǎng)的上市時(shí)間。在我們的項(xiàng)目中，這意味著實(shí)施新的計(jì)劃需要幾個(gè)星期的時(shí)間，這會(huì)讓管理部門(mén)很不高興。這也意味著你的工作評(píng)定又降了一級(jí)，甚至更多。我們當(dāng)然不能這么做。

一個(gè)較好的辦法是將應(yīng)用中比較穩(wěn)定的部分從經(jīng)常改變的部分中分離出來(lái)。比如在我們的方案中，像顧客姓名、地址等人口統(tǒng)計(jì)資料應(yīng)該就是與銷(xiāo)售方案無(wú)關(guān)的穩(wěn)定因素。雖然如此，編排穩(wěn)定的邏輯仍然是一項(xiàng)繁瑣且容易出錯(cuò)的任務(wù)。或許，我們可以想個(gè)更好的辦法……

解決方案

在服務(wù)中引入一個(gè)工作流引擎來(lái)處理不穩(wěn)定的和經(jīng)常變化的過(guò)程、以及編排穩(wěn)定邏輯（stable logic）。

如圖所示，工作流化模式是在服務(wù)中添加一個(gè)工作流引擎來(lái)驅(qū)動(dòng)業(yè)務(wù)過(guò)程。工作流引擎中包含一個(gè)工作流實(shí)例（workflow instance）。最基本的形式是每個(gè)工作流負(fù)責(zé)一種請(qǐng)求類(lèi)型；然而，工作流可以更復(fù)雜，處理連續(xù)的過(guò)程并且有多個(gè)接收外部服務(wù)請(qǐng)求或數(shù)據(jù)的入口點(diǎn)。

使用工作流的優(yōu)勢(shì)是可以以活動(dòng)為構(gòu)建塊進(jìn)行思考，從而更靈活、更輕松地安排流程。以活動(dòng)流的方式建模過(guò)程意味著可以更容易地分辨并重用穩(wěn)定的部分，直到有變化需求為止。既然活動(dòng)可以進(jìn)行自我測(cè)試，重用一個(gè)活動(dòng)就代表你不用再進(jìn)行大量的測(cè)試。而靈活地重新安排活動(dòng)則代表你可以迅速地響應(yīng)業(yè)務(wù)需求。

這個(gè)能夠更容易地（通過(guò)工作流）改變服務(wù)行為的誘人方案有一個(gè)問(wèn)題：每次行為變更是否需要同時(shí)更新契約版本？回答當(dāng)然是要看情況。我的原則是，對(duì)于契約行為來(lái)說(shuō)，如果里氏代換原則成立，那么就不需要添加新的版本。

什么時(shí)候更新契約版本——里氏代換原則

里氏代換原則，或契約式設(shè)計(jì)，是一種面向?qū)ο蟮脑瓌t。Barbara Liskoy（里氏）是這樣說(shuō)的：“如果對(duì)于每一個(gè)類(lèi)型S的對(duì)象o1都有一個(gè)類(lèi)型T的對(duì)象o2，使得以T定義的所有程序P在所有o1都被替換為o2的時(shí)候程序P的行為沒(méi)有變化，那么S是T的一個(gè)子類(lèi)型?！焙?jiǎn)單地說(shuō)，這就是指子類(lèi)可以代替父類(lèi)使用而不會(huì)破壞任何使用基類(lèi)的行為。應(yīng)用到SOA上這意味著改變服務(wù)的內(nèi)部行為時(shí)，如果對(duì)于每個(gè)契約中定義的操作，前面的情況不變或較弱，而后面的情況（比如請(qǐng)求結(jié)果）不變或更強(qiáng)，那么你就不需要?jiǎng)?chuàng)建新的契約版本。換言之，為了保持相同的契約版本，新的服務(wù)版本應(yīng)該與客戶(hù)對(duì)舊的服務(wù)版本的期望行為保持一致。

下面我們把示例的場(chǎng)景工作流化，看看工作流是怎么發(fā)揮作用的。簡(jiǎn)單重復(fù)一下，該場(chǎng)景主要是關(guān)于如何更快地為移動(dòng)公司引入新的使用方案。在引入新的方案的時(shí)候，后臺(tái)系統(tǒng)通常還沒(méi)有就緒——一般需要幾天甚至幾個(gè)星期的時(shí)間進(jìn)行改動(dòng)、測(cè)試和部署。而使用工作流的一個(gè)優(yōu)勢(shì)就是可以在沒(méi)有后臺(tái)的人工干預(yù)的情況下為新方案提供請(qǐng)求路由支持。比如，我們可以先讓客戶(hù)關(guān)系管理（CRM）系統(tǒng)記錄某個(gè)客戶(hù)服務(wù)的變更，通知技術(shù)人員配置網(wǎng)絡(luò)等，然后等后臺(tái)系統(tǒng)就緒了，再更新路由把流程指向新系統(tǒng)。此外，正如前面提到的，在這個(gè)流程中有許多步驟是穩(wěn)定的，比如獲取客戶(hù)的人口統(tǒng)計(jì)數(shù)據(jù)（姓名、地址等）、為電話(huà)提供附加程序或附件等。這些步驟都是可以被幾乎全部銷(xiāo)售過(guò)程重用的活動(dòng)或步驟。在這個(gè)場(chǎng)景中添

加一個(gè)工作流可以極大地提高業(yè)務(wù)響應(yīng)能力并保持業(yè)務(wù)敏捷性。如果某個(gè)競(jìng)爭(zhēng)對(duì)手啟動(dòng)了一個(gè)很受歡迎的新方案，那么這家公司就可以在一天之內(nèi)回應(yīng)一個(gè)有競(jìng)爭(zhēng)力的方案。這是真正的有形商業(yè)資產(chǎn)。

工作流引擎的另一個(gè)優(yōu)勢(shì)是能夠處理持續(xù)的過(guò)程。它把涉及多信息交互的全部過(guò)程直觀地表示出來(lái)，使我們更容易對(duì)藍(lán)圖和過(guò)程有一個(gè)清楚的了解，因此可以從業(yè)務(wù)的角度來(lái)調(diào)試過(guò)程。 當(dāng)然，工作流化也可以與其它模式結(jié)合。比如，很容易通過(guò)作業(yè)調(diào)度（幾乎所有的工作流引擎都支持）實(shí)現(xiàn)主動(dòng)式服務(wù)模式。

流程編排（Orchestrated Choreography）是一種與工作流化密切相關(guān)的模式；這兩種模式都使用相同的底層技術(shù)：使用工作流引擎。不過(guò)，雖然底層技術(shù)一樣，但是不同的架構(gòu)考慮方式卻會(huì)導(dǎo)致選擇不一樣的模式。比如，兩者之間一個(gè)很明顯的不同就是工作流化局限于一個(gè)單獨(dú)的服務(wù)中，而流程編排則需要在服務(wù)間添加調(diào)整性工作流。

模式五：邊界組件

最后一個(gè)基本模式是邊界組件模式。稱(chēng)其它模式為基本模式是因?yàn)樗鼈冇泻艽蟮耐ㄓ眯?。但邊界組件模式不同，稱(chēng)它為基本模式是因?yàn)檫@是一個(gè)實(shí)現(xiàn)其它模式的平臺(tái)。由于邊界組件模式是實(shí)現(xiàn)其它模式的一個(gè)步驟，具體的示例都是適應(yīng)于在這個(gè)邊界組件上構(gòu)建的模式的，所以很難想象一個(gè)具體的示例來(lái)展示它的必要性。不過(guò)，我會(huì)嘗試通常幾個(gè)簡(jiǎn)單的例子和這些例子之間的共性來(lái)介紹邊界組件。

問(wèn)題

場(chǎng)景1 我們?cè)?jīng)為一家公司開(kāi)發(fā)了一個(gè)海軍C4I平臺(tái)（Military Naval C4I platform）。這個(gè)平臺(tái)有一些可以重用的服務(wù)。比如，核心服務(wù)之一提供了標(biāo)準(zhǔn)的中央目標(biāo)視圖。平臺(tái)上第一套工具使用了TIBCO Rendezvous消息設(shè)施。后來(lái)需要更換完全不同的技術(shù)（WSE 3.0 ）。這兩套工具都使用相同的業(yè)務(wù)邏輯，但是實(shí)現(xiàn)技術(shù)不同。

場(chǎng)景2 在另一個(gè)項(xiàng)目中（在工作流化模式中提到過(guò)），一家移動(dòng)公司經(jīng)常需要在一個(gè)處理訂單的服務(wù)中引入新的應(yīng)用和銷(xiāo)售方案，比如朋友和親情、晚間話(huà)費(fèi)等。由于詳細(xì)變動(dòng)都是XML相關(guān)，因此這個(gè)服務(wù)接口是非常穩(wěn)定的，但是業(yè)務(wù)邏輯卻要為適應(yīng)新方案而經(jīng)常變動(dòng)。 這是一個(gè)與場(chǎng)景1截然相反的場(chǎng)景；這里的接口與技術(shù)是不變的，而業(yè)務(wù)邏輯是變動(dòng)的。

場(chǎng)景3 最后一個(gè)場(chǎng)景是許多項(xiàng)目中常見(jiàn)的一種情況。通常系統(tǒng)里會(huì)有多個(gè)服務(wù)。雖然每個(gè)服務(wù)處理各自不同的業(yè)務(wù)，但所有這些服務(wù)都要執(zhí)行一些常見(jiàn)的任務(wù)，比如在處理請(qǐng)求之前要確認(rèn)請(qǐng)求是經(jīng)過(guò)驗(yàn)證的，保存審核條目等等。 在這個(gè)場(chǎng)景里，我們遇到了一個(gè)不是與單個(gè)服務(wù)直接相關(guān)但在各服務(wù)之間重復(fù)性卻是最高的功能——因?yàn)榧词挂粋€(gè)服務(wù)是處理訂單的，另一個(gè)服務(wù)是面向顧客的，其記錄請(qǐng)求的代碼都是基本一樣的。 這些場(chǎng)景的共性是每個(gè)服務(wù)都涉及多個(gè)問(wèn)題（業(yè)務(wù)邏輯、技術(shù)、記錄等）。正如我們所見(jiàn)到的，所有這些問(wèn)題都必須可以根據(jù)情況進(jìn)行變更而不依賴(lài)于其它的問(wèn)題——我們需要實(shí)現(xiàn)這種靈活性。因?yàn)槲覀兊膯?wèn)題是：

如何讓服務(wù)、技術(shù)和其它交叉問(wèn)題（比如安全、記錄等）等業(yè)務(wù)方面的問(wèn)題可以按自己的步調(diào)變更而不產(chǎn)生相互的依賴(lài)性？ 最簡(jiǎn)單的（或許過(guò)分簡(jiǎn)單了）辦法是不要做任何具體的變動(dòng)。比如，直接把一部分邏輯當(dāng)作Web服務(wù)。這對(duì)技術(shù)提供商的在線(xiàn)業(yè)務(wù)來(lái)說(shuō)是很常見(jiàn)的，比如Microsoft （WCF）和 Sun （JAX-WS）提供的教程。然而，由于契約操作與業(yè)務(wù)邏輯實(shí)現(xiàn)直接糾纏在了一起，這給代碼維護(hù)帶來(lái)了極大的不便——比如，如果要支持場(chǎng)景1，用這種方法來(lái)替換技術(shù)可能就會(huì)非常困難。 我們可以通過(guò)在復(fù)制服務(wù)上替換新技術(shù)來(lái)解決前面的在當(dāng)前服務(wù)中替換技術(shù)的問(wèn)題，這種方法也叫“自我克隆（own and clone）”。不過(guò)這也會(huì)產(chǎn)生維護(hù)上的問(wèn)題，因?yàn)槟悻F(xiàn)在有了同一業(yè)務(wù)邏輯的多個(gè)復(fù)本，因此你得改動(dòng)所有復(fù)本，并且這還解決不了場(chǎng)景3里要在多個(gè)服務(wù)上添加記錄功能的問(wèn)題。 如果什么也不做和克隆都行不通，那么我們可能要考慮分開(kāi)解決各個(gè)問(wèn)題。

解決方案

關(guān)注點(diǎn)分離（SoC）在面向?qū)ο蟮脑O(shè)計(jì)中是一個(gè)為人熟知的概念。其背后的基本原則是單一責(zé)任原則（The Single Responsibility Principle），或簡(jiǎn)稱(chēng)為SRP。SRP認(rèn)為要改變一個(gè)類(lèi)只能有唯一的原因，這個(gè)原因就是責(zé)任（responsibility）。我們可以在SOA中應(yīng)用同一原則，把業(yè)務(wù)邏輯看作是一個(gè)責(zé)任，把其它的問(wèn)題看作是另一個(gè)責(zé)任，這樣我們就得到以下模式： 附加邊界組件（Add Edge Component（s）），用以實(shí)現(xiàn)服務(wù)并提高靈活性、分離業(yè)務(wù)邏輯與其它問(wèn)題（比如契約、協(xié)議、終端技術(shù)和其它交叉問(wèn)題）。

正如圖所示，添加邊界組件的主要原因就是關(guān)注點(diǎn)分離。邊界組件可以處理所有這些交叉問(wèn)題以及其它非核心業(yè)務(wù)問(wèn)題。這些問(wèn)題包括負(fù)載平衡、格式轉(zhuǎn)換和審計(jì)。這樣，服務(wù)的業(yè)務(wù)邏輯就交給了另一個(gè)專(zhuān)門(mén)處理業(yè)務(wù)邏輯的組件。這種分離支持所有前面提到的場(chǎng)景，因?yàn)榉蛛x可以允許各個(gè)部件自由調(diào)整。比如，要支持一項(xiàng)新技術(shù)（場(chǎng)景1），只需要添加一個(gè)邊界組件，但是業(yè)務(wù)邏輯并不需要更換。如果要改變業(yè)務(wù)邏輯的行為，就添加一個(gè)新的使用方案（場(chǎng)景2），而邊界組件則不需要更換。

從某種意義來(lái)說(shuō)，邊界組件模式可以為SOA提供外觀（fa？ade）、代理、和AOP模式。 我們還要看一下如何解決場(chǎng)景3中服務(wù)間的交叉問(wèn)題。最好的辦法是進(jìn)一步擴(kuò)展單一責(zé)任原則，并且注意邊界組件實(shí)際上是一個(gè)組件，不能把它對(duì)應(yīng)于整個(gè)類(lèi)型的類(lèi)。比如，你可以應(yīng)用管道和過(guò)濾架構(gòu)類(lèi)型，把多個(gè)類(lèi)/組件連接到一起，各個(gè)類(lèi)/組件處理特定的問(wèn)題，以此來(lái)創(chuàng)建傳入或傳出的流程。比如，圖12即是一個(gè)邊界組件的示例。該示例中，邊界組件提供了一個(gè)驗(yàn)證過(guò)濾器來(lái)確保消息有正確的格式。然后是一個(gè)轉(zhuǎn)換過(guò)濾器把外部契約格式轉(zhuǎn)為內(nèi)部格式。最后是一個(gè)路由過(guò)濾器，負(fù)責(zé)把消息發(fā)送到服務(wù)的正確組件。這些組件可以在各個(gè)服務(wù)中根據(jù)需求重用，并且能夠自由地進(jìn)行更改。

雖然從一開(kāi)始就在邊界組件和服務(wù)之間定義一個(gè)內(nèi)部契約很有吸引力，但是實(shí)際上沒(méi)有理由這么做，除非你必須支持多個(gè)外部契約（雖然實(shí)現(xiàn)與消費(fèi)者一對(duì)一的契約非常麻煩——見(jiàn)PTP Integration反模式）。如果服務(wù)進(jìn)展并且創(chuàng)建了新的契約版本，像場(chǎng)景1中像添加新技術(shù)，那么在需要支持外部老版本的契約時(shí)你可能需要添加內(nèi)部契約。