一、SOA架構

SOA： Service Oriented Architecture， 面向服務的架構，或者說，以服務為基礎搭建的企業IT架構。SOA中服務（Service）的理念，本質上是一種業務和技術完全分離，業務和技術又能自由組合的思想。 它達到了目前軟件設計思想的最高境界。

增強現實導航軟件運用到了SOA框架，提供的SOAP接口可以滿足不同語言不同平臺的調用，采用HTTP協議，Http協議是跨平臺的協議，因此在安卓端和后臺交互上無疑是比較好的選擇。

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

（1）松散耦合是指相互之間的依賴程度，包括三個方面：1）服務之間的松散耦合： 不同服務的功能不要互相依賴， 相對獨立而完整，所謂自包含；這樣就比較好管理各個數據2）接口和實現之間的松散耦合： J2EE或.NET只需WSDL就可以調用WEB SERVICE的服務接口；3）業務組件和傳輸協議之間的松散耦合：傳輸協議和位置的透明。 （2）粗粒度的意義是SOA中服務的接口應該比面向對象的編程的API要大一些。以ATM取款機的取款功能來說明這個問題。取款功能的實現可能實際要包括下面的3個API：1）身份校驗： 系統確認用戶輸入的卡號和密碼是否正確；2）余額查詢：賬戶是否有足夠取款數額；3）取款： 以上兩項都滿足后，才真正付給用戶現金。

ATM取款機取款功能的3個API

作為SOA的業務接口，就不能將“身份校驗”和“查詢余額”這兩個API公布給用戶，因為這樣太細了。如果讓用戶必須操作完兩個接口，最后再操作“取款”接口，則不符合用戶的操作習慣。所以系統只能給出符合用戶操作習慣的一個服務接口“取款”，它里面包含前面兩個API功能 。

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

所謂位置的透明，就是指不論服務組件的實際位置URL如何變化，客戶端的調用程序的URL都不需要改變。所謂傳輸協議的透明，就是指不管服務組件的傳輸協議如何變化，客戶端的調用程序的傳輸協議都不需要改變。

二、SOA工作流程

SOA架構中有三種角色：（1）服務提供者Provider：發布自己的服務，并且對服務請求進行響應。（2）服務注冊中心Agent：注冊已經發布的web service，對其進行分類，并提供搜索服務。（3）Consumer服務請求者：利用服務中心查找所需要的服務，然后使用該服務。

SOA的三種操作：（1）發布操作：為了使服務可訪問，需要發布服務描述以使服務使用者可以發現它。（2）查找操作：服務請求者定位服務，方法是查詢服務注冊中心來找到滿足其標準的服務。（3）綁定操作：在檢索到服務描述之后，服務使用者繼續根據服務描述中信息來調用服務。

SOA實例：在石油企業內部，有許多不同的網站，進入每個網站，都需要身份驗證，不僅浪費時間而且容易遺忘代碼 ，另外，網站維護人員對各種服務需要建立相應的用戶認證與信息管理系統，分布于個服務器中的用戶數據不僅浪費維護人員的時間，而且過于分散的用戶數據不利于統計和管理。用戶的需求和管理要求促使用戶趨于統一，產生了統一者認證。統一認證的實現是基于SOA的架構。

從中可以看出使用SOA的優點：將身份驗證這一功能模塊發布成一種服務，其他的軟件可以通過UUDI查找該服務，然后將該服務與服務的實現進行綁定。

三、SOA的架構層次

進行SOA類型的架構設計就需要搞清楚SOA架構模型才行。并不能想當然的對系統進行簡單的拆分就行，需要搞清楚SOA的架構模型是怎樣的，每一塊是干什么用的，這樣設計由分析階段輸出的需求時才能正確的劃分職責。

如果把SOA的架構簡單的理解為是多個子系統之間的整合其實有點太過于簡單，也沒有真正搞清楚SOA的架構模型。按照SOA的正確方法論及目標模型，其實SOA在實現架構落地上，需要考慮到對服務的組合，不斷的重用現有的服務，讓企業應用可以逐步集成，快速實現業務的迭代。其實這就是本節要講的服務的分層，通過分層將服務按照使用類型進行分配，上層服務對下層服務的包裝，下層服務負責原子性的操作，上層服務對下層服務進行業務性的組合。

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

1、應用服務（原子服務）

應用服務就是諸如：訂單服務、倉庫服務、銷售服務、客戶管理服務，這些服務直接對應不同的應用系統，直接服務這些應用系統的原子操作。訂單服務直接原子性的插入訂單，沒有任何跨其他服務的分支邏輯。倉庫服務只管自己的倉庫邏輯。同樣其他的應用服務只管好自己的職責，杜絕對其他服務的調用。

應用服務位于UI與后臺之間，后臺我們可以認為它是一異構的系統或者是數據庫之類的。應用服務的位置位于前端與后端之間，起到類似一個服務API的作用，但是SOA中的服務還遠遠不止這一個應用服務，如果我們的SOA架構中只有一種類型的服務，那么這會增加我們系統的耦合程度，因為你沒有對系統的服務進行層次的劃分，你的業務功能會直接的落到某一個應用線上的服務，繼續往下看。

2、組合服務

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

組合服務對下層的應用服務進行了組合，完成了一個基本的業務動作，應用服務中是最基本的基礎性的原子性的操作。但是在復雜的業務需求下大部分業務功能都需要跨越多個應用線來完成一個最外層的企業動作。提交訂單可能需要穿過很多應用線，訂單管理、倉庫、財務等等環節。所以這里我們還需要一個能在最外層對組合服務進行編排的業務服務。這個編排服務可以完全是自動化的，通過工作流引擎進行組合自動化來完成，這對企業應用的自動化流程很有意義。

3、業務服務（編排服務）

業務服務是最外層的服務，向下編排了組合服務。業務服務位于最上層，當需要有跨越多個應用線來完成的業務，這個業務就放入業務服務中。比如提交訂單，先檢查庫存、扣減庫存（凍結庫存），然后下單，再往后通知財務，再往后通知物流等等都是一個復雜的企業服務線。這種最外層的業務邏輯如果你不進行SOA分層然后將其放入最外層的業務服務中，你把它放入任何一個應用線都會使系統調用混亂不堪。所以問題就是需要進行縱向的劃分層次。如果進行了SOA的層次劃分后就不會出現互相亂用的情況。其實這里可以參考阿里的服務設計方法。（李智慧寫的一本大型互聯網架構與實踐里面也講到了服務要劃分層次）

當在業務服務中執行的業務邏輯時，需要跨越多個應用線來完成。這部分的邏輯也說是職責，如果不放入這個位置，放在哪個應用線都不合適，放入哪個應用線都會使系統調用出現混亂。其實這里的問題就是我們不能用一個維度來進行SOA系統的設計，本來服務就具有組合特性，所以適當的提升服務的層次是有好處的，但是應用服務和組合服務可以在代碼層面上進行構建，而業務服務也叫編排服務是需要進行物理隔離的，畢竟考慮到系統復雜度和穩定性問題這是值得的。在排查問題，系統性能、穩定性等等方面，物理的隔離有一定的作用，畢竟業務服務本來就是來組合多個應用線的，這樣做會使整個系統架構很清晰。

四、SOA化的重構

進行SOA化的實施，大部分情況下都是對現有系統進行重構后考慮的，初期企業發展階段以快速出原形為首要目標，只有當系統出現瓶頸了才會考慮運用SOA來解決。但是在這個時候有很多歷史包袱無法解決，進行SOA化的重構其實成本是很高的，而且很危險，對有些復雜的邏輯說的現實點，是無能為力的。如果都可以通過重構這個技術來解決，那我們就太天真了。《重構—馬丁。福勒》一書講的是代碼層面的重構，跟做系統級重構兩個概念。對系統級別的重構還沒有太多成熟的方法論支撐。尤其現在新技術層出不窮的，各有優點，能很好的運用這些技術、方法論、過程來重構大型企業級系統，難度非常大，這需要整個公司投入很多人力、資源成本。回過頭來想想，其實在前期適當考慮一下還是有必要的，這樣可以減少后期很多技術債務。

這里我只總結我在分析、設計公司某一塊業務系統的時候對其進行SOA化的重構思路。重構本來就是一個不斷迭代的過程，不可以跨大步。通過很多腳手架支撐，讓系統慢慢的過度到新的SOA架構下，既然要實施SOA架構，那么很重要的一點就是對遷移的業務邏輯適當的歸類，什么業務邏輯該放入“業務服務”中，什么邏輯該在代碼層面上放入“組合服務”中，對基本的操作有如何放入代碼層面的“應用服務”中。

1、保留服務空間，為了將來服務的組合

在進行系統拆分的時候，對當前后端的調用都進行適當的規劃，將其分為兩類，一類是應用服務，一類是組合服務，這兩個服務是可以在代碼層面上進行抽象。重點是那些調用其他系統的地方，需要將其放入業務服務中，這塊邏輯比較復雜，難以抽取，需要適當的結合”數據落地“的思路來綜合考慮。有時候把一部分數據落入本地可以提升系統的整體簡潔度和穩定性，但是要考慮數據的一個生命周期性質。

在遷移的過程中可能還會有一些新的功能并行開發的，既有新的邏輯需要放入新的SOA服務中，也會有遷移過來的邏輯，這兩個過程同時進行其實很痛苦，盡量避免這樣同時進行，但是現實是根本不可能，正常都是一起并行推進。如果這兩個過程是同一組團隊負責其實還好，畢竟對這塊的代碼、業務都比較了解。

這一節目的是想強調對現在系統進行遷移的時候要考慮服務的層次，不要只進行一個簡單的搬移代碼，這個時候是一個對代碼進行重構的好機會，該劃分層次的要劃分層次，該讀寫分離的要讀寫分離，要重點考慮那些“業務服務”，需要跨越多個應用線的邏輯。

順便說一下，還有一個重點就是遷移的時候還要考慮數據存儲方面的遷移，光代碼層面的遷移只是第一步，第二步還需要進行數據層面的遷移。當然這兩個大的步驟都是要通過很多次迭代完成，并且還是一個對業務、代碼進行很好梳理和整理的好機會。

在將系統進行服務化的時候要考慮服務層，如果當前沒有業務服務的邏輯那么就保留服務空間，至少要清楚在服務層中有這么一個空間是要預留的，當有其他的應用線需要與你交互的時候可以順利的進入到你的服務區，而不是直接到達你的應用。

五、運用DDD+GRASP進行分析和設計（防止主觀的判斷導致錯誤的假設）

做系統設計時最怕的就是職責搞錯了，這會使系統的架構突然就復雜了，而且系統架構都是很難改變的或者壓根就無法改變的決定。所以我對這塊引起了重視，有時候你對業務在了解在熟悉依然會搞錯職責，對于這塊光憑主觀的判斷是不長遠的，無發復制、無法傳播的，也無法落字成文的。

對DDD我這里就不多做介紹了，這里要強調是GRASP。運用DDD可以很好的幫助我們來戰略性的觀察企業所坐立的領域，我還是很提倡DDD在公司實施的，不說DDD中的“戰術設計”方法論，就光說它的“戰略設計”方法論還是有很大作用的，讓我們可以在腦海中建立一個戰略性的模型。具體要不要進行代碼層面的落地這就看實際情況了。而且DDD中的很多不錯的思想都可以借鑒過來，包括領域通用語言，有了領域通用語言團隊之間的溝通和交流會節省很多成本。對于新人來說，可以很快的了解公司的一些大概的業務，這和“詞匯表”其實還是有區別的。

上面說了，在劃分職責的時候很多都是通過經驗來主觀的判斷，沒有其他的客觀證據了。那么有沒有一個不錯的方法論或模式來指導我們進行這類問題的解決呢，其實還是有的，因為在國外人家這方面已經很成熟。

GRASP就是這樣的一套模式，它可以幫助我們進行客觀的設計職責。到底該把這塊數據放入哪個應用中，到底該把這個邏輯放入哪個服務中，都有指導，包括對對象層面的設計依然可以。我們可能對“信息專家模式”都有了解，但是以往我們可能都只把它用在對象設計上，而沒有提升一個系統層面中考慮。那是因為我們以往可能沒有碰見很復雜的職責分配場景，只有當出現問題時我們才能真正領會某個東西的好壞。

DDD只有結合GRASP才能客觀準確的方配某個領域的職責，不管是戰略設計層面還是戰術設計層面，都是一個很好的平衡標準，不會由于技術人員主觀的興趣傾向導致一個錯誤的職責分配決定，而這個錯誤的決定最終是要開發人員來買單。

六、SOA分布式下的數據一致性

傳統分布式系統與當代的面向SOA的分布式系統有一定區別，論概念上來講SOA是以服務為中心，既然以服務為中心就會有很多面向服務的設計原則。而傳統的分布式系統沒有服務的概念，也沒有所謂的一切皆是服務的原則。而當代SOA則首要原則就要以服務為中心，針對服務的設計又有了很多服務設計原則。

SOA對服務還進行了類型的劃分，按照服務的應用層次來分類：業務服務、組合服務、應用服務，包裝服務等。再按照管理與運維的層面來分類：控制服務、調度服務、監控服務等等。傳統的分布式系統是沒有這些的，我們談論的是當代SOA的分布式系統，所以我們強調的是以服務為中心，以服務設計原則為架構設計的指導要求，當代SOA是對傳統分布式系統的一個迭代進化，不是一個時代的產物，SOA更加強調了以服務為首要原則，已經提升到了另外一個更加高級的層面。

本節我們交流一下在當代SOA分布式系統中的數據一致性問題，在SOA中這主要涉及兩個層面來考慮，一個是服務層面、一個數據持久化層面。再按照一致性的基本要求，可以分為：讀一致性、寫一致性、會話一致性、最終一致性、實時一致性等幾個維度，當然還有其他幾個維度的一致性要求。

我們這里重點討論在企業應用中實施SOA時遇到的一些比較棘手的數據一致性問題和解決方案，對于剛才提到的幾個維度的一致性要求均具有重要的參考價值。

1、分布式事務（基于DTC的分布式事務）

以往包括目前很多項目還是傾向于使用DTC來處理分布式事務，這個方案多數適用于一般的企業應用，業務、訪問量、數據量要求都不是很高的情況下。用DTC很方便，事務的自動傳播、事務的自動感知、事務的自動回滾和提交，這都是中央DTC幫我們管理好了。

由于有中央DTC的統一協調，看似好像幫我們解決了很多我們需要考慮的問題，但是它也是整個平臺的致命的瓶頸，一旦DTC由于某個問題出現錯誤，而且這種錯誤都是系統層面的錯誤，很多問題我們是無能為力的。如果出現問題，整個應用平臺都無法完成任何一個跨服務的業務流程，這其實很危險，你不無法控制系統的穩定性。

這里總結，DTC用于一般的小型企業應用，不建議用在中等規模的企業應用中，不是說這個東西不好，而是無法控制它。

2、事務補償（提供正向或反向的操作來讓數據在業務上是一致的）

世界級SOA專家所編寫的書籍里都提到了使用“補償”操作來完成數據的不一致性，當我們編寫了一個服務方法A，就需要一個服務方法A1的補償接口來完成A服務的補償操作。但是真實的業務情況下很難實施這種看起來好像很優美很柔性的設計。沒有實踐就沒有發言權，我們公司的技術團隊就實施過這種方案，但是很不理想，這跟技術本身及技術團隊沒關系，只是我們的平臺業務太復雜，很難去“補償”一個已經做過的操作。

這當然也要看你所面對的項目情況，量變引起質變，如果你的各種量都上去了，這個“補償”方案不實際，而且很難在數據層面進行“補償“。總之，這不是一個中長期的方案。

3、異步EDA（基于異步事件流來實現柔性的分布式事務）

EDA簡稱”事件驅動架構“。多個系統之間通過傳播”事件“來驅動整個業務的運轉。系統之間沒有緊耦合的同步調用的操作，都是通過發出異步的“事件”來通知下一個業務環節。

可能你會有一個疑問，異步操作，是不是系統之間延遲會很長，其實不是，現在有很多成熟的消息中間件在內網內幾乎是毫秒級別的延遲，至于跨機房就看物理上的距離了。

異步操作有很多好處，這里我就不浪費大家時間重復那些好處。使用EDA實現系統之間的一個松散的事務關系，要把控好項目的質量，對系統的非功能需求、BUG數等等可能會影響業務操作中斷的地方都要建立起適當的機制，讓這些問題盡早的在線下解決。比如可以實施UnitTest、持續集成等一些敏捷的方法論。

總結

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