如何科學的解釋RPC
說起RPC，就不能不提到分布式，這個促使RPC誕生的領域。
假設你有一個計算器接口，Calculator，以及它的實現類CalculatorImpl，那么在系統還是單體應用時，你要調用Calculator的add方法來執行一個加運算，直接new一個CalculatorImpl，然后調用add方法就行了，這其實就是非常普通的本地函數調用，因為在同一個地址空間，或者說在同一塊內存，所以通過方法棧和參數棧就可以實現。
現在，基於高性能和高可靠等因素的考慮，你決定將系統改造為分布式應用，將很多可以共享的功能都單獨拎出來，比如上面說到的計算器，你單獨把它放到一個服務里頭，讓別的服務去調用它。
這下問題來了，服務A里頭並沒有CalculatorImpl這個類，那它要怎樣調用服務B的CalculatorImpl的add方法呢？
有同學會說，可以模仿B/S架構的調用方式呀，在B服務暴露一個Restful接口，然后A服務通過調用這個Restful接口來間接調用CalculatorImpl的add方法。
很好，這已經很接近RPC了，不過如果是這樣，那每次調用時，是不是都需要寫一串發起http請求的代碼呢？比如httpClient.sendRequest...之類的，能不能像本地調用一樣，去發起遠程調用，讓使用者感知不到遠程調用的過程呢，像這樣：
@Reference private Calculator calculator; ... calculator.add(1,2); ... 這時候，有同學就會說，用代理模式呀！而且最好是結合Spring IoC一起使用，通過Spring注入calculator對象，注入時，如果掃描到對象加了@Reference注解，那么就給它生成一個代理對象，將這個代理對象放進容器中。而這個代理對象的內部，就是通過httpClient來實現RPC遠程過程調用的。
可能上面這段描述比較抽象，不過這就是很多RPC框架要解決的問題和解決的思路，比如阿里的Dubbo。
總結一下，RPC要解決的兩個問題：
- 解決分布式系統中，服務之間的調用問題。
- 遠程調用時，要能夠像本地調用一樣方便，讓調用者感知不到遠程調用的邏輯。
如何實現一個RPC
實際情況下，RPC很少用到http協議來進行數據傳輸，畢竟我只是想傳輸一下數據而已，何必動用到一個文本傳輸的應用層協議呢，我為什么不直接使用二進制傳輸？比如直接用Java的Socket協議進行傳輸？
不管你用何種協議進行數據傳輸，一個完整的RPC過程，都可以用下面這張圖來描述：
以左邊的Client端為例，Application就是rpc的調用方，Client Stub就是我們上面說到的代理對象，也就是那個看起來像是Calculator的實現類，其實內部是通過rpc方式來進行遠程調用的代理對象，至於Client Run-time Library，則是實現遠程調用的工具包，比如jdk的Socket，最后通過底層網絡實現實現數據的傳輸。
這個過程中最重要的就是序列化和反序列化了，因為數據傳輸的數據包必須是二進制的，你直接丟一個Java對象過去，人家可不認識，你必須把Java對象序列化為二進制格式，傳給Server端，Server端接收到之后，再反序列化為Java對象。
下一次我也將通過代碼，給大家演示一下，如何實現一個簡單的RPC。
RPC vs Restful
其實這兩者並不是一個維度的概念，總得來說RPC涉及的維度更廣。
如果硬要比較，那么可以從RPC風格的url和Restful風格的url上進行比較。
比如你提供一個查詢訂單的接口，用RPC風格，你可能會這樣寫：
/queryOrder?orderId=123
用Restful風格呢？
Get
/order?orderId=123
RPC是面向過程，Restful是面向資源，並且使用了Http動詞。從這個維度上看，Restful風格的url在表述的精簡性、可讀性上都要更好。
RPC vs RMI
嚴格來說這兩者也不是一個維度的。
RMI是Java提供的一種訪問遠程對象的協議，是已經實現好了的，可以直接用了。
而RPC呢？人家只是一種編程模型，並沒有規定你具體要怎樣實現，你甚至都可以在你的RPC框架里面使用RMI來實現數據的傳輸，比如Dubbo：Dubbo - rmi協議
RPC沒那么簡單
要實現一個RPC不算難，難的是實現一個高性能高可靠的RPC框架。
比如，既然是分布式了，那么一個服務可能有多個實例，你在調用時，要如何獲取這些實例的地址呢？
這時候就需要一個服務注冊中心，比如在Dubbo里頭，就可以使用Zookeeper作為注冊中心，在調用時，從Zookeeper獲取服務的實例列表，再從中選擇一個進行調用。
那么選哪個調用好呢？這時候就需要負載均衡了，於是你又得考慮如何實現復雜均衡，比如Dubbo就提供了好幾種負載均衡策略。
這還沒完，總不能每次調用時都去注冊中心查詢實例列表吧，這樣效率多低呀，於是又有了緩存，有了緩存，就要考慮緩存的更新問題，blablabla......
你以為就這樣結束了，沒呢，還有這些：
- 客戶端總不能每次調用完都干等着服務端返回數據吧，於是就要支持異步調用；
- 服務端的接口修改了，老的接口還有人在用，怎么辦？總不能讓他們都改了吧？這就需要版本控制了；
- 服務端總不能每次接到請求都馬上啟動一個線程去處理吧？於是就需要線程池；
- 服務端關閉時，還沒處理完的請求怎么辦？是直接結束呢，還是等全部請求處理完再關閉呢？
- ......
如此種種，都是一個優秀的RPC框架需要考慮的問題。
當然，接下來我們還是先實現一個簡單的RPC，再在上面一步步優化！
作者：柳樹之
鏈接：https://www.jianshu.com/p/2accc2840a1b
來源：簡書
著作權歸作者所有。商業轉載請聯系作者獲得授權，非商業轉載請注明出處。