一、SOA架構(gòu)

SOA： Service Oriented Architecture， 面向服務(wù)的架構(gòu)，或者說(shuō)，以服務(wù)為基礎(chǔ)搭建的企業(yè)IT架構(gòu)。SOA中服務(wù)（Service）的理念，本質(zhì)上是一種業(yè)務(wù)和技術(shù)完全分離，業(yè)務(wù)和技術(shù)又能自由組合的思想。 它達(dá)到了目前軟件設(shè)計(jì)思想的最高境界。

增強(qiáng)現(xiàn)實(shí)導(dǎo)航軟件運(yùn)用到了SOA框架，提供的SOAP接口可以滿足不同語(yǔ)言不同平臺(tái)的調(diào)用，采用HTTP協(xié)議，Http協(xié)議是跨平臺(tái)的協(xié)議，因此在安卓端和后臺(tái)交互上無(wú)疑是比較好的選擇。

SOA有3個(gè)基本的要素，只有這3個(gè)基本要素全部都滿足了，這個(gè)應(yīng)用才能稱為SOA的編程：（1）松散耦合；（2）粗粒度；（3）位置和傳輸協(xié)議透明。

（1）松散耦合是指相互之間的依賴程度，包括三個(gè)方面：1）服務(wù)之間的松散耦合： 不同服務(wù)的功能不要互相依賴， 相對(duì)獨(dú)立而完整，所謂自包含；這樣就比較好管理各個(gè)數(shù)據(jù)2）接口和實(shí)現(xiàn)之間的松散耦合： J2EE或.NET只需WSDL就可以調(diào)用WEB SERVICE的服務(wù)接口；3）業(yè)務(wù)組件和傳輸協(xié)議之間的松散耦合：傳輸協(xié)議和位置的透明。 （2）粗粒度的意義是SOA中服務(wù)的接口應(yīng)該比面向?qū)ο蟮木幊痰腁PI要大一些。以ATM取款機(jī)的取款功能來(lái)說(shuō)明這個(gè)問(wèn)題。取款功能的實(shí)現(xiàn)可能實(shí)際要包括下面的3個(gè)API：1）身份校驗(yàn)： 系統(tǒng)確認(rèn)用戶輸入的卡號(hào)和密碼是否正確；2）余額查詢：賬戶是否有足夠取款數(shù)額；3）取款： 以上兩項(xiàng)都滿足后，才真正付給用戶現(xiàn)金。

ATM取款機(jī)取款功能的3個(gè)API

作為SOA的業(yè)務(wù)接口，就不能將“身份校驗(yàn)”和“查詢余額”這兩個(gè)API公布給用戶，因?yàn)檫@樣太細(xì)了。如果讓用戶必須操作完兩個(gè)接口，最后再操作“取款”接口，則不符合用戶的操作習(xí)慣。所以系統(tǒng)只能給出符合用戶操作習(xí)慣的一個(gè)服務(wù)接口“取款”，它里面包含前面兩個(gè)API功能 。

（3）位置和傳輸協(xié)議透明是SOA最根本的區(qū)別于目前面向組件編程的地方。目前的服務(wù)組件如EJB、WEB SERVICE、JMS的發(fā)布都是和特定的應(yīng)用服務(wù)器綁定在一起的。如果某個(gè)服務(wù)組件的URL位置修改了，客戶端程序必須要做相應(yīng)的修改，否則整個(gè)集成不能工作了。這就是位置組件的不透明。

所謂位置的透明，就是指不論服務(wù)組件的實(shí)際位置URL如何變化，客戶端的調(diào)用程序的URL都不需要改變。所謂傳輸協(xié)議的透明，就是指不管服務(wù)組件的傳輸協(xié)議如何變化，客戶端的調(diào)用程序的傳輸協(xié)議都不需要改變。

二、SOA工作流程

SOA架構(gòu)中有三種角色：（1）服務(wù)提供者Provider：發(fā)布自己的服務(wù)，并且對(duì)服務(wù)請(qǐng)求進(jìn)行響應(yīng)。（2）服務(wù)注冊(cè)中心Agent：注冊(cè)已經(jīng)發(fā)布的web service，對(duì)其進(jìn)行分類，并提供搜索服務(wù)。（3）Consumer服務(wù)請(qǐng)求者：利用服務(wù)中心查找所需要的服務(wù)，然后使用該服務(wù)。

SOA的三種操作：（1）發(fā)布操作：為了使服務(wù)可訪問(wèn)，需要發(fā)布服務(wù)描述以使服務(wù)使用者可以發(fā)現(xiàn)它。（2）查找操作：服務(wù)請(qǐng)求者定位服務(wù)，方法是查詢服務(wù)注冊(cè)中心來(lái)找到滿足其標(biāo)準(zhǔn)的服務(wù)。（3）綁定操作：在檢索到服務(wù)描述之后，服務(wù)使用者繼續(xù)根據(jù)服務(wù)描述中信息來(lái)調(diào)用服務(wù)。

SOA實(shí)例：在石油企業(yè)內(nèi)部，有許多不同的網(wǎng)站，進(jìn)入每個(gè)網(wǎng)站，都需要身份驗(yàn)證，不僅浪費(fèi)時(shí)間而且容易遺忘代碼 ，另外，網(wǎng)站維護(hù)人員對(duì)各種服務(wù)需要建立相應(yīng)的用戶認(rèn)證與信息管理系統(tǒng)，分布于個(gè)服務(wù)器中的用戶數(shù)據(jù)不僅浪費(fèi)維護(hù)人員的時(shí)間，而且過(guò)于分散的用戶數(shù)據(jù)不利于統(tǒng)計(jì)和管理。用戶的需求和管理要求促使用戶趨于統(tǒng)一，產(chǎn)生了統(tǒng)一者認(rèn)證。統(tǒng)一認(rèn)證的實(shí)現(xiàn)是基于SOA的架構(gòu)。

從中可以看出使用SOA的優(yōu)點(diǎn)：將身份驗(yàn)證這一功能模塊發(fā)布成一種服務(wù)，其他的軟件可以通過(guò)UUDI查找該服務(wù)，然后將該服務(wù)與服務(wù)的實(shí)現(xiàn)進(jìn)行綁定。

三、SOA的架構(gòu)層次

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

如果把SOA的架構(gòu)簡(jiǎn)單的理解為是多個(gè)子系統(tǒng)之間的整合其實(shí)有點(diǎn)太過(guò)于簡(jiǎn)單，也沒(méi)有真正搞清楚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ù)的分層，通過(guò)分層將服務(wù)按照使用類型進(jìn)行分配，上層服務(wù)對(duì)下層服務(wù)的包裝，下層服務(wù)負(fù)責(zé)原子性的操作，上層服務(wù)對(duì)下層服務(wù)進(jìn)行業(yè)務(wù)性的組合。

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

1、應(yīng)用服務(wù)（原子服務(wù)）

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

應(yīng)用服務(wù)位于UI與后臺(tái)之間，后臺(tái)我們可以認(rèn)為它是一異構(gòu)的系統(tǒng)或者是數(shù)據(jù)庫(kù)之類的。應(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)槟銢](méi)有對(duì)系統(tǒng)的服務(wù)進(jìn)行層次的劃分，你的業(yè)務(wù)功能會(huì)直接的落到某一個(gè)應(yīng)用線上的服務(wù)，繼續(xù)往下看。

2、組合服務(wù)

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

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

3、業(yè)務(wù)服務(wù)（編排服務(wù)）

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

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

四、SOA化的重構(gòu)

進(jìn)行SOA化的實(shí)施，大部分情況下都是對(duì)現(xiàn)有系統(tǒng)進(jìn)行重構(gòu)后考慮的，初期企業(yè)發(fā)展階段以快速出原形為首要目標(biāo)，只有當(dāng)系統(tǒng)出現(xiàn)瓶頸了才會(huì)考慮運(yùn)用SOA來(lái)解決。但是在這個(gè)時(shí)候有很多歷史包袱無(wú)法解決，進(jìn)行SOA化的重構(gòu)其實(shí)成本是很高的，而且很危險(xiǎn)，對(duì)有些復(fù)雜的邏輯說(shuō)的現(xiàn)實(shí)點(diǎn)，是無(wú)能為力的。如果都可以通過(guò)重構(gòu)這個(gè)技術(shù)來(lái)解決，那我們就太天真了?！吨貥?gòu)—馬丁。福勒》一書(shū)講的是代碼層面的重構(gòu)，跟做系統(tǒng)級(jí)重構(gòu)兩個(gè)概念。對(duì)系統(tǒng)級(jí)別的重構(gòu)還沒(méi)有太多成熟的方法論支撐。尤其現(xiàn)在新技術(shù)層出不窮的，各有優(yōu)點(diǎn)，能很好的運(yùn)用這些技術(shù)、方法論、過(guò)程來(lái)重構(gòu)大型企業(yè)級(jí)系統(tǒng)，難度非常大，這需要整個(gè)公司投入很多人力、資源成本。回過(guò)頭來(lái)想想，其實(shí)在前期適當(dāng)考慮一下還是有必要的，這樣可以減少后期很多技術(shù)債務(wù)。

這里我只總結(jié)我在分析、設(shè)計(jì)公司某一塊業(yè)務(wù)系統(tǒng)的時(shí)候?qū)ζ溥M(jìn)行SOA化的重構(gòu)思路。重構(gòu)本來(lái)就是一個(gè)不斷迭代的過(guò)程，不可以跨大步。通過(guò)很多腳手架支撐，讓系統(tǒng)慢慢的過(guò)度到新的SOA架構(gòu)下，既然要實(shí)施SOA架構(gòu)，那么很重要的一點(diǎn)就是對(duì)遷移的業(yè)務(wù)邏輯適當(dāng)?shù)臍w類，什么業(yè)務(wù)邏輯該放入“業(yè)務(wù)服務(wù)”中，什么邏輯該在代碼層面上放入“組合服務(wù)”中，對(duì)基本的操作有如何放入代碼層面的“應(yīng)用服務(wù)”中。

1、保留服務(wù)空間，為了將來(lái)服務(wù)的組合

在進(jìn)行系統(tǒng)拆分的時(shí)候，對(duì)當(dāng)前后端的調(diào)用都進(jìn)行適當(dāng)?shù)囊?guī)劃，將其分為兩類，一類是應(yīng)用服務(wù)，一類是組合服務(wù)，這兩個(gè)服務(wù)是可以在代碼層面上進(jìn)行抽象。重點(diǎn)是那些調(diào)用其他系統(tǒng)的地方，需要將其放入業(yè)務(wù)服務(wù)中，這塊邏輯比較復(fù)雜，難以抽取，需要適當(dāng)?shù)慕Y(jié)合”數(shù)據(jù)落地“的思路來(lái)綜合考慮。有時(shí)候把一部分?jǐn)?shù)據(jù)落入本地可以提升系統(tǒng)的整體簡(jiǎn)潔度和穩(wěn)定性，但是要考慮數(shù)據(jù)的一個(gè)生命周期性質(zhì)。

在遷移的過(guò)程中可能還會(huì)有一些新的功能并行開(kāi)發(fā)的，既有新的邏輯需要放入新的SOA服務(wù)中，也會(huì)有遷移過(guò)來(lái)的邏輯，這兩個(gè)過(guò)程同時(shí)進(jìn)行其實(shí)很痛苦，盡量避免這樣同時(shí)進(jìn)行，但是現(xiàn)實(shí)是根本不可能，正常都是一起并行推進(jìn)。如果這兩個(gè)過(guò)程是同一組團(tuán)隊(duì)負(fù)責(zé)其實(shí)還好，畢竟對(duì)這塊的代碼、業(yè)務(wù)都比較了解。

這一節(jié)目的是想強(qiáng)調(diào)對(duì)現(xiàn)在系統(tǒng)進(jìn)行遷移的時(shí)候要考慮服務(wù)的層次，不要只進(jìn)行一個(gè)簡(jiǎn)單的搬移代碼，這個(gè)時(shí)候是一個(gè)對(duì)代碼進(jìn)行重構(gòu)的好機(jī)會(huì)，該劃分層次的要?jiǎng)澐謱哟危撟x寫分離的要讀寫分離，要重點(diǎn)考慮那些“業(yè)務(wù)服務(wù)”，需要跨越多個(gè)應(yīng)用線的邏輯。

順便說(shuō)一下，還有一個(gè)重點(diǎn)就是遷移的時(shí)候還要考慮數(shù)據(jù)存儲(chǔ)方面的遷移，光代碼層面的遷移只是第一步，第二步還需要進(jìn)行數(shù)據(jù)層面的遷移。當(dāng)然這兩個(gè)大的步驟都是要通過(guò)很多次迭代完成，并且還是一個(gè)對(duì)業(yè)務(wù)、代碼進(jìn)行很好梳理和整理的好機(jī)會(huì)。

在將系統(tǒng)進(jìn)行服務(wù)化的時(shí)候要考慮服務(wù)層，如果當(dāng)前沒(méi)有業(yè)務(wù)服務(wù)的邏輯那么就保留服務(wù)空間，至少要清楚在服務(wù)層中有這么一個(gè)空間是要預(yù)留的，當(dāng)有其他的應(yīng)用線需要與你交互的時(shí)候可以順利的進(jìn)入到你的服務(wù)區(qū)，而不是直接到達(dá)你的應(yīng)用。

五、運(yùn)用DDD+GRASP進(jìn)行分析和設(shè)計(jì)（防止主觀的判斷導(dǎo)致錯(cuò)誤的假設(shè)）

做系統(tǒng)設(shè)計(jì)時(shí)最怕的就是職責(zé)搞錯(cuò)了，這會(huì)使系統(tǒng)的架構(gòu)突然就復(fù)雜了，而且系統(tǒng)架構(gòu)都是很難改變的或者壓根就無(wú)法改變的決定。所以我對(duì)這塊引起了重視，有時(shí)候你對(duì)業(yè)務(wù)在了解在熟悉依然會(huì)搞錯(cuò)職責(zé)，對(duì)于這塊光憑主觀的判斷是不長(zhǎng)遠(yuǎn)的，無(wú)發(fā)復(fù)制、無(wú)法傳播的，也無(wú)法落字成文的。

對(duì)DDD我這里就不多做介紹了，這里要強(qiáng)調(diào)是GRASP。運(yùn)用DDD可以很好的幫助我們來(lái)戰(zhàn)略性的觀察企業(yè)所坐立的領(lǐng)域，我還是很提倡DDD在公司實(shí)施的，不說(shuō)DDD中的“戰(zhàn)術(shù)設(shè)計(jì)”方法論，就光說(shuō)它的“戰(zhàn)略設(shè)計(jì)”方法論還是有很大作用的，讓我們可以在腦海中建立一個(gè)戰(zhàn)略性的模型。具體要不要進(jìn)行代碼層面的落地這就看實(shí)際情況了。而且DDD中的很多不錯(cuò)的思想都可以借鑒過(guò)來(lái)，包括領(lǐng)域通用語(yǔ)言，有了領(lǐng)域通用語(yǔ)言團(tuán)隊(duì)之間的溝通和交流會(huì)節(jié)省很多成本。對(duì)于新人來(lái)說(shuō)，可以很快的了解公司的一些大概的業(yè)務(wù)，這和“詞匯表”其實(shí)還是有區(qū)別的。

上面說(shuō)了，在劃分職責(zé)的時(shí)候很多都是通過(guò)經(jīng)驗(yàn)來(lái)主觀的判斷，沒(méi)有其他的客觀證據(jù)了。那么有沒(méi)有一個(gè)不錯(cuò)的方法論或模式來(lái)指導(dǎo)我們進(jìn)行這類問(wèn)題的解決呢，其實(shí)還是有的，因?yàn)樵趪?guó)外人家這方面已經(jīng)很成熟。

GRASP就是這樣的一套模式，它可以幫助我們進(jìn)行客觀的設(shè)計(jì)職責(zé)。到底該把這塊數(shù)據(jù)放入哪個(gè)應(yīng)用中，到底該把這個(gè)邏輯放入哪個(gè)服務(wù)中，都有指導(dǎo)，包括對(duì)對(duì)象層面的設(shè)計(jì)依然可以。我們可能對(duì)“信息專家模式”都有了解，但是以往我們可能都只把它用在對(duì)象設(shè)計(jì)上，而沒(méi)有提升一個(gè)系統(tǒng)層面中考慮。那是因?yàn)槲覀円酝赡軟](méi)有碰見(jiàn)很復(fù)雜的職責(zé)分配場(chǎng)景，只有當(dāng)出現(xiàn)問(wèn)題時(shí)我們才能真正領(lǐng)會(huì)某個(gè)東西的好壞。

DDD只有結(jié)合GRASP才能客觀準(zhǔn)確的方配某個(gè)領(lǐng)域的職責(zé)，不管是戰(zhàn)略設(shè)計(jì)層面還是戰(zhàn)術(shù)設(shè)計(jì)層面，都是一個(gè)很好的平衡標(biāo)準(zhǔn)，不會(huì)由于技術(shù)人員主觀的興趣傾向?qū)е乱粋€(gè)錯(cuò)誤的職責(zé)分配決定，而這個(gè)錯(cuò)誤的決定最終是要開(kāi)發(fā)人員來(lái)買單。

六、SOA分布式下的數(shù)據(jù)一致性

傳統(tǒng)分布式系統(tǒng)與當(dāng)代的面向SOA的分布式系統(tǒng)有一定區(qū)別，論概念上來(lái)講SOA是以服務(wù)為中心，既然以服務(wù)為中心就會(huì)有很多面向服務(wù)的設(shè)計(jì)原則。而傳統(tǒng)的分布式系統(tǒng)沒(méi)有服務(wù)的概念，也沒(méi)有所謂的一切皆是服務(wù)的原則。而當(dāng)代SOA則首要原則就要以服務(wù)為中心，針對(duì)服務(wù)的設(shè)計(jì)又有了很多服務(wù)設(shè)計(jì)原則。

SOA對(duì)服務(wù)還進(jìn)行了類型的劃分，按照服務(wù)的應(yīng)用層次來(lái)分類：業(yè)務(wù)服務(wù)、組合服務(wù)、應(yīng)用服務(wù)，包裝服務(wù)等。再按照管理與運(yùn)維的層面來(lái)分類：控制服務(wù)、調(diào)度服務(wù)、監(jiān)控服務(wù)等等。傳統(tǒng)的分布式系統(tǒng)是沒(méi)有這些的，我們談?wù)摰氖钱?dāng)代SOA的分布式系統(tǒng)，所以我們強(qiáng)調(diào)的是以服務(wù)為中心，以服務(wù)設(shè)計(jì)原則為架構(gòu)設(shè)計(jì)的指導(dǎo)要求，當(dāng)代SOA是對(duì)傳統(tǒng)分布式系統(tǒng)的一個(gè)迭代進(jìn)化，不是一個(gè)時(shí)代的產(chǎn)物，SOA更加強(qiáng)調(diào)了以服務(wù)為首要原則，已經(jīng)提升到了另外一個(gè)更加高級(jí)的層面。

本節(jié)我們交流一下在當(dāng)代SOA分布式系統(tǒng)中的數(shù)據(jù)一致性問(wèn)題，在SOA中這主要涉及兩個(gè)層面來(lái)考慮，一個(gè)是服務(wù)層面、一個(gè)數(shù)據(jù)持久化層面。再按照一致性的基本要求，可以分為：讀一致性、寫一致性、會(huì)話一致性、最終一致性、實(shí)時(shí)一致性等幾個(gè)維度，當(dāng)然還有其他幾個(gè)維度的一致性要求。

我們這里重點(diǎn)討論在企業(yè)應(yīng)用中實(shí)施SOA時(shí)遇到的一些比較棘手的數(shù)據(jù)一致性問(wèn)題和解決方案，對(duì)于剛才提到的幾個(gè)維度的一致性要求均具有重要的參考價(jià)值。

1、分布式事務(wù)（基于DTC的分布式事務(wù)）

以往包括目前很多項(xiàng)目還是傾向于使用DTC來(lái)處理分布式事務(wù)，這個(gè)方案多數(shù)適用于一般的企業(yè)應(yīng)用，業(yè)務(wù)、訪問(wèn)量、數(shù)據(jù)量要求都不是很高的情況下。用DTC很方便，事務(wù)的自動(dòng)傳播、事務(wù)的自動(dòng)感知、事務(wù)的自動(dòng)回滾和提交，這都是中央DTC幫我們管理好了。

由于有中央DTC的統(tǒng)一協(xié)調(diào)，看似好像幫我們解決了很多我們需要考慮的問(wèn)題，但是它也是整個(gè)平臺(tái)的致命的瓶頸，一旦DTC由于某個(gè)問(wèn)題出現(xiàn)錯(cuò)誤，而且這種錯(cuò)誤都是系統(tǒng)層面的錯(cuò)誤，很多問(wèn)題我們是無(wú)能為力的。如果出現(xiàn)問(wèn)題，整個(gè)應(yīng)用平臺(tái)都無(wú)法完成任何一個(gè)跨服務(wù)的業(yè)務(wù)流程，這其實(shí)很危險(xiǎn)，你不無(wú)法控制系統(tǒng)的穩(wěn)定性。

這里總結(jié)，DTC用于一般的小型企業(yè)應(yīng)用，不建議用在中等規(guī)模的企業(yè)應(yīng)用中，不是說(shuō)這個(gè)東西不好，而是無(wú)法控制它。

2、事務(wù)補(bǔ)償（提供正向或反向的操作來(lái)讓數(shù)據(jù)在業(yè)務(wù)上是一致的）

世界級(jí)SOA專家所編寫的書(shū)籍里都提到了使用“補(bǔ)償”操作來(lái)完成數(shù)據(jù)的不一致性，當(dāng)我們編寫了一個(gè)服務(wù)方法A，就需要一個(gè)服務(wù)方法A1的補(bǔ)償接口來(lái)完成A服務(wù)的補(bǔ)償操作。但是真實(shí)的業(yè)務(wù)情況下很難實(shí)施這種看起來(lái)好像很優(yōu)美很柔性的設(shè)計(jì)。沒(méi)有實(shí)踐就沒(méi)有發(fā)言權(quán)，我們公司的技術(shù)團(tuán)隊(duì)就實(shí)施過(guò)這種方案，但是很不理想，這跟技術(shù)本身及技術(shù)團(tuán)隊(duì)沒(méi)關(guān)系，只是我們的平臺(tái)業(yè)務(wù)太復(fù)雜，很難去“補(bǔ)償”一個(gè)已經(jīng)做過(guò)的操作。

這當(dāng)然也要看你所面對(duì)的項(xiàng)目情況，量變引起質(zhì)變，如果你的各種量都上去了，這個(gè)“補(bǔ)償”方案不實(shí)際，而且很難在數(shù)據(jù)層面進(jìn)行“補(bǔ)償“。總之，這不是一個(gè)中長(zhǎng)期的方案。

3、異步EDA（基于異步事件流來(lái)實(shí)現(xiàn)柔性的分布式事務(wù)）

EDA簡(jiǎn)稱”事件驅(qū)動(dòng)架構(gòu)“。多個(gè)系統(tǒng)之間通過(guò)傳播”事件“來(lái)驅(qū)動(dòng)整個(gè)業(yè)務(wù)的運(yùn)轉(zhuǎn)。系統(tǒng)之間沒(méi)有緊耦合的同步調(diào)用的操作，都是通過(guò)發(fā)出異步的“事件”來(lái)通知下一個(gè)業(yè)務(wù)環(huán)節(jié)。

可能你會(huì)有一個(gè)疑問(wèn)，異步操作，是不是系統(tǒng)之間延遲會(huì)很長(zhǎng)，其實(shí)不是，現(xiàn)在有很多成熟的消息中間件在內(nèi)網(wǎng)內(nèi)幾乎是毫秒級(jí)別的延遲，至于跨機(jī)房就看物理上的距離了。

異步操作有很多好處，這里我就不浪費(fèi)大家時(shí)間重復(fù)那些好處。使用EDA實(shí)現(xiàn)系統(tǒng)之間的一個(gè)松散的事務(wù)關(guān)系，要把控好項(xiàng)目的質(zhì)量，對(duì)系統(tǒng)的非功能需求、BUG數(shù)等等可能會(huì)影響業(yè)務(wù)操作中斷的地方都要建立起適當(dāng)?shù)臋C(jī)制，讓這些問(wèn)題盡早的在線下解決。比如可以實(shí)施UnitTest、持續(xù)集成等一些敏捷的方法論。

總結(jié)

同樣一個(gè)工具在于什么人用，真正的工匠都是使用很樸實(shí)的工具來(lái)雕刻無(wú)法超越的藝術(shù)品，這就是工匠情懷。最近對(duì)工匠情懷感受越來(lái)越深，一直以為自己是一個(gè)比較喜歡專的人，這是不是偏離了一個(gè)大的方向沖進(jìn)了一個(gè)小胡同，直到最近我才領(lǐng)悟，這其實(shí)是”軟件工匠“的精神。但是這不代表不考慮全局，這只是一種情懷，一種態(tài)度，對(duì)于架構(gòu)也是，對(duì)于代碼也是，不要認(rèn)為那些看似無(wú)關(guān)緊要的問(wèn)題就忽視它，帶著工匠精神雕刻它。