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基因的徹底改造，形成了更簡化的一種分散式架構形態，尤其滿足更為網際網路化應用的需求。
前往讀位元組創作中心——瞭解”讀位元組“更多創作內容
本文是公眾號“讀位元組
”原創文章，轉載請務必顯示文章來源