用隧道協議實現不同dubbo叢集間的透明通訊

Al發表於2021-01-12

用隧道協議實現不同dubbo叢集間的透明通訊

前言

筆者最近完成了一個非常有意思的隧道機制(已在產線執行)，可以讓註冊到不同zookeeper之間的dubbo叢集之間能夠正常進行通訊。如下圖所示:

例如圖中A/B兩個網路隔離的叢集，兩者只能通過專線進行通訊。但是對於在裡面的應用來說，呼叫另外一個叢集的dubbo服務(例如app1呼叫app3)依舊和原來的方式一模一樣，無需做任何修改。這個特性對於新建單元(機房),業務網路隔離等場景非常有用。
本文就稍稍聊一下這個機制。

場景

這個dubbo叢集通訊機制，可被用在下面的場景中。

新建機房

在我們新建一個機房的過程中。正常情況下，需要將一整條鏈路的所有應用以及相關設施全部部署到新的機房中。如下圖所示:

而在筆者新的機制中，如果本叢集沒有對應的介面，會去尋找有對應介面的叢集，就算其中缺失了一些系統，整個機房依舊能夠work，將新建機房變為可迭代式的。大幅度減少了新建機房的複雜性。

新建業務單元

由於單機房機架位的限制或者一些其它原因，有一些業務希望剝離到一個單獨的單元(機房裡面)。但是業務確需要一大堆原來單元的基礎服務。而不同單元之間的網路又無法打通(安全性要求)。

如果按照傳統的模式，勢必要對業務系統做改造，例如建立一個業務閘道器來負責和基礎系統的通訊，這個閘道器明顯費時費力而且沒什麼技術含量，例如在業務程式碼中將dubbo呼叫強行轉換為對業務閘道器的http呼叫,如下圖所示:

而且，每增加一個介面呼叫，都得在業務閘道器中轉換一把，新增對應的介面包，然後釋出。這樣的閘道器維護起來肯定是個天坑！隨著日益嚴格的安全性要求，不同業務間的網路隔離要求會與日俱增。
筆者是搞中介軟體的，堅信做的基礎服務能夠對業務透明，讓其感知不到才是一個好的設計。一旦需要業務大量配合這種由基礎架構變更而引起的改造，無疑是非常的不友好，甚至是個失敗的設計。

故障隔離

事實上，筆者搞這一套隧道機制的初衷還有很大一部分原因是故障隔離。例如，筆者遇到數次由於業務系統使用zookeeper不當，往zookeeper寫了一大堆資料，從而讓整個叢集陷入不可用的風險。而新的機制，可以讓不同的業務註冊到不同的zookeeper,zookeeper掛了，也只是這個業務宕了，其它業務則不受影響。

事實上不僅為zookeeper,由於筆者對訊息(例如activemq)也做了這一套類似的隧道機制。使得我們的整個業務能夠更好的進行故障隔離！

隧道機制

筆者這個機制的最大便利性在於對業務的侵入性很少。對於基礎叢集的應用甚至完全不需要做修改。為了達成這個需求，筆者引入了在網路上非常常用的隧道概念(Tunnel),這個大家可能平時都接觸過，VPN/Vxlan這些網路協議都用了隧道。

隧道穿透

我們先來看一下最基本的原理，在系統A通過Dubbo呼叫系統B的時候，在同一個叢集中走的是dubbo協議。而跨叢集的時候，筆者將dubbo原始位元流承載在http協議上，在專線上發出去。

由於在B系統看來，接收到的都是相同的byte流，其無法(也不用)區分到底是走了一層專線還是直接呼叫。所以B系統無需更改任何程式碼。

隧道實現

那麼，這個隧道具體是如何實現，系統A又是如何知道需要本叢集沒有對應的介面，需要通過http隧道呼叫到另一個叢集的呢?這就引入了我們的隧道閘道器。

這裡的概念也是和網路上的預設閘道器類似，如果本叢集內找不到對應的接受者就投遞到一個預設的閘道器，由這個隧道閘道器來替我們傳遞呼叫。

如何發現這個閘道器

為了充分利用dubbo介面的註冊發現機制，筆者將隧道閘道器也暴露為一個dubbo介面，其輸入和輸出分別如下所示:

// 隧道閘道器介面請求體
class TunnelInterfaceReq {
	// dubbo元資訊，例如具體呼叫介面資訊
	MetaData dubbo
	// 原始請求A呼叫序列化後的位元流
	byte[] body;
}
// 隧道閘道器介面返回體
class TunnelInterfaceResp{
	// dubbo元資訊
	MetaData dubbo
	// 返回值呼叫序列化後的位元流，由另一個叢集的對應系統返回
	byte[] resp;
}

有了這個dubbo介面，我們就可以很容易的將資料傳送給預設閘道器了。

注意，這裡其實也是做了一層隧道協議，即用dubbo協議承載dubbo協議，用這種類似套娃的方法有效的利用了dubbo本身的註冊發現機制。

閘道器和閘道器之間通過http通訊

由於不同叢集之間通過專線進行通訊，所以筆者採用了http通訊來進行。在App1的請求到達隧道閘道器後，閘道器會將原始body位元流從TunnelInterfaceRequest中取出。然後放到一個http的請求中進行傳遞。如下圖所示:

值得注意的是，由於傳遞的是byte流，沒有攜帶任何業務資訊(例如型別資訊等),所以我們的隧道閘道器可以對任意dubbo請求進行隧道傳輸，而不像傳統的閘道器那樣需要新增各種業務對應的jar包並不停釋出-_-!
在圖中，投遞到另一端的隧道閘道器後，其從http協議中取出呼叫元資訊和原始呼叫byte流，通過呼叫元資訊找到App2。然後給App2重放byte流，這樣就可以進行dubbo呼叫了。事實上，App2從隧道閘道器看到的byte流和從叢集內其它機器呼叫的byte流完全一致。如下圖所示:

返回值也通過隧道機制

很明顯的，我們的返回值也需要通過隧道機制。和Request一樣，其也會走兩次隧道協議，如下圖所示:

那麼App1真正接收到的其實是Tunnel Response,怎麼讓其透明的接收原始response位元流呢？這就需要呼叫方接入筆者研發的輕量級jar包(其實，一開始的request的隧道也需要這樣的jar包)