摘要：報(bào)文類(lèi)型對(duì)于框架來(lái)說(shuō)，報(bào)文可能有多種類(lèi)型心跳類(lèi)型報(bào)文認(rèn)證類(lèi)型報(bào)文請(qǐng)求類(lèi)型報(bào)文響應(yīng)類(lèi)型報(bào)文等。接口調(diào)用請(qǐng)求的發(fā)送，在多條連接之間進(jìn)行負(fù)載均衡。

RPC 全稱 Remote Procedure Call ，簡(jiǎn)單地來(lái)說(shuō)，它能讓使用者像調(diào)用本地方法一樣，調(diào)用遠(yuǎn)程的接口，而不需要關(guān)注底層的具體細(xì)節(jié)。

例如車(chē)輛違章代辦功能，如果車(chē)輛因?yàn)槟撤N原因違章，只需要通過(guò)這個(gè)違章代辦功能（它也許是個(gè)APP），我們就能動(dòng)動(dòng)手指，而省去了一些跑腿的工作。

不像微服務(wù)背景下大家所說(shuō)的 RPC 框架，如 Dubbo 之類(lèi)。這個(gè) RPC 框架不提供過(guò)多的關(guān)于服務(wù)注冊(cè)、服務(wù)發(fā)現(xiàn)、服務(wù)管理等功能。它針對(duì)的是這樣的一些場(chǎng)景：在內(nèi)部網(wǎng)絡(luò)，或者局域網(wǎng)內(nèi)，兩個(gè)屬于同個(gè)業(yè)務(wù)的系統(tǒng)之間需要通信，而我們又覺(jué)得去設(shè)計(jì)多一種二進(jìn)制網(wǎng)絡(luò)協(xié)議過(guò)于繁瑣并且沒(méi)有必要，這時(shí)候如果給客戶端開(kāi)發(fā)者一些明確的接口，讓他知道實(shí)現(xiàn)什么功能該調(diào)用什么接口，那么省去的工作量以及開(kāi)發(fā)效率上的提升不言而喻。

這個(gè) RPC 系統(tǒng)基于 Java 語(yǔ)言實(shí)現(xiàn)，需求如下：

RPC 服務(wù)端可以通過(guò)一條長(zhǎng)連接發(fā)布多個(gè)接口（Interface），客戶端按需生成對(duì)應(yīng)接口的代理。

RPC 客戶端也可以發(fā)布接口，以便在必要的時(shí)候，服務(wù)端可以主動(dòng)調(diào)用客戶端的接口實(shí)現(xiàn)

客戶端與服務(wù)端之間保持長(zhǎng)連接并且維持心跳

服務(wù)端針對(duì)不同的接口實(shí)現(xiàn)，可以指定不同的線程池去處理

序列化協(xié)議支持?jǐn)U展

通信協(xié)議與具體編程語(yǔ)言無(wú)關(guān)

支持并發(fā)調(diào)用，一個(gè)RPC客戶端實(shí)例要求是線程安全的

高效的通信協(xié)議一般是二進(jìn)制格式的，比較常見(jiàn)的還有文本協(xié)議比如說(shuō)HTTP，為了追求效率，這個(gè) RPC 框架就采用二進(jìn)制格式。

要了解到，報(bào)文是在網(wǎng)絡(luò)上傳輸?shù)?，安全性比較低，因此有必要采取一些措施使得并不是任何人都可以隨隨便便往我們的端口上發(fā)東西，因此我們對(duì)報(bào)文要有一個(gè)初步的識(shí)別功能，這時(shí)候“魔數(shù)(magic number)”就派上用場(chǎng)了。魔數(shù)并不受任何規(guī)范約束，沒(méi)有人可以要求你的魔數(shù)應(yīng)該遵循什么規(guī)范，實(shí)際上魔數(shù)只是我們通信雙方都約定的一個(gè)“暗號(hào)”，不知道這個(gè)暗號(hào)的人就無(wú)法參與進(jìn)通信中。例如 Java 源文件編譯后的 class 文件開(kāi)頭就有一個(gè)魔數(shù)：0xCAFEBABE，隨隨便便打開(kāi)一個(gè)class文件用十六進(jìn)制編輯器查看，就能看到。

Java 虛擬機(jī)加載 class 的時(shí)候會(huì)先驗(yàn)證魔數(shù)。如果不是 CAFEBABE 就認(rèn)為是不合法的 class 文件，并拒絕加載。

不過(guò)魔數(shù)起到的安全防范作用是非常有限的，“有心人”可以通過(guò)抓取網(wǎng)絡(luò)包就識(shí)別出魔數(shù)了。因此魔數(shù)這個(gè)東西其實(shí)是“防君子不防小人”。

一個(gè)協(xié)議可能也會(huì)有多個(gè)版本，例如說(shuō) HTTP1.0 和 HTTP1.1，不同版本的協(xié)議元素可能發(fā)生了改變，解析方式也會(huì)發(fā)生改變，因此協(xié)議設(shè)計(jì)這一塊，需要預(yù)留出地方聲明協(xié)議的版本，通信雙方在解析協(xié)議或者拼裝協(xié)議的時(shí)候才有跡可循。

對(duì)于RPC框架來(lái)說(shuō)，報(bào)文可能有多種類(lèi)型：心跳類(lèi)型報(bào)文、認(rèn)證類(lèi)型報(bào)文、請(qǐng)求類(lèi)型報(bào)文、響應(yīng)類(lèi)型報(bào)文等。

RPC 調(diào)用其實(shí)是一個(gè)“請(qǐng)求-響應(yīng)”的過(guò)程，并且跨物理機(jī)器，因此每次請(qǐng)求和響應(yīng)，都必須帶上上下文 ID，通信雙方才能把請(qǐng)求和響應(yīng)對(duì)應(yīng)起來(lái)。

狀態(tài)用來(lái)標(biāo)識(shí)一次調(diào)用時(shí)正常結(jié)束還是異常結(jié)束，通常由被調(diào)用方置狀態(tài)。

即發(fā)送到服務(wù)端的調(diào)用請(qǐng)求，通常是序列化后的二進(jìn)制流，長(zhǎng)度不定。

收?qǐng)?bào)文的一方怎么知道發(fā)報(bào)文的那一方發(fā)了多少字節(jié)呢？因此發(fā)送方必須在協(xié)議里告訴接收方需要接受多少字節(jié)才算一個(gè)完整的報(bào)文。

協(xié)議一旦被設(shè)計(jì)，并非一成不變的，日后可能有變動(dòng)的可能，因此還需要考慮保留一些字節(jié)空間作為保留字段，以備日后協(xié)議的擴(kuò)展。

結(jié)合以上的一些設(shè)計(jì)原則，具體協(xié)議設(shè)計(jì)如下：

 ------------------------------------------------------------------------
 | magic (2bytes) | version (1byte) |  type (1byte)  | reserved (7bits) | 
 ------------------------------------------------------------------------
 | status (1byte) |    id (8bytes)    |        body length (4bytes)     |
 ------------------------------------------------------------------------
 |                                                                      |
 |                   body ($body_length bytes)                          |
 |                                                                      |
 ------------------------------------------------------------------------

客戶端與服務(wù)端之間的連接采用 TCP 長(zhǎng)連接，一個(gè)客戶端與服務(wù)端之間保持至少一條長(zhǎng)連接。接口調(diào)用請(qǐng)求的發(fā)送，在多條連接之間進(jìn)行負(fù)載均衡。

每條連接在空閑的時(shí)候，由客戶端主動(dòng)向服務(wù)端發(fā)送心跳報(bào)文，并且客戶端在發(fā)現(xiàn)連接失效或斷開(kāi)的時(shí)候，自動(dòng)進(jìn)行重連。

每個(gè)客戶端向服務(wù)端建立連接后，在正式發(fā)起接口調(diào)用請(qǐng)求之前，都需要進(jìn)行check in 操作, check in 操作主要是將客戶端的身份標(biāo)識(shí)(identifier)和客戶端的心跳間隔告訴服務(wù)端。利用 netty 的 handler 責(zé)任鏈機(jī)制和自帶的 IdleStateHandler，自動(dòng)檢測(cè)出連接是否空閑，并在空閑時(shí)觸發(fā)心跳報(bào)文的發(fā)送。而服務(wù)端在客戶端 checkin 后，根據(jù)客戶端的心跳頻率，在自己的 handler pipeline 上動(dòng)態(tài)加入一個(gè) IdleStateHandler，來(lái)檢測(cè)出客戶端是否已經(jīng)失聯(lián)，如果是，則主動(dòng)關(guān)閉連接。

同時(shí)，客戶端本地將會(huì)起一個(gè)定時(shí)執(zhí)行任務(wù)的線程，定期檢查連接是否失效，如果失效，則關(guān)閉舊連接，并進(jìn)行連接的重建。