曾今SOA的概念猶如今日“云計算、大數據”一樣，被炒得火熱，不少企業便紛紛響應，并宣稱會擁抱和實施SOA。而事實上，業界出現了兩種極端：一種是由于各類文章和書籍關于SOA的描述往往太過抽象，再加上各大廠商的呼吁，使得SOA往往顯得“高大上”，令不少企業和架構師們望而卻步。第二種恰好相反，有部分人卻認為SOA無非是“新瓶裝舊酒”。

個人理解，SOA在宏觀上確實太復雜，因為它涉及到的不僅僅是技術和架構本身。而從技術的視角來看，并非難以落地。

SOA全稱“面向服務架構”，它提供的是一種架構風格和理念，而并非是一種技術或者產品。并不是說項目中用了WebService、WCF、Hessian、RMI之類的就是SOA了。

通俗點來講，SOA提倡將不同應用程序的業務功能封裝成“服務”并宿主起來，通常以接口和契約的形式暴露并提供給外界應用訪問（通過交換消息），達到不同系統可重用的目的。

流行的WebService等可以看作是實現SOA基礎設施的技術方法。當然，實踐SOA不僅需要解決服務調用的問題，還包括服務編排、服務治理、服務路由、服務監控等一系列的問題。在大型分布式系統中，SOA被廣泛實踐，但是在不同的應用場景中，設計方法也大不相同。

SOA是一個組件模型，它能將不同的服務通過定義良好的接口和契約聯系起來。服務是SOA的基石，在開始服務設計和SOA實踐之前，有必要先了解服務的概念以及服務的常見特性。

何為服務

服務的概念非常寬泛，在宏觀上，服務的理解是“為他人做事，滿足他人需要，而且通常是不以實物形式提供勞動的…”。在SOA系統中，服務指的是應用程序的功能單元，它通常體現了業務功能。服務是一種抽象，它向服務使用者隱藏了服務內部的實現細節。根據服務設計的基本原則，服務可能會具有以下特性：

l  自治（理）性 

服務應該是獨立部署和運行存在的，且邊界清晰，應盡量減少對外部的引用和依賴。

l  粗粒度

服務調用是需要開銷的，這也是實現松耦合的分布式系統必須付出的代價。因此，應盡量通過一次服務調用傳輸所有需要的數據，而不是分多次去調用服務和組裝數據。

l  可見性

服務是對外提供的，必須在某公共的地方可搜尋和發現，且服務要有必要的描述。

l  無狀態

服務不應該依賴于其他服務的上下文、會話等，盡量減少不必要的狀態管理流程所帶來的資源消耗。但是，對于業務流程服務而言，狀態數據是不可避免的。

l  冪等性

當消費者調用服務后，服務調用可能會有“成功、失敗、超時”這三種狀態，當服務并沒有最終響應完成時，消費者可以嘗試反復地調用服務，這樣仍不會影響到最終結果。

l  可重用性

服務應該是可以被重用的，相同功能應可以調用相同的服務，這也是軟件設計的原則。

l  可組合

服務是可以被當作成一個步驟的，服務也可以調用其它的服務。這樣能夠靈活的組合。

有關服務的“粗粒度、無狀態、冪等性”等特性，一直是飽受爭議的話題，可謂見仁見智。這里有必要說明下，這些特性并不是服務不可或缺的，應當在實踐中根據需求來取舍。

SOA所面臨的問題

SOA架構將公共的業務拆分出來，形成可共用的服務，最大程度的保障了代碼和邏輯的復用，避免了系統的重復建設，并且讓應用程序的部署找到了一種持續可擴展的方案，給應用抗負載能力帶來了質的飛躍。

SOA架構所面臨的一大問題就是如何解決集成服務應用普遍存在的一致性問題，舉例來說，同時調用多個服務，當其中一個服務調用失敗時，其他服務已經處理執行的結果該如何進行回滾，這在單機本地調用的情況下使用事務比較好處理，而分布式環境下的事務將問題復雜化，并且性能開銷難以承受，因此，只有在極端情況下才會考慮強一致性，一般情況下更多的關注最終一致性。另外一個就是安全問題，面向企業的平臺級的SOA架構，需要對參數傳遞、響應內容以及各種用戶私有信息的交互，有著更嚴格的且特殊的安全需求，如何構建一個安全的SOA架構體系，也給技術人員帶來了很大的挑戰。

在講了很多“大而空”的理論之后，估計很多人要拍磚了。后面文章中將會講一些干貨，更貼合實際應用。先預告一下后面文章：

1.SOA之基于服務總線的設計

（從設計的角度講述服務總線--比較適合企業級系統集成的設計方式）

2.大型分布式網站的演變歷程

（隨著網站快速發展，解決業務復雜化、大流量、穩定性等問題的必經之路。正所謂“天下大勢，分久必合，合久必分”。

重點不是講負載均衡這些手段，而是設計層面的“集中式”到“分布式”）

3.SOA架構體系之通信協議和遠程調用（RPC）

（講解具體的實現技術，對比各自優缺點）

4.SOA之基于服務框架的應用

（服務化實踐--介紹流行的服務框架，重點演示一種服務框架的使用）