實現(xiàn)一個迷你版的RPC

前言

在實際后臺服務(wù)開發(fā)中，比如訂單服務(wù)（開發(fā)者A負責(zé)）需要調(diào)用商品服務(wù)（開發(fā)者B負責(zé)），那么開發(fā)者B會和A約定調(diào)用API，以接口的形式提供給A。通常都是B把API上傳到Maven私服，然后B開始寫API的實現(xiàn)，A只需要引入API依賴進行開發(fā)即可。

動手實現(xiàn)RPC

商品服務(wù)工程

注意，我將商品服務(wù)的API以及實現(xiàn)分為Maven的2個模塊來開發(fā)。這里，我們想給定一個商品ID，查詢得到商品對象信息。

商品對象

要注意的是，Product是可以被序列化的，Why?

很顯然，訂單系統(tǒng)調(diào)用商品系統(tǒng)的時候，需要商品系統(tǒng)返回一個商品，必然涉及到發(fā)生網(wǎng)絡(luò)傳輸，這就涉及對象的序列化和反序列化了。

商品查詢API接口

訂單系統(tǒng)調(diào)用商品服務(wù)

在訂單系統(tǒng)工程中需要引入商品服務(wù)API依賴。

在上圖代碼中，最重要的就是rpc方法了！

rpc實現(xiàn)方法

第一，我們看到了Proxy.newProxyInstance，很顯然在進行動態(tài)代理。也即是說，在訂單服務(wù)調(diào)用商品服務(wù)的代碼中，我們先是通過動態(tài)代理返回一個代理的IProductService類型對象，這意味著當(dāng)代理對象調(diào)用queryById方法的時候，會自動調(diào)用invoke方法！

第二，我們看看invoke到底做了些什么？

它本質(zhì)上就是進行Socket通信，那么它需要傳遞什么信息給到商品服務(wù)呢？

我們知道訂單系統(tǒng)就是想調(diào)用商品服務(wù)的某個類的某個方法，然后把這個方法的返回結(jié)果傳輸給訂單系統(tǒng)！

想一想，如何調(diào)用某個類的某個方法呢？

只要我們能確定這個類的全限定類名、確定方法名、確定方法的參數(shù)類型，給定方法需要的具體參數(shù)，通過反射就能實現(xiàn)。

商品服務(wù)調(diào)用后得到的結(jié)果，我們序列化寫入Socket流中，在訂單系統(tǒng)中反序列化得到對象即可。

第三，這里需要思考一個問題：在訂單系統(tǒng)中我們只知道商品服務(wù)的API，并不知道這背后的API到底是如何實現(xiàn)的，所以我們需要有一個映射，就是商品服務(wù)的API到商品服務(wù)的實現(xiàn)的一個映射關(guān)系，其實這就是所謂的服務(wù)的注冊！

商品API的具體實現(xiàn)

商品服務(wù)

從這里，可以清晰的看到，商品服務(wù)讀取了訂單系統(tǒng)調(diào)用商品系統(tǒng)時發(fā)送的數(shù)據(jù)，利用反射機制，進行方法調(diào)用，并把調(diào)用結(jié)果寫入Socket輸出流。

運行結(jié)果

啟動商品服務(wù)后，通過訂單系統(tǒng)發(fā)起對商品服務(wù)的調(diào)用。

以前總認為RPC是遙不可及的，感覺是個很神奇的東西，實際上它的底層實現(xiàn)不就是這樣的么~