前言

---

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

訂單服務調用商品服務

上圖簡單的描述了RPC在實際場景中的應用，我們在開發中當然是利用現有的RPC框架來快速實現業務需求，比如百度開源了baidu-rpc，阿里的Dubbo早已聲名在外，騰訊自己玩TAF。本篇博客將實現一個迷你版的RPC，探索下RPC底層實現的奧秘！

?

動手實現RPC商品服務工程

---

商品服務工程

商品服務工程

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

商品對象

商品API

?

Product

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

很顯然，訂單系統調用商品系統的時候，需要商品系統返回一個商品，必然涉及到發生網絡傳輸，這就涉及對象的序列化和反序列化了。

商品查詢API接口

商品查詢API

?

訂單系統調用商品服務

訂單服務調用商品服務

在訂單系統工程中需要引入商品服務API依賴。

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

rpc實現方法

rpc

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

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

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

我們知道訂單系統就是想調用商品服務的某個類的某個方法，然后把這個方法的返回結果傳輸給訂單系統！

想一想，如何調用某個類的某個方法呢？

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

商品服務調用后得到的結果，我們序列化寫入Socket流中，在訂單系統中反序列化得到對象即可。

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

商品API的具體實現

商品服務 商品服務API實現

商品服務

商品服務

從這里，可以清晰的看到，商品服務讀取了訂單系統調用商品系統時發送的數據，利用反射機制，進行方法調用，并把調用結果寫入Socket輸出流。

運行結果

運行結果

啟動商品服務后，通過訂單系統發起對商品服務的調用。

?

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

晚安！

?

手寫系列相關爆文

---

【手寫系列】寫出我的第一個框架：迷你版Spring MVC

【手寫系列】透徹理解Spring事務設計思想之手寫實現

【手寫系列】透徹理解MyBatis設計思想之手寫實現

【手寫系列】理解數據庫連接池底層原理之手寫實現

【手寫系列】對HashMap的思考及手寫實現

【手寫系列】純手寫實現JDK動態代理

【手寫系列】寫一個迷你版的Tomcat

總結

以上是生活随笔為你收集整理的【手写系列】纯手写实现一个高可用的RPC的全部內容，希望文章能夠幫你解決所遇到的問題。

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