cubelink概要設(shè)計

[TOC]

1. 撰寫記錄

更新時間

內(nèi)容

作者

2017-08-23 08:39:31

撰寫參數(shù)回調(diào)章節(jié)內(nèi)容

林斌

2017-08-22 21:26:52

增加了異步響應(yīng)和異步回調(diào)章節(jié)

林斌

2017-08-22 14:36:36

確定文檔結(jié)構(gòu)和大致框架

林斌

2. 設(shè)計目標

設(shè)計一個具備治理，監(jiān)控，服務(wù)發(fā)現(xiàn)能力的RPC框架

框架支持同步、異步調(diào)用；支持回調(diào)

3. 架構(gòu)設(shè)計

3.1 注冊、發(fā)現(xiàn)

大體上來說是依靠注冊中心實現(xiàn)注冊和發(fā)現(xiàn)機制。架構(gòu)如下

鏈接均采用長連接方式。注冊中心會監(jiān)控服務(wù)端的健康狀態(tài)。并且在發(fā)生變化時，實時推送實例狀態(tài)到客戶端。

3.2 客戶端架構(gòu)

客戶端的主要架構(gòu)如下

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

3.3 服務(wù)端架構(gòu)

服務(wù)端主要架構(gòu)如下

4. 技術(shù)要點

4.1 服務(wù)端注冊服務(wù)方式

從服務(wù)端的實現(xiàn)角度來說，

4.1 接口定位

服務(wù)端可以在一個監(jiān)聽端口上暴露多個接口服務(wù)。那么調(diào)用的時候首先需要明確的就是調(diào)用的哪一個接口。

4.2 方法定位

客戶端使用接口調(diào)用，如何在服務(wù)端這一側(cè)定位對應(yīng)的調(diào)用方法。為了節(jié)省傳輸數(shù)據(jù)，客戶端和服務(wù)端可以通過一種方式約定每一個方法的數(shù)字序號。這樣只需要傳遞數(shù)字序號即可定位調(diào)用的方法。

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

4.3 多線程共享TCP通道

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

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

服務(wù)端處理完業(yè)務(wù)請求后將響應(yīng)和序號一起發(fā)回

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

4.4 異步響應(yīng)

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

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

// 此調(diào)用會立即返回null

fooService.findFoo(fooId);

// 拿到調(diào)用的Future引用，當(dāng)結(jié)果返回后，會被通知和設(shè)置到此Future。

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

4.4 參數(shù)回調(diào)

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

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

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。