通俗地理解面向服務的架構（SOA）以及微服務之間的關係

SOA是一種軟件的應用架構方法，它基於面向對象，但又不是面向對象，總體上是面向服務的架構。SOA由精確的服務定義、鬆散的構件服務組成，以及業務流程調用等多個方面造成的一整套架構方法。
這話是否是聽起來，讓人以爲有點暈，咱們就細細品讀一下。

SOA的架構思想

（一）SOA架構是面向服務的，只不過是基於面向對象

SOA繼承了不少面向對象的特色，好比說面向對象的封裝，常常表明不少類封裝成一個模塊，爲其餘對象調用者提供接口調用，良好的面向對象設計就是暴露接口，隱藏實現，類比到SOA的設計，SOA也須要精準明確地定義好服務接口，具體服務內部的邏輯實現都是隱藏在背後的，只不過有兩個很大的區別：

• （1）面向對象的實現都是基於同一個編程語言或平臺（同構），但SOA服務完全隱藏了實現上用何種語言平臺的具體細節（異構）
• （2）面向對象的實現其實大部分都是本地方法之間的調用，固然也具有分佈式遠程方法調用，但SOA是純粹提供了獨立的服務，面向分佈式的遠程服務調用。

（二）SOA的服務定義是精確的

這個怎麼理解呢？由於SOA的服務一旦發佈出來，那麼就會有不少其餘的異構平臺服務進行調用，這時候的服務接口修改就不像一我的或者一個小團隊之間協做那麼容易了，可能涉及到一個大型企業多部門的信息協做，或者對構件已經造成依賴的生態鏈條。所以這就牽扯出了SOA另一個特徵，那就是服務接口的粒度通常要設置得比較粗。若提供過多的服務接口，服務又定義得很細粒度，那麼頻繁修改是在所不免的。這一點上就註定了SOA架構適合在較重量的環境下存在。

那什麼是較重量的環境呢？（1）體系健全、制度穩定的重管理型企業，（2）業務邏輯複雜，服務的獨立性，開放性需求又大，服務的穩定性也是剛需。例如：醫院信息化系統架構。

（三）SOA是由鬆散的構件服務組成

爲何是鬆散的呢？由上述咱們能夠了解到SOA的服務接口是粗粒度的，並且組成服務的構件都是獨立部署並具備獨立的上下文環境，這種形態就是爲了下降與其餘構件之間的強依賴性。讓每一個構件儘量一次性爲客戶提供足夠的其領域範圍的服務。

例如：通知服務，客戶端只要傳遞過來通知內容便可，究竟是通知短信、微信、站內信等等，這是通知服務與配置庫、用戶關係庫的內部邏輯關係，也能夠經過消息從其餘服務中獲取。所以SOA服務更傾向於前期就配置好通知渠道、通知用戶組的邏輯關係，這種形式就是客戶端輕，管理端重。

上述這種鬆散的、粗粒度的構建服務例子，就很是符合SOA架構的胃口，可讓每一個服務的獨立性看起來很不錯，提供一個簡單的接口外觀，並且越少的接口參數，頻繁更改的接口的概率就越低，又知足了服務接口的精確要求，以及服務更偏重管理的特色。

ESB、BPM在SOA中的實現方式

SOA架構能夠按業務流程調用各個構件服務，這是個什麼概念？想要弄清楚這個概念，咱們要站在上帝視角去俯視SOA架構了！

如上圖所示：這是一種SOA架構的解決方案，與ESB和BPM的基礎中間件結合，BPM做爲一個業務流程管理平臺，很好的將SOA服務經過流程建模的形式，與業務流程邏輯聯繫在一塊兒。那麼這個過程當中，BPM支撐SOA架構的業務流程協做問題，ESB支撐SOA架構的數據交換問題。這個架構體系是否是看起來就比較完整了！

例如：應急指揮系統中，咱們制定一個流程預案，能夠由BPM工具進行建模，進行不一樣獨立運行的SOA構件服務進行流程執行調度，並造成流程執行庫。應用執行端，通常就是客戶端手動或定時器自動，啓動流程引擎實例，流程引擎讀取流程模型庫，並配合應用管理端的操做，對構件服務實現訪問調度，流程引擎調度的這個過程當中，SOA的服務構件始終圍繞在ESB周圍，交換過程數據。進行物資服務調度、醫療資源服務調度、通信設備服務調度、對外信息披露服務調用等。

那麼這種架構例子中，你們是否是看得出來很是適合複雜應用系統整合、協做，由於頗有可能通信設備服務提供了C++網絡通信包，物資服務是Java平臺運行，醫療資源服務又是.Net平臺運行，可是你們基於統一的服務規約，提供精確而風格一致的服務接口，那麼對於BPM也好，ESB也好，就極大的減小了適配集成的複雜過程，讓各類業務和通信系統，都變成了一項服務，做爲SOA總體調度與管理的一枚棋子而存在。這其實就有點SOA的精髓了。

WebService的實現方式

每每不少人不太瞭解SOA的狀況下，就會認爲Webservice就是SOA，因此這就是爲何先把上面的SOA思想以及架構實現講講，你們就能對SOA有個總體全面的理解。Webservice只是實現SOA構件服務的一種手段，若將其中的換成基於RestFul風格的實現，也是沒有問題的。

WebService又依賴於幾種具體的技術規範和協議了，具體描述我就直接引用吧：

SOAP（Simple ObjectAccess Protocol，簡單對象訪問協議） 定義了服務請求者和服務提供者之間的消息傳輸規範，SOAP 用 XML 來格式化消息，用 HTTP 來承載消息。經過 SOAP，應用程序能夠在網絡中進行數據交換和遠程過程調用（Remote Procedure Call， RPC）。

WSDL（Web ServiceDescription Language，Web 服務描述語言） 是對服務進行描述的語言，它有一套基於 XML 的語法定義。WSDL 描述的重點是服務，它包含服務實現定義和服務接口定義。

UDDI（Universal DescriptionDiscovery and Integration，統一描述、發現和集成） 提供了一種服務發佈、查找和定位的方法，是服務的信息註冊規範，以便被須要該服務的用戶發現和使用它。UDDI 規範描述了服務的概念，同時也定義了一種編程接口。經過 UDDI 提供的標準接口，企業能夠發佈本身的服務供其餘企業查詢和調用，也能夠查詢特定服務的描述信息，並動態綁定到該服務上。

如何通俗地去理解這三大件呢？

仍是上個圖，看起來舒服一些。如上圖所示：SOA中的服務1須要調用服務2的接口，那麼咱們就描述一下Webservices方式。

首先虛線中，也就是開發階段服務1要去理解服務2的WSDL描述，清楚服務2提供的服務接口是什麼樣子，描述語言就是XML，服務1的程序就知道須要設置什麼參數，返回什麼結果。

而後在運行時服務1要從UDDI服務上，也就是註冊發現中心，找到服務2在哪裏，因爲服務2早已經在UDDI服務中註冊，那麼服務1就能夠得到服務2的路由地址。再對須要傳遞的數據進行SOAP格式編碼。

SOAP是HTTP層之上的一個傳輸協議，服務1對傳遞參數進行知足SOAP協議的xml編碼和參數發送，造成對服務2的WebService接口調用，服務2接收到SOAP協議數據，進行xml解碼，而後再進行內部實現層的邏輯處理，並最終將結果仍然以SOAP方式編碼返回給服務1，由服務1再解碼數據。這就完成了WebService的一次請求和響應。固然了服務1也能夠是一個普通的客戶端。

從上述的圖示例子中，咱們能夠看到WebService是經過XML做爲中間傳遞格式，這就兼容了異構平臺的數據格式，SOAP協議大部分是基於HTTP協議（SOAP的設計不限於HTTP），這樣就兼容了異構平臺數據傳輸。

所以WebService的技術實現方案就很是符合SOA架構中服務的異構平臺兼容性要求（SOAP），而且具有完整規範的服務接口語義描述（WSDL）和服務註冊發現管理的規範定義（UDDI）。

SOA與微服務的優劣對比

每每沒有對比就沒有傷害，所以咱們經過SOA架構與微服務架構的對比，來更深入地認識SOA架構的優點與劣勢，同時也能掌握到微服務優劣特徵。

咱們每每會從單體過渡的角度去尋求微服務的發展蹤影，也就是單體向微服務的過渡。但不多有人會去從SOA的變種這個角度去思考微服務。

所以咱們須要定義一個問題，微服務到底和SOA有沒有關係？其實，這其中就隱藏着兩種關係：

• （1）微服務簡化了SOA架構思想，是SOA一個離經叛道的繼任者，
• （2）微服務進行了SOA基因改造，成了一個新的變種，

微服務是SOA一個離經叛道的繼任者， 其實這是一句讚美之詞！

首先咱們來看看微服務和SOA比起來有多麼的類似，又多麼的不一樣。

（1）微服務專一小的個體問題，造成服務，經過鬆耦合的通信機制協做起來，解決更大的問題；反之，SOA一開始就專一大的協調問題，首先關注的是服務協議、規則、表述的統一性，而後纔是設計足夠大的獨立服務，並經過流程建模，解決總體上的問題。

（2）微服務傾向於拆分，也就是將單體應用盡可能拆分到一個適當的粒度，造成我的或小團隊去關注獨立的服務個體；但SOA不一樣，服務要足夠的粗粒度，服務接口只是做爲異構系統調用的統一手段，甚至咱們能夠將一個大系統做爲SOA的一個構建服務而獨立存在，例如前面說到的應急指揮系統的SOA架構中通信調度系統做爲一個獨立的SOA服務而存在。

（3）微服務的實施模式是自底向上型：不一樣的小團隊分配不一樣的微服務進行開發、構建、部署、發佈。系統總體上的把控，是在發佈、測試過程當中全部團隊共同參與的結果，這時候開發變成了運維，運維變成了顧問，這就是Devops的思想，所以微服務更適合小型團隊的持續化發佈；反之SOA是自頂向下的實施模式，必須進行分層式的過程管理，要有人對流程管理負責、ESB企業數據總線負責、各個構件服務也是不一樣組織的項目或開發團隊負責。所以SOA架構在實施過程當中具有清晰的責任關係，特別適合項目跨企業、大企業跨部門的複雜應用系統建設。這和微服務的實施過程能夠說是天壤之別。

（4）微服務與SOA同樣，都是在分佈式環境下，造成不少不一樣的獨立服務，相對於SOA，微服務是細粒度的，SOA是粗粒度的，並且它們在技術的異構性的兼容上有着一致的風格，微服務是經過通信機制，主要是Restful，實現不一樣微服務的相互協做，但微服務自身用什麼技術來實現，那都不影響；一樣前面的內容也說清楚了SOA的服務接口定義和Webservices實現，自己就是爲了統一兼容異構平臺之間的協做。

最後咱們看看SOA和微服務的對比總結

從上面的對比，咱們能夠看到不能把任何問題都統一論之。微服務有其適合的場景，若在一個複雜的社會關係體系下創建一套複雜的應用系統，微服務的架構思想就是無源之水了。反卻是SOA架構思想就具有這種複雜體系下的生存條件，可是，例如放到不少互聯網應用須要快速應對需求、敏捷迭代開發，靈活創建部署發佈機制，那麼SOA架構確定就不適合了，這種環境正是微服務架構所適應的。

所以咱們能夠總結到微服務在形式上與SOA很相似，在分佈式環境中都是進行更多獨立的服務、獨立的部署，咱們能夠理解是SOA的繼任者。可是骨子裏微服務又將SOA那一套沉重的前期規劃、設計和分層實施的思路完全打爛，造成了一個新的思想變種，靈活、敏捷、小巧，更適合團隊密切的協做。 這就是進行了SOA基因的完全改造，造成了更簡化的一種分佈式架構形態，尤爲知足更爲互聯網化應用的需求。

前往讀字節創做中心——瞭解」讀字節「更多創做內容

本文是公衆號「讀字節 」原創文章，轉載請務必顯示文章來源