1.什麼是RPC
RPC（Remote Procedure Call Protocol）遠程過程調用協議，它是一種通過網絡從遠程計算機程序上請求服務，而不需要了解底層網絡技術的協議。RPC協議假定某些傳輸協議的存在，如TCP或UDP，爲通信程序之間攜帶信息數據。在OSI網絡通信模型中，RPC跨越了傳輸層和應用層，RPC使得開發包括網絡分佈式多程序在內的應用程序更加容易。
RPC採用C/S模式，請求程序就是要給客戶機，而服務提供程序就是一個服務器。首先，客戶機調用進程發送一個有進程參數的調用信息到服務進程，然後等待應答信息。在服務端，進程保持睡眠狀態直到調用信息到達爲止。當一個調用信息到達，服務器獲得進程參數，計算結果，發送答覆信息。然後等待下一個調用信息，最後，客戶端調用進程接收答覆信息，獲得進程結果，然後調用執行繼續進行。
WebService和Socket都是一種RPC。
好了，上面這些當然不是我要說的重點，因爲百度一搜都能搜到，接下來我要通過一個案例來簡單明瞭的闡述一下rpc的工作原理，請大家耐着性子讀下去吧！
2.RPC框架設計思路
有這樣一段代碼:
@Autowired
OrderService os;
os.createOrder();
寫過spring的朋友看到這段都會想，這裏就是注入了一個service，然後調service的方法而已，很簡單。但是這是在service也在同一個服務器的前提下的。現在情況變了。我們的app開發和appservice開發在不同的服務器上，這時候如果app開發人員想這麼調用，那麼appservice的程序員就必須要在service上加@RpcService註解。那麼，這個註解是如何實現兩臺服務器遠程調用的呢。
我們知道，我們在啓動項目時，spring首先會掃描註解，這樣，所有的service服務只要加了@RpcService註解的都會被掃描到。這時我們需要一個HashMap來存儲接口名和對應的實現類對象obj。這時候spring會通過它的機制啓動服務器SocketService，它提供了一個接口接受app開發端發送過來的調用請求，這個請求包括需要調用的接口名，方法名以及參數名，SocketServer通過反射機制在HashMap中找到對應的實現類對象，然後將其返回給app開發端，app端就調用到了想要調用的接口。
我們在回到開頭，我們的app端實際上用到了動態代理。
proxy=Proxy.createProxy(classLoader.接口)，這時程序員寫的是OrderService類，所以proxy=OrderService;實際orderService.createOrder() 是 proxy.createOrder()。此時該方法會被invoke(proxy.method.args)阻塞,這時候我們已經拿到了接口,method和args，再將他們封裝成request請求放入socket中，由socket發送到socketServer中請求調用。
最後還有一個問題，就是在請求時app端是如何知道服務器的地址的？這時需要zookeeper，在appservice生成HashMap時將接口和服務器地址註冊到zookeeper中。客戶端在封裝request請求的時候只需要從zookeeper中根據接口名取服務器地址就可以了。
這就是RPC的原理，在上層（APP開發人員和APPService開發人員）看起來很簡單，只是一方寫業務，另一方寫Service並加上Rpc註解。但是在底層確有着龐大的工作量！
關於SocketServer，如果有傳統的socket，效率非常低，就會變成一個低性能服務器，因此需要引入netty（NIO）。（下回再談）