手寫RPC框架，我都學會了什麼？（一）

摘要： 關於“動態代理”可能是一個被講爛了的詞，但無論是基於純原始碼分析的，還是基於純講故事的，看過的太多，記住的太少。直到我嘗試著手寫一個RPC框架時，不經意發現對它的理解又更深了一點。 RPC框架要完成的，是實現像呼叫本地方法一樣獲得遠端執行的結果。 IHelloService...

關於“動態代理”可能是一個被講爛了的詞，但無論是基於純原始碼分析的，還是基於純講故事的，看過的太多，記住的太少。直到我嘗試著手寫一個RPC框架時，不經意發現對它的理解又更深了一點。

RPC框架要完成的，是實現像呼叫本地方法一樣獲得遠端執行的結果。

IHelloService helloService = RpcClient.getRemoteInstanceProxy(IHelloService.class);
String msg = helloService.sayHi("world");
//- 返回：Hello, world!

實際上getRemoteInstanceProxy返回的是一個實現了IHelloService介面的“傀儡”例項：底層通過Socket通訊把方法名、引數等傳送給IHelloService真正的服務提供者（Server/Provider）。服務提供者得到結果後，再通過Socket把結果傳送給服務消費者（Client/Consumer）。

“傀儡”例項基於動態代理實現，無非是對Socket通訊進行了一層封裝。

代理模式分為靜態代理和動態代理。靜態代理在編譯時期產生.class，為IHelloService實現代理後，如果又有一個新介面，就必須再重新實現一次。對於框架來說顯然是不可接受的，因此引出了動態代理，在執行時通過反射生成介面的“傀儡”例項。