手寫RPC框架，我學會了什麼？（三）
這一系列的小文章要暫時告一段落了，這一篇會挖很多坑，留著以後慢慢填。
（前面的兩篇請直接拉到最後的傳送門。）
到目前為止也沒有貼程式碼，主要是因為單純用最簡單的實現，網上隨便一搜一大吧。我也只是在Java實現簡單的RPC框架 的基礎上做了一些小改進。
比如在部落格中，每一次請求會生成一個新的介面實現類：
Object result = method.invoke(serviceClass.newInstance(), arguments);
我覺得完全可以把實現類快取起來，減小記憶體的開銷；再比如把服務提供方和消費方分開實現在兩個不同的子工程，和諸如此類。
因此程式碼本身並不是重點，重點在於對原理的理解和概念的理解，當你真正理解概念之後，就不再會問出：
客戶端register這邊你能拿到HelloServiceImpl.class嗎？應該不行吧？
這樣的問題，因為第一篇 已經說了，客戶端拿到的只是一個動態代理生成的“傀儡”。也不再會問出：
我想知道，客戶端是怎麼有HelloService.class這個類的呢。
知道一個“HelloService”（字串）就可以了吧？
這樣的問題，因為第二篇 也說過，服務介面需要以jar包的形式釋出出去。
（畫外音，這個問題本身很好，因為我自己的實現就是通過字串的形式傳遞的，跟某框架更像一點）。
之前一直信奉的箴言 **Talk is cheap, show me the code. ** 近些年來有些動搖，因為感覺talk跟code一樣重要，有些概念不梳理清楚程式碼本身一定會很混亂。而梳理概念最簡單的做法，就是不停的跟別人說，說，說。
當然，看別人的部落格一萬遍，也代替不了把這些概念自己實現出來，當然未必真的要從0開始，適當的站在別人打好的基礎上先快速實現一個原型，再不停的迭代改進，也不失為一個好的原則。
既然說了是“原型”，就一定有很多可以值得大刀闊斧的砍掉重寫的地方，比如：
- 採用基於Google protobuf的序列化機制，其實幾年前就對它有所耳聞，也一直沒有機會試一試。
- 採用Netty，這個也不多說了，一直沒有用它開發過東西，說起來覺得挺丟人的。
- 引入獨立的配置中心，現在的實現只是點對點的，要完成叢集式的呼叫，還缺少服務發現這一環。
- 接上一條，負載均衡策略也不得不考慮，服務釋出者怎麼實現平滑重啟。
- 目前的實現入侵性太重，更優雅的實現基於AOP通過類似：
@ServiceConsumer()
的方式一行搞定。那麼是不是可以再實現一個boot-starter呢？
感覺坑已經多到可以出個年度連載了，那麼就留待以後一個個，慢慢填 。
（技術上我是個慢性子，雖然可能幾個月後再來寫一篇，但是，每個坑我一定會填上！）