一不小心實現了RPC

隨著最近關注 cim 專案的人越發增多，導致提的問題以及 bug 也在增加，在修復問題的過程中難免**潔癖又上來了。

看著一兩年前寫的東西總是懷疑這真的是出自自己手裡嘛？有些地方實在忍不住了便開始了漫漫重構之路。

在開始之前先簡單介紹一下cim這個專案，下面是它的架構圖：

簡單來說就是乙個 im 即時通訊系統，主要有以下部分組成：

當然服務端、路由都可以水平擴充套件。

這是乙個訊息傳送的流程圖，假設現在部署了兩個服務端 a、b 和乙個路由服務；其中clienta和clientb分別和服務端 a、b 保持了長連線。

當clienta向clientb傳送乙個hello world時，整個的訊息流轉如圖所示：

先通過http將訊息傳送到route服務。

路由服務得知clientb是連線在serverb上；於是再通過http將訊息傳送給serverb。

最終serverb將訊息通過與clientb的長連線通道push下去，至此訊息傳送成功。

這裡我擷取了clienta向route發起請求的**：

可以看到這就是利用okhttp發起了乙個http請求，這樣雖然能實現功能，但其實並不優雅。

舉個例子：假設我們需要對接支付寶的介面，這裡傳送乙個 http 請求自然是沒問題；但對於支付寶內部各部門直接互相呼叫介面時那就不應該再使用原始的 http 請求了。

應該是由服務提供方提供乙個api包，服務消費者只需要依賴這個包就可以實現介面呼叫。

當然最終使用的是 http、還是自定義私有協議都可以。

也類似於我們在使用dubbo或者是springcloud時，通常是直接依賴乙個api包，便可以像呼叫乙個本地方法一樣呼叫遠端服務了，並且完全遮蔽了底層細節，不管是使用的 http 還是其他私有協議都沒關係，對於呼叫者來說完全不關心。

這麼一說是不是有內味了，這不就是 rpc 的官方解釋嘛。

對應到這裡也是同樣的道理，client、route、server本質上都是乙個系統，他們互相的介面呼叫也應當是走rpc才合理。

所以我重構之後的變成這樣了：

是不是**也簡潔了許多，就和呼叫本地方法一樣了，而且這樣也有幾個好處：

下面來聊聊具體是如何實現的。

其實在上文《動態**的實際應用》中也有講到，原理是類似的。

要想做到對呼叫者無感知，就得建立乙個介面的**物件；在這個**物件中實現編碼、呼叫、解碼的過程。

對應到此處其實就是建立乙個routeapi的**物件，關鍵就是這段**：

routeapi routeapi = new proxymanager<>(routeapi.class, routeurl, okhttpclient).getinstance();

完整原始碼如下：

其中的getinstance()函式就是返回了需要被**的介面物件；而其中的proxyinvocation則是乙個實現了invocationhandler介面的類，這套**就是利用jdk實現動態**的三板斧。

檢視proxyinvocation的原始碼會發現當我們呼叫被**介面的任意乙個方法時，都會執行這裡的invoke()方法。

其實理解這些就也就很容易看懂dubbo這類rpc框架的核心原始碼了，總體的思路也是類似的，只不過使用的私有協議，所以在編譯碼時會有所不同。

所以大家要是想自己動手實現乙個rpc框架，不妨參考這個思路試試，當用自己寫的**跑通乙個rpc的helloworld時的感覺是和自己整合了乙個dubbo、springcloud這樣的第三方框架的感覺是完全不同的。

你的點讚與分享是對我最大的支援