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基因的徹底改造，形成了更簡化的一種分布式架構形態，尤其滿足更為互聯網化應用的需求，

前往讀位元組創作中心——了解”讀位元組“更多創作內容

本文是公眾號“讀位元組”原創文章，轉載請務必顯示文章來源

標籤：架構設計

上一篇：java OA辦公管理系統 Springboot vue 前后分離 跨域 作業流 集成代碼生成器

下一篇：springcloud Alibaba 阿里組件 nacos注冊中心 gateway網關 flowable流程引擎 vue.js前后分離