實(shí)現(xiàn)RPC遠(yuǎn)程調(diào)用通信框架整體需要解決四個(gè)問題：
- 通信的框架
- 客戶端和服務(wù)端如何建立網(wǎng)絡(luò)連接？
- 服務(wù)端如何處理請求？
- 數(shù)據(jù)傳輸需要采用什么協(xié)議？
- 數(shù)據(jù)如何序列化和反序列化？
但是實(shí)現(xiàn)RPC調(diào)用還需要解決
- 服務(wù)描述，即數(shù)據(jù)構(gòu)造成的樣子
1.客戶端和服務(wù)端如何建立網(wǎng)絡(luò)連接
現(xiàn)在的通信一般都是基于TCP協(xié)議簡歷的網(wǎng)絡(luò)連接。
- HTTP通信，默認(rèn)使用HTTP協(xié)議
- Socket 通信
2.服務(wù)端如何處理請求？
BIO(同步阻塞方式)
每個(gè)請求都需要新開線程去處理，如果達(dá)到os最大的線程數(shù)瓶頸，新來的請求沒有辦法處理
- 適合連接數(shù)少
NIO（同步非阻塞方式），服務(wù)器端優(yōu)化
通過I/O多路復(fù)用技術(shù)，單線程的情況下可以同時(shí)處理多個(gè)客戶端請求，這種開銷小，節(jié)省os開銷。
- 適合連接數(shù)多，請求耗時(shí)比較輕的業(yè)務(wù)場景
AIO（異步非阻塞方式），客戶端優(yōu)化
客戶端只需要發(fā)起一個(gè)I/O操作然后立即返回，等I/O操作真正完成之后，客戶端會得到I/O操作完成的通知，此時(shí)客戶端只需要對數(shù)據(jù)進(jìn)行處理就好了，不需要進(jìn)行實(shí)際的I/O讀寫操作，真正的I/O讀寫操作已經(jīng)由內(nèi)核完成，這種方式的優(yōu)勢客戶端無需等待，不存在阻塞等待問題。
- 適合連接數(shù)多，請求耗時(shí)比較重的業(yè)務(wù)場景
3.數(shù)據(jù)傳輸需要采用什么協(xié)議？
因?yàn)楝F(xiàn)在的通信都是基于TCP協(xié)議，但是TCP是面向字節(jié)流的，無邊界。所以會產(chǎn)生粘包和半包問題，具體可以查看點(diǎn)擊
除了公有協(xié)議的Http協(xié)議等，現(xiàn)在更多的RPC框架都自定義私有協(xié)議。
- 協(xié)議重點(diǎn)就是：協(xié)議頭里需要包含數(shù)據(jù)包的字節(jié)數(shù)
4.數(shù)據(jù)該如何序列化和反序列化？
字節(jié)數(shù)組<->java Object
如何選擇,考慮維度？
- 空間大?。ǜ鶕?jù)數(shù)據(jù)量變）
- 編解碼速度（根據(jù)數(shù)據(jù)量變）
- 可讀性
- 多語言支持
現(xiàn)在最火的就是json和pb。
案例
- 下面就有一個(gè)實(shí)現(xiàn)的RPC遠(yuǎn)程調(diào)用的實(shí)現(xiàn)
