共計(jì) 2983 個(gè)字符，預(yù)計(jì)需要花費(fèi) 8 分鐘才能閱讀完成。

本篇文章給大家分享的是有關(guān)然后用隧道協(xié)議實(shí)現(xiàn)不同 dubbo 集群間的透明通信，丸趣 TV 小編覺(jué)得挺實(shí)用的，因此分享給大家學(xué)習(xí)，希望大家閱讀完這篇文章后可以有所收獲，話(huà)不多說(shuō)，跟著丸趣 TV 小編一起來(lái)看看吧。

用隧道協(xié)議實(shí)現(xiàn)不同 dubbo 集群間的透明通信前言

筆者最近完成了一個(gè)非常有意思的隧道機(jī)制(已在產(chǎn)線(xiàn)運(yùn)行)，可以讓注冊(cè)到不同 zookeeper 之間的 dubbo 集群之間能夠正常進(jìn)行通信。如下圖所示:
例如圖中 A / B 兩個(gè)網(wǎng)絡(luò)隔離的集群，兩者只能通過(guò)專(zhuān)線(xiàn)進(jìn)行通信。但是對(duì)于在里面的應(yīng)用來(lái)說(shuō)，調(diào)用另外一個(gè)集群的 dubbo 服務(wù) (例如 app1 調(diào)用 app3) 依舊和原來(lái)的方式一模一樣，無(wú)需做任何修改。這個(gè)特性對(duì)于新建單元(機(jī)房), 業(yè)務(wù)網(wǎng)絡(luò)隔離等場(chǎng)景非常有用。

場(chǎng)景

這個(gè) dubbo 集群通信機(jī)制，可被用在下面的場(chǎng)景中。

新建機(jī)房

在我們新建一個(gè)機(jī)房的過(guò)程中。正常情況下，需要將一整條鏈路的所有應(yīng)用以及相關(guān)設(shè)施全部部署到新的機(jī)房中。如下圖所示:
而在筆者新的機(jī)制中，如果本集群沒(méi)有對(duì)應(yīng)的接口，會(huì)去尋找有對(duì)應(yīng)接口的集群，就算其中缺失了一些系統(tǒng)，整個(gè)機(jī)房依舊能夠 work，將新建機(jī)房變?yōu)榭傻降摹４蠓葴p少了新建機(jī)房的復(fù)雜性。

新建業(yè)務(wù)單元

由于單機(jī)房機(jī)架位的限制或者一些其它原因，有一些業(yè)務(wù)希望剝離到一個(gè)單獨(dú)的單元(機(jī)房里面)。但是業(yè)務(wù)確需要一大堆原來(lái)單元的基礎(chǔ)服務(wù)。而不同單元之間的網(wǎng)絡(luò)又無(wú)法打通(安全性要求)。
如果按照傳統(tǒng)的模式，勢(shì)必要對(duì)業(yè)務(wù)系統(tǒng)做改造，例如建立一個(gè)業(yè)務(wù)網(wǎng)關(guān)來(lái)負(fù)責(zé)和基礎(chǔ)系統(tǒng)的通信，這個(gè)網(wǎng)關(guān)明顯費(fèi)時(shí)費(fèi)力而且沒(méi)什么技術(shù)含量，例如在業(yè)務(wù)代碼中將 dubbo 調(diào)用強(qiáng)行轉(zhuǎn)換為對(duì)業(yè)務(wù)網(wǎng)關(guān)的 http 調(diào)用, 如下圖所示:
而且，每增加一個(gè)接口調(diào)用，都得在業(yè)務(wù)網(wǎng)關(guān)中轉(zhuǎn)換一把，添加對(duì)應(yīng)的接口包，然后發(fā)布。這樣的網(wǎng)關(guān)維護(hù)起來(lái)肯定是個(gè)天坑！隨著日益嚴(yán)格的安全性要求，不同業(yè)務(wù)間的網(wǎng)絡(luò)隔離要求會(huì)與日俱增。
筆者是搞中間件的，堅(jiān)信做的基礎(chǔ)服務(wù)能夠?qū)I(yè)務(wù)透明，讓其感知不到才是一個(gè)好的設(shè)計(jì)。一旦需要業(yè)務(wù)大量配合這種由基礎(chǔ)架構(gòu)變更而引起的改造，無(wú)疑是非常的不友好，甚至是個(gè)失敗的設(shè)計(jì)。

故障隔離

事實(shí)上，筆者搞這一套隧道機(jī)制的初衷還有很大一部分原因是故障隔離。例如，筆者遇到數(shù)次由于業(yè)務(wù)系統(tǒng)使用 zookeeper 不當(dāng)，往 zookeeper 寫(xiě)了一大堆數(shù)據(jù)，從而讓整個(gè)集群陷入不可用的風(fēng)險(xiǎn)。而新的機(jī)制，可以讓不同的業(yè)務(wù)注冊(cè)到不同的 zookeeper,zookeeper 掛了，也只是這個(gè)業(yè)務(wù)宕了，其它業(yè)務(wù)則不受影響。
事實(shí)上不僅為 zookeeper, 由于筆者對(duì)消息 (例如 activemq) 也做了這一套類(lèi)似的隧道機(jī)制。使得我們的整個(gè)業(yè)務(wù)能夠更好的進(jìn)行故障隔離！

隧道機(jī)制

筆者這個(gè)機(jī)制的最大便利性在于對(duì)業(yè)務(wù)的侵入性很少。對(duì)于基礎(chǔ)集群的應(yīng)用甚至完全不需要做修改。為了達(dá)成這個(gè)需求，筆者引入了在網(wǎng)絡(luò)上非常常用的隧道概念(Tunnel), 這個(gè)大家可能平時(shí)都接觸過(guò)，VPN/Vxlan 這些網(wǎng)絡(luò)協(xié)議都用了隧道。

隧道穿透

我們先來(lái)看一下最基本的原理，在系統(tǒng) A 通過(guò) Dubbo 調(diào)用系統(tǒng) B 的時(shí)候，在同一個(gè)集群中走的是 dubbo 協(xié)議。而跨集群的時(shí)候，筆者將 dubbo 原始比特流承載在 http 協(xié)議上，在專(zhuān)線(xiàn)上發(fā)出去。
由于在 B 系統(tǒng)看來(lái)，接收到的都是相同的 byte 流，其無(wú)法 (也不用) 區(qū)分到底是走了一層專(zhuān)線(xiàn)還是直接調(diào)用。所以 B 系統(tǒng)無(wú)需更改任何代碼。

隧道實(shí)現(xiàn)

那么，這個(gè)隧道具體是如何實(shí)現(xiàn)，系統(tǒng) A 又是如何知道需要本集群沒(méi)有對(duì)應(yīng)的接口，需要通過(guò) http 隧道調(diào)用到另一個(gè)集群的呢? 這就引入了我們的隧道網(wǎng)關(guān)。

這里的概念也是和網(wǎng)絡(luò)上的默認(rèn)網(wǎng)關(guān)類(lèi)似，如果本集群內(nèi)找不到對(duì)應(yīng)的接受者就投遞到一個(gè)默認(rèn)的網(wǎng)關(guān)，由這個(gè)隧道網(wǎng)關(guān)來(lái)替我們傳遞調(diào)用。

如何發(fā)現(xiàn)這個(gè)網(wǎng)關(guān)

為了充分利用 dubbo 接口的注冊(cè)發(fā)現(xiàn)機(jī)制，筆者將隧道網(wǎng)關(guān)也暴露為一個(gè) dubbo 接口，其輸入和輸出分別如下所示:

//  隧道網(wǎng)關(guān)接口請(qǐng)求體
class TunnelInterfaceReq {
 // dubbo 元信息，例如具體調(diào)用接口信息
 MetaData dubbo
 //  原始請(qǐng)求 A 調(diào)用序列化后的比特流
 byte[] body;
//  隧道網(wǎng)關(guān)接口返回體
class TunnelInterfaceResp{
 // dubbo 元信息
 MetaData dubbo
 //  返回值調(diào)用序列化后的比特流，由另一個(gè)集群的對(duì)應(yīng)系統(tǒng)返回
 byte[] resp;}

有了這個(gè) dubbo 接口，我們就可以很容易的將數(shù)據(jù)傳送給默認(rèn)網(wǎng)關(guān)了。
注意，這里其實(shí)也是做了一層隧道協(xié)議，即用 dubbo 協(xié)議承載 dubbo 協(xié)議，用這種類(lèi)似套娃的方法有效的利用了 dubbo 本身的注冊(cè)發(fā)現(xiàn)機(jī)制。

網(wǎng)關(guān)和網(wǎng)關(guān)之間通過(guò) http 通信

由于不同集群之間通過(guò)專(zhuān)線(xiàn)進(jìn)行通信，所以筆者采用了 http 通信來(lái)進(jìn)行。在 App1 的請(qǐng)求到達(dá)隧道網(wǎng)關(guān)后，網(wǎng)關(guān)會(huì)將原始 body 比特流從 TunnelInterfaceRequest 中取出。然后放到一個(gè) http 的請(qǐng)求中進(jìn)行傳遞。如下圖所示:
值得注意的是，由于傳遞的是 byte 流，沒(méi)有攜帶任何業(yè)務(wù)信息(例如類(lèi)型信息等), 所以我們的隧道網(wǎng)關(guān)可以對(duì)任意 dubbo 請(qǐng)求進(jìn)行隧道傳輸，而不像傳統(tǒng)的網(wǎng)關(guān)那樣需要添加各種業(yè)務(wù)對(duì)應(yīng)的 jar 包并不停發(fā)布 -_-!
在圖中，投遞到另一端的隧道網(wǎng)關(guān)后，其從 http 協(xié)議中取出調(diào)用元信息和原始調(diào)用 byte 流，通過(guò)調(diào)用元信息找到 App2。然后給 App2 重放 byte 流，這樣就可以進(jìn)行 dubbo 調(diào)用了。事實(shí)上，App2 從隧道網(wǎng)關(guān)看到的 byte 流和從集群內(nèi)其它機(jī)器調(diào)用的 byte 流完全一致。如下圖所示:

返回值也通過(guò)隧道機(jī)制

很明顯的，我們的返回值也需要通過(guò)隧道機(jī)制。和 Request 一樣，其也會(huì)走兩次隧道協(xié)議，如下圖所示:
那么 App1 真正接收到的其實(shí)是 Tunnel Response, 怎么讓其透明的接收原始 response 比特流呢？這就需要調(diào)用方接入筆者研發(fā)的輕量級(jí) jar 包(其實(shí)，一開(kāi)始的 request 的隧道也需要這樣的 jar 包)

對(duì) dubbo 進(jìn)行擴(kuò)展

由于 dubbo 有非常優(yōu)秀的 filter 機(jī)制，可以在各種地方可以擴(kuò)展。為了這個(gè)隧道機(jī)制，筆者就擴(kuò)展了其中的 invoke 調(diào)用邏輯。如下圖所示:

只要引入筆者寫(xiě)的 jar 包，就能夠非常輕松的進(jìn)行自動(dòng)擴(kuò)展，除了 pom.xml 加兩行，其它業(yè)務(wù)代碼完全無(wú)需修改。

隧道網(wǎng)關(guān)的接口發(fā)現(xiàn)

那么隧道網(wǎng)關(guān) A 是怎么知道接口在集群 B，從而投遞給隧道網(wǎng)關(guān) B 的呢？很明顯的，我們需要隧道網(wǎng)關(guān)間的集群通信機(jī)制。
例如, 由隧道網(wǎng)關(guān)向其它不同的隧道網(wǎng)關(guān)詢(xún)問(wèn)是否有此接口，并按一定策略做緩存即可。

dubbo 集群的發(fā)現(xiàn)

最后的問(wèn)題就是隧道網(wǎng)關(guān)怎么知道其它的 dubbo 集群的了，由于相對(duì)于 dubbo 接口數(shù)量，集群的數(shù)量是很少且不經(jīng)常改變。我們只需要找個(gè)地方簡(jiǎn)單的記錄下即可，例如放到數(shù)據(jù)庫(kù)里面。然后由于是 http 調(diào)用，直接通過(guò) DNS 解析域名即可做負(fù)載均衡。

性能

由于筆者的這套機(jī)制序列化和反序列化完全在 Provider/Consumer 端，完全沒(méi)有對(duì)網(wǎng)關(guān)形成任何壓力，所以網(wǎng)關(guān)的 CPU 消耗很低。在單個(gè)調(diào)用延遲上，由于多了兩跳，不可避免的有所損耗，大概每個(gè)接口多了 2ms 左右。

以上就是然后用隧道協(xié)議實(shí)現(xiàn)不同 dubbo 集群間的透明通信，丸趣 TV 小編相信有部分知識(shí)點(diǎn)可能是我們?nèi)粘９ぷ鲿?huì)見(jiàn)到或用到的。希望你能通過(guò)這篇文章學(xué)到更多知識(shí)。更多詳情敬請(qǐng)關(guān)注丸趣 TV 行業(yè)資訊頻道。