cubelink概要設計

[TOC]

1. 撰寫記錄

更新時間

內容

作者

2017-08-23 08:39:31

撰寫參數回調章節內容

林斌

2017-08-22 21:26:52

增加了異步響應和異步回調章節

林斌

2017-08-22 14:36:36

確定文檔結構和大致框架

林斌

2. 設計目標

設計一個具備治理，監控，服務發現能力的RPC框架

框架支持同步、異步調用；支持回調

3. 架構設計

3.1 注冊、發現

大體上來說是依靠注冊中心實現注冊和發現機制。架構如下

鏈接均采用長連接方式。注冊中心會監控服務端的健康狀態。并且在發生變化時，實時推送實例狀態到客戶端。

3.2 客戶端架構

客戶端的主要架構如下

TCP的雙工特點使得實際上客戶端的消息寫出和消息收取可以并行。但是由于大多數RPC調用是同步的，因為需要一個同步/異步轉換層在中間，滿足接口調用的特性。

3.3 服務端架構

服務端主要架構如下

4. 技術要點

4.1 服務端注冊服務方式

從服務端的實現角度來說，

4.1 接口定位

服務端可以在一個監聽端口上暴露多個接口服務。那么調用的時候首先需要明確的就是調用的哪一個接口。

4.2 方法定位

客戶端使用接口調用，如何在服務端這一側定位對應的調用方法。為了節省傳輸數據，客戶端和服務端可以通過一種方式約定每一個方法的數字序號。這樣只需要傳遞數字序號即可定位調用的方法。

排序方式的方式為方法的字符串簽名進行字母自然排序。序號從0開始遞增。

4.3 多線程共享TCP通道

多個線程如果需要共享TCP通道，那么就需要通過請求序號的方式來區別不同的線程收到的響應。具體做法如下

客戶端發出請求的報文中攜帶一個客戶端全局唯一的序號。

服務端處理完業務請求后將響應和序號一起發回

客戶端依靠響應中的序號將響應給予對應的等待線程(如果有的話)。

4.4 異步響應

底層的傳輸層框架本身就是支持異步的客戶端。因此異步響應的支持本身實際上只需要在底層客戶端的基礎之上，引入一個異步響應的future實現類即可。

異步響應本身不需要修改API，可以只是在客戶端配置該方法為異步響應。此時通過上下文之類的方式獲得一個響應的future。調用方式類似

// 此調用會立即返回null

fooService.findFoo(fooId);

// 拿到調用的Future引用，當結果返回后，會被通知和設置到此Future。

Future fooFuture = RpcContext.getContext().getFuture();

4.4 參數回調

參數回調的效果是讓客戶端傳遞了一個調用行為到服務端。而這個調用行為的效果是發生在客戶端本地的，所使用到的資源也在客戶端本地。比較容易實現而且也實踐較多的做法是定義一個只有一個方法且該方法沒有返回值的接口。

接著的問題就是如何傳遞這個接口的實現。上面說到這個回調行為是發生在客戶端本地的，因此傳遞一個接口的對象實現到服務端是沒有意義的。因此只需要傳遞一個代表這個回調接口的標識過去即可。

總結

以上是生活随笔為你收集整理的java dubbo jsf_cubelink的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。