《什么是SOA》中可以看到松耦合對(duì)于SOA架構(gòu)的意義，SOA架構(gòu)最求的就是將原來(lái)一個(gè)超級(jí)大型的系統(tǒng)裁剪，減少依賴，減少相互之間的影響，簡(jiǎn)單的說(shuō)就是增強(qiáng)靈活性：增強(qiáng)接需求的靈活性，增強(qiáng)修改bug的靈活性，SOA架構(gòu)最求的就是這個(gè)，當(dāng)然這并不是說(shuō)引入了一個(gè)SOA框架，比如WCF，或者一種服務(wù)調(diào)用框架，hsf，就可以實(shí)現(xiàn)這個(gè)目標(biāo)了，這還是和你的服務(wù)劃分的方式，部門(mén)之間的協(xié)作程度，一些技術(shù)點(diǎn)的抉擇有關(guān)。
下面講一下一些技術(shù)點(diǎn)里的耦合聯(lián)系：
| | 緊耦合 | 松耦合 |
| 物理連接 | 點(diǎn)對(duì)點(diǎn) | 通過(guò)中介者 |
| 通信風(fēng)格 | 同步 | 異步 |
| 數(shù)據(jù)模型 | 公共復(fù)雜類型 | 只是簡(jiǎn)單的公共類型 |
| 類型系統(tǒng) | 強(qiáng) | 弱 |
| 交互模式 | 通過(guò)復(fù)雜的對(duì)象樹(shù)導(dǎo)航 | 以數(shù)據(jù)為中心、自足的消息 |
| 業(yè)務(wù)邏輯控制 | 集中控制 | 分布式控制 |
| 綁定方式 | 靜態(tài) | 動(dòng)態(tài) |
| 平臺(tái) | 強(qiáng)平臺(tái)依賴 | 平臺(tái)無(wú)關(guān) |
| 事務(wù)性 | 2PC（兩階段提交） | 補(bǔ)償 |
| 部署 | 同時(shí)進(jìn)行 | 非同時(shí)進(jìn)行 |
| 版本劃分 | 顯示升級(jí) | 隱式升級(jí) |
1.物理連接，在WCF中使用，直接使用添加引用的方式，其實(shí)就是點(diǎn)對(duì)點(diǎn)的連接，服務(wù)端關(guān)閉的時(shí)候就會(huì)調(diào)用失敗，包括hsf服務(wù)，有時(shí)候也要配置地址，這也是緊耦合的，另外hsf還可以通過(guò)configserver去獲取，消費(fèi)者可以通過(guò)服務(wù)名(標(biāo)簽或者符號(hào))來(lái)標(biāo)識(shí)要訪問(wèn)的服務(wù)，雖然還是點(diǎn)對(duì)點(diǎn)的，但是已經(jīng)實(shí)現(xiàn)了間接性(要做適當(dāng)緩存，避免每次詢問(wèn)地址，影響性能)。這實(shí)際上就是通過(guò)中介者，這相對(duì)來(lái)說(shuō)可以更加松耦合。它可以同時(shí)在里面做負(fù)載平衡和是失效備援，這屬于那種在出發(fā)之前就告訴你正確的服務(wù)端點(diǎn)，這要求消費(fèi)者端只能一點(diǎn)，比如配置一個(gè)ConfigServer。另外，還可以讓每個(gè)服務(wù)做到動(dòng)態(tài)提供，在啟動(dòng)或者運(yùn)行時(shí)，每個(gè)供應(yīng)者注冊(cè)自己。
除了connfigServer，還可以提供一種攔截器的方式，或者叫做代理，每個(gè)請(qǐng)求都請(qǐng)求道一個(gè)七負(fù)載均衡作用的硬件或者軟件，消費(fèi)者仍然使用一個(gè)正式的端點(diǎn)，該端點(diǎn)再委派真正的任務(wù)：當(dāng)消息到達(dá)時(shí)，負(fù)載均衡器把消息分發(fā)到自己所知的不同的物理服務(wù)供應(yīng)者上。
更復(fù)雜一些的ESB方法為每個(gè)供應(yīng)者和消費(fèi)者提供一個(gè)攔截器代理，消費(fèi)者只與正對(duì)自己的特定攔截器進(jìn)行“點(diǎn)對(duì)點(diǎn)“方式的通信。
Web Service天生就是一種點(diǎn)對(duì)點(diǎn)的協(xié)議，沒(méi)有包含對(duì)負(fù)載均衡和失效備援的規(guī)定。這兩個(gè)仍然是大型分布式系統(tǒng)的核心需求，因此，每個(gè)基于Web Service的ESB遲早都要把攔截器結(jié)合進(jìn)去。
2.通信風(fēng)格，異步通信意味著消息的發(fā)送和消息的接收者沒(méi)有同步，這好比電子郵件。這里發(fā)送者面對(duì)的而一個(gè)難題就是需要一個(gè)答復(fù)，可以這并不是馬上就能獲得答復(fù)，這樣，當(dāng)應(yīng)答到來(lái)的時(shí)候，必須把答復(fù)和最初的請(qǐng)求關(guān)聯(lián)起來(lái)(例如，通過(guò)處理類似ID的東西)；另外，處理答復(fù)的時(shí)候看，可能需要最初請(qǐng)求的時(shí)候的初始狀態(tài)和上下文環(huán)境；還有，大量的異步請(qǐng)求發(fā)出的時(shí)候，收到應(yīng)答的順序可能不同發(fā)出的順序，調(diào)試的時(shí)候可能非常悲?。贿@樣引入異步處理的邏輯變得這么復(fù)雜。
《ESB的消息交換》
3.數(shù)據(jù)類型，.NET中有DataTable類型，結(jié)合一些控件使用，非常方便，但是在使用WCF的時(shí)候，如果將它作為返回類型，那么將會(huì)散失互操作性，java中并不能引用到解釋這種類型，這就是緊耦合。
雖然搞一個(gè)簡(jiǎn)單的數(shù)據(jù)類型是最好的，但是在一個(gè)大型的系統(tǒng)中，最求完美的一致性可能是一種災(zāi)難，會(huì)讓你的工作停步不前；另外，在大型組織中，人們就是無(wú)法一致化意見(jiàn)，各個(gè)子系統(tǒng)的所有者有不同的利益，達(dá)成一致意見(jiàn)很難；另外不斷變化的需求業(yè)務(wù)，也會(huì)使得模型改變。
在大型的系統(tǒng)中，數(shù)據(jù)類型如果沒(méi)有一致化，那你可能需要一種適合你的“數(shù)據(jù)映射”，雖然增加了一點(diǎn)復(fù)雜性，但是這是一種解耦，應(yīng)該避免直接依賴供應(yīng)者提供的數(shù)據(jù)類型；另外不采用一致的數(shù)據(jù)模型，那么你的修改不會(huì)對(duì)其他系統(tǒng)直接造成影響。
4補(bǔ)償
為了保持狀態(tài)同步，可以使用稱為2PC，兩階段提交的技術(shù)創(chuàng)建一個(gè)公共的事務(wù)上下文環(huán)境，最后執(zhí)行成功的話，提交執(zhí)行在兩個(gè)系統(tǒng)，這可能是作為一個(gè)中間件的重要特性，這可能會(huì)造成死鎖和延遲，并且在多個(gè)異質(zhì)的平臺(tái)上實(shí)現(xiàn)這個(gè)，會(huì)有很多技術(shù)上的復(fù)雜性。補(bǔ)償可能是一種更加松耦合的方式。BPEL直接支持補(bǔ)償。
聯(lián)系客服
