SOA是一種軟件的應(yīng)用架構(gòu)方法，它基于面向?qū)ο?，但又不是面向?qū)ο?，整體上是面向服務(wù)的架構(gòu)。SOA由精確的服務(wù)定義、松散的構(gòu)件服務(wù)組成，以及業(yè)務(wù)流程調(diào)用等多個(gè)方面形成的一整套架構(gòu)方法。這話是不是聽起來，讓人覺得有點(diǎn)暈，我們就細(xì)細(xì)品讀一下。

SOA的架構(gòu)思想

（一）SOA架構(gòu)是面向服務(wù)的，只不過是基于面向?qū)ο?/strong>

SOA繼承了很多面向?qū)ο蟮奶攸c(diǎn)，比如說面向?qū)ο蟮姆庋b，經(jīng)常代表很多類封裝成一個(gè)模塊，為其他對(duì)象調(diào)用者提供接口調(diào)用，良好的面向?qū)ο笤O(shè)計(jì)就是暴露接口，隱藏實(shí)現(xiàn)，類比到SOA的設(shè)計(jì)，SOA也需要精準(zhǔn)明確地定義好服務(wù)接口，具體服務(wù)內(nèi)部的邏輯實(shí)現(xiàn)都是隱藏在背后的，只不過有兩個(gè)很大的區(qū)別：

• （1）面向?qū)ο蟮膶?shí)現(xiàn)都是基于同一個(gè)編程語言或平臺(tái)（同構(gòu)），但SOA服務(wù)徹底隱藏了實(shí)現(xiàn)上用何種語言平臺(tái)的具體細(xì)節(jié)（異構(gòu)）

• （2）面向?qū)ο蟮膶?shí)現(xiàn)其實(shí)大部分都是本地方法之間的調(diào)用，當(dāng)然也具備分布式遠(yuǎn)程方法調(diào)用，但SOA是純粹提供了獨(dú)立的服務(wù)，面向分布式的遠(yuǎn)程服務(wù)調(diào)用。

（二）SOA的服務(wù)定義是精確的

這個(gè)怎么理解呢？因?yàn)镾OA的服務(wù)一旦發(fā)布出來，那么就會(huì)有很多其他的異構(gòu)平臺(tái)服務(wù)進(jìn)行調(diào)用，這時(shí)候的服務(wù)接口修改就不像一個(gè)人或者一個(gè)小團(tuán)隊(duì)之間協(xié)作那么容易了，可能涉及到一個(gè)大型企業(yè)多部門的信息協(xié)作，或者對(duì)構(gòu)件已經(jīng)形成依賴的生態(tài)鏈條。因此這就牽扯出了SOA另外一個(gè)特征，那就是服務(wù)接口的粒度一般要設(shè)置得比較粗。若提供過多的服務(wù)接口，服務(wù)又定義得很細(xì)粒度，那么頻繁修改是在所難免的。這一點(diǎn)上就注定了SOA架構(gòu)適合在較重量的環(huán)境下存在。

那什么是較重量的環(huán)境呢？（1）體系健全、制度穩(wěn)定的重管理型企業(yè)，（2）業(yè)務(wù)邏輯復(fù)雜，服務(wù)的獨(dú)立性，開放性需求又大，服務(wù)的穩(wěn)定性也是剛需。例如：醫(yī)院信息化系統(tǒng)架構(gòu)。

（三）SOA是由松散的構(gòu)件服務(wù)組成

為什么是松散的呢？由上述我們可以了解到SOA的服務(wù)接口是粗粒度的，而且組成服務(wù)的構(gòu)件都是獨(dú)立部署并具有獨(dú)立的上下文環(huán)境，這種形態(tài)就是為了降低與其他構(gòu)件之間的強(qiáng)依賴性。讓每個(gè)構(gòu)件盡可能一次性為客戶提供足夠的其領(lǐng)域范圍的服務(wù)。

例如：通知服務(wù)，客戶端只要傳遞過來通知內(nèi)容即可，到底是通知短信、微信、站內(nèi)信等等，這是通知服務(wù)與配置庫、用戶關(guān)系庫的內(nèi)部邏輯關(guān)系，也可以通過消息從其他服務(wù)中獲取。因此SOA服務(wù)更傾向于前期就配置好通知渠道、通知用戶組的邏輯關(guān)系，這種形式就是客戶端輕，管理端重。

上述這種松散的、粗粒度的構(gòu)建服務(wù)例子，就非常符合SOA架構(gòu)的胃口，可以讓每個(gè)服務(wù)的獨(dú)立性看起來很不錯(cuò)，提供一個(gè)簡單的接口外觀，而且越少的接口參數(shù)，頻繁更改的接口的幾率就越低，又滿足了服務(wù)接口的精確要求，以及服務(wù)更偏重管理的特點(diǎn)。

ESB、BPM在SOA中的實(shí)現(xiàn)方式

SOA架構(gòu)可以按業(yè)務(wù)流程調(diào)用各個(gè)構(gòu)件服務(wù)，這是個(gè)什么概念？想要弄清楚這個(gè)概念，我們要站在上帝視角去俯視SOA架構(gòu)了！

如上圖所示：這是一種SOA架構(gòu)的解決方案，與ESB和BPM的基礎(chǔ)中間件結(jié)合，BPM作為一個(gè)業(yè)務(wù)流程管理平臺(tái)，很好的將SOA服務(wù)通過流程建模的形式，與業(yè)務(wù)流程邏輯聯(lián)系在一起。那么這個(gè)過程中，BPM支撐SOA架構(gòu)的業(yè)務(wù)流程協(xié)作問題，ESB支撐SOA架構(gòu)的數(shù)據(jù)交換問題。這個(gè)架構(gòu)體系是不是看起來就比較完整了！

例如：應(yīng)急指揮系統(tǒng)中，我們制定一個(gè)流程預(yù)案，可以由BPM工具進(jìn)行建模，進(jìn)行不同獨(dú)立運(yùn)行的SOA構(gòu)件服務(wù)進(jìn)行流程執(zhí)行調(diào)度，并形成流程執(zhí)行庫。應(yīng)用執(zhí)行端，一般就是客戶端手動(dòng)或定時(shí)器自動(dòng)，啟動(dòng)流程引擎實(shí)例，流程引擎讀取流程模型庫，并配合應(yīng)用管理端的操作，對(duì)構(gòu)件服務(wù)實(shí)現(xiàn)訪問調(diào)度，流程引擎調(diào)度的這個(gè)過程中，SOA的服務(wù)構(gòu)件始終圍繞在ESB周圍，交換過程數(shù)據(jù)。進(jìn)行物資服務(wù)調(diào)度、醫(yī)療資源服務(wù)調(diào)度、通訊設(shè)備服務(wù)調(diào)度、對(duì)外信息披露服務(wù)調(diào)用等。

那么這種架構(gòu)例子中，大家是不是看得出來非常適合復(fù)雜應(yīng)用系統(tǒng)整合、協(xié)作，因?yàn)楹苡锌赡芡ㄓ嵲O(shè)備服務(wù)提供了C++網(wǎng)絡(luò)通訊包，物資服務(wù)是Java平臺(tái)運(yùn)行，醫(yī)療資源服務(wù)又是.Net平臺(tái)運(yùn)行，但是大家基于統(tǒng)一的服務(wù)規(guī)約，提供精確而風(fēng)格一致的服務(wù)接口，那么對(duì)于BPM也好，ESB也好，就極大的減少了適配集成的復(fù)雜過程，讓各種業(yè)務(wù)和通訊系統(tǒng)，都變成了一項(xiàng)服務(wù)，作為SOA整體調(diào)度與管理的一枚棋子而存在。這其實(shí)就有點(diǎn)SOA的精髓了。

WebService的實(shí)現(xiàn)方式

往往很多人不太了解SOA的情況下，就會(huì)認(rèn)為Webservice就是SOA，所以這就是為什么先把上面的SOA思想以及架構(gòu)實(shí)現(xiàn)講講，大家就能對(duì)SOA有個(gè)整體全面的理解。Webservice只是實(shí)現(xiàn)SOA構(gòu)件服務(wù)的一種手段，若將其中的換成基于RestFul風(fēng)格的實(shí)現(xiàn)，也是沒有問題的。

WebService又依賴于幾種具體的技術(shù)規(guī)范和協(xié)議了，具體描述我就直接引用吧：

SOAP（Simple ObjectAccess Protocol，簡單對(duì)象訪問協(xié)議） 定義了服務(wù)請(qǐng)求者和服務(wù)提供者之間的消息傳輸規(guī)范，SOAP 用 XML 來格式化消息，用 HTTP 來承載消息。通過 SOAP，應(yīng)用程序可以在網(wǎng)絡(luò)中進(jìn)行數(shù)據(jù)交換和遠(yuǎn)程過程調(diào)用（Remote Procedure Call， RPC）。

WSDL（Web ServiceDescription Language，Web 服務(wù)描述語言） 是對(duì)服務(wù)進(jìn)行描述的語言，它有一套基于 XML 的語法定義。WSDL 描述的重點(diǎn)是服務(wù)，它包含服務(wù)實(shí)現(xiàn)定義和服務(wù)接口定義。

UDDI（Universal DescriptionDiscovery and Integration，統(tǒng)一描述、發(fā)現(xiàn)和集成） 提供了一種服務(wù)發(fā)布、查找和定位的方法，是服務(wù)的信息注冊(cè)規(guī)范，以便被需要該服務(wù)的用戶發(fā)現(xiàn)和使用它。UDDI 規(guī)范描述了服務(wù)的概念，同時(shí)也定義了一種編程接口。通過 UDDI 提供的標(biāo)準(zhǔn)接口，企業(yè)可以發(fā)布自己的服務(wù)供其他企業(yè)查詢和調(diào)用，也可以查詢特定服務(wù)的描述信息，并動(dòng)態(tài)綁定到該服務(wù)上。

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

還是上個(gè)圖，看起來舒服一些。如上圖所示：SOA中的服務(wù)1需要調(diào)用服務(wù)2的接口，那么我們就描述一下Webservices方式。

首先虛線中，也就是開發(fā)階段服務(wù)1要去理解服務(wù)2的WSDL描述，清楚服務(wù)2提供的服務(wù)接口是什么樣子，描述語言就是XML，服務(wù)1的程序就知道需要設(shè)置什么參數(shù)，返回什么結(jié)果。

然后在運(yùn)行時(shí)服務(wù)1要從UDDI服務(wù)上，也就是注冊(cè)發(fā)現(xiàn)中心，找到服務(wù)2在哪里，由于服務(wù)2早已經(jīng)在UDDI服務(wù)中注冊(cè)，那么服務(wù)1就可以獲得服務(wù)2的路由地址。再對(duì)需要傳遞的數(shù)據(jù)進(jìn)行SOAP格式編碼。

SOAP是HTTP層之上的一個(gè)傳輸協(xié)議，服務(wù)1對(duì)傳遞參數(shù)進(jìn)行滿足SOAP協(xié)議的xml編碼和參數(shù)發(fā)送，形成對(duì)服務(wù)2的WebService接口調(diào)用，服務(wù)2接收到SOAP協(xié)議數(shù)據(jù)，進(jìn)行xml解碼，然后再進(jìn)行內(nèi)部實(shí)現(xiàn)層的邏輯處理，并最終將結(jié)果仍然以SOAP方式編碼返回給服務(wù)1，由服務(wù)1再解碼數(shù)據(jù)。這就完成了WebService的一次請(qǐng)求和響應(yīng)。當(dāng)然了服務(wù)1也可以是一個(gè)普通的客戶端。

從上述的圖示例子中，我們可以看到WebService是通過XML作為中間傳遞格式，這就兼容了異構(gòu)平臺(tái)的數(shù)據(jù)格式，SOAP協(xié)議大部分是基于HTTP協(xié)議（SOAP的設(shè)計(jì)不限于HTTP），這樣就兼容了異構(gòu)平臺(tái)數(shù)據(jù)傳輸。

因此WebService的技術(shù)實(shí)現(xiàn)方案就非常符合SOA架構(gòu)中服務(wù)的異構(gòu)平臺(tái)兼容性要求（SOAP），并且具備完整規(guī)范的服務(wù)接口語義描述（WSDL）和服務(wù)注冊(cè)發(fā)現(xiàn)管理的規(guī)范定義（UDDI）。

SOA與微服務(wù)的優(yōu)劣對(duì)比

往往沒有對(duì)比就沒有傷害，因此我們通過SOA架構(gòu)與微服務(wù)架構(gòu)的對(duì)比，來更深刻地認(rèn)識(shí)SOA架構(gòu)的優(yōu)勢與劣勢，同時(shí)也能掌握到微服務(wù)優(yōu)劣特征。

單體向微服務(wù)過渡架構(gòu)

我們往往會(huì)從上圖的角度去尋求微服務(wù)的發(fā)展蹤跡，也就是單體向微服務(wù)的過渡。但很少有人會(huì)去從SOA的變種這個(gè)角度去思考微服務(wù)。

因此我們需要定義一個(gè)問題，微服務(wù)到底和SOA有沒有關(guān)系？其實(shí)，這其中就隱藏著兩種關(guān)系：

• （1）微服務(wù)簡化了SOA架構(gòu)思想，是SOA一個(gè)離經(jīng)叛道的繼任者，

• （2）微服務(wù)進(jìn)行了SOA基因改造，成了一個(gè)新的變種，

微服務(wù)是SOA一個(gè)離經(jīng)叛道的繼任者， 其實(shí)這是一句贊美之詞！

首先我們來看看微服務(wù)和SOA比起來有多么的相似，又多么的不同。

（1）微服務(wù)專注小的個(gè)體問題，形成服務(wù)，通過松耦合的通訊機(jī)制協(xié)作起來，解決更大的問題；反之，SOA一開始就專注大的協(xié)調(diào)問題，首先關(guān)注的是服務(wù)協(xié)議、規(guī)則、表述的統(tǒng)一性，然后才是設(shè)計(jì)足夠大的獨(dú)立服務(wù)，并通過流程建模，解決整體上的問題。

（2）微服務(wù)傾向于拆分，也就是將單體應(yīng)用盡量拆分到一個(gè)適當(dāng)?shù)牧６?，形成個(gè)人或小團(tuán)隊(duì)去關(guān)注獨(dú)立的服務(wù)個(gè)體；但SOA不同，服務(wù)要足夠的粗粒度，服務(wù)接口只是作為異構(gòu)系統(tǒng)調(diào)用的統(tǒng)一手段，甚至我們可以將一個(gè)大系統(tǒng)作為SOA的一個(gè)構(gòu)建服務(wù)而獨(dú)立存在，例如前面說到的應(yīng)急指揮系統(tǒng)的SOA架構(gòu)中通訊調(diào)度系統(tǒng)作為一個(gè)獨(dú)立的SOA服務(wù)而存在。

（3）微服務(wù)的實(shí)施模式是自底向上型：不同的小團(tuán)隊(duì)分配不同的微服務(wù)進(jìn)行開發(fā)、構(gòu)建、部署、發(fā)布。系統(tǒng)整體上的把控，是在發(fā)布、測試過程中所有團(tuán)隊(duì)共同參與的結(jié)果，這時(shí)候開發(fā)變成了運(yùn)維，運(yùn)維變成了顧問，這就是Devops的思想，因此微服務(wù)更適合小型團(tuán)隊(duì)的持續(xù)化發(fā)布；反之SOA是自頂向下的實(shí)施模式，必須進(jìn)行分層式的過程管理，要有人對(duì)流程管理負(fù)責(zé)、ESB企業(yè)數(shù)據(jù)總線負(fù)責(zé)、各個(gè)構(gòu)件服務(wù)也是不同組織的項(xiàng)目或開發(fā)團(tuán)隊(duì)負(fù)責(zé)。因此SOA架構(gòu)在實(shí)施過程中具備清晰的責(zé)任關(guān)系，特別適合項(xiàng)目跨企業(yè)、大企業(yè)跨部門的復(fù)雜應(yīng)用系統(tǒng)建設(shè)。這和微服務(wù)的實(shí)施過程可以說是天壤之別。

（4）微服務(wù)與SOA一樣，都是在分布式環(huán)境下，形成很多不同的獨(dú)立服務(wù)，相對(duì)于SOA，微服務(wù)是細(xì)粒度的，SOA是粗粒度的，而且它們?cè)诩夹g(shù)的異構(gòu)性的兼容上有著一致的風(fēng)格，微服務(wù)是通過通訊機(jī)制，主要是Restful，實(shí)現(xiàn)不同微服務(wù)的相互協(xié)作，但微服務(wù)自身用什么技術(shù)來實(shí)現(xiàn)，那都不影響；同樣前面的內(nèi)容也說清楚了SOA的服務(wù)接口定義和Webservices實(shí)現(xiàn)，本身就是為了統(tǒng)一兼容異構(gòu)平臺(tái)之間的協(xié)作。

最后我們看看SOA和微服務(wù)的對(duì)比總結(jié)

從上面的對(duì)比，我們可以看到不能把任何問題都統(tǒng)一論之。微服務(wù)有其適合的場景，若在一個(gè)復(fù)雜的社會(huì)關(guān)系體系下建立一套復(fù)雜的應(yīng)用系統(tǒng)，微服務(wù)的架構(gòu)思想就是無源之水了。反倒是SOA架構(gòu)思想就具備這種復(fù)雜體系下的生存條件，但是，例如放到很多互聯(lián)網(wǎng)應(yīng)用需要快速應(yīng)對(duì)需求、敏捷迭代開發(fā)，靈活建立部署發(fā)布機(jī)制，那么SOA架構(gòu)肯定就不適合了，這種環(huán)境正是微服務(wù)架構(gòu)所適應(yīng)的。

因此我們可以總結(jié)到微服務(wù)在形式上與SOA很類似，在分布式環(huán)境中都是進(jìn)行更多獨(dú)立的服務(wù)、獨(dú)立的部署，我們可以理解是SOA的繼任者。但是骨子里微服務(wù)又將SOA那一套沉重的前期規(guī)劃、設(shè)計(jì)和分層實(shí)施的思路徹底打爛，形成了一個(gè)新的思想變種，靈活、敏捷、小巧，更適合團(tuán)隊(duì)密切的協(xié)作。 這就是進(jìn)行了SOA基因的徹底改造，形成了更簡化的一種分布式架構(gòu)形態(tài)，尤其滿足更為互聯(lián)網(wǎng)化應(yīng)用的需求。