如何自己設計一個類似 Dubbo 的 RPC 框架？有什麼思路？
面試題
如何自己設計一個類似 Dubbo 的 RPC 框架？
面試官心理分析
說實話，就這問題，其實就跟問你如何自己設計一個 MQ 一樣的道理，就考兩個：
- 你有沒有對某個 rpc 框架原理有非常深入的理解。
- 你能不能從整體上來思考一下，如何設計一個 rpc 框架，考考你的系統設計能力。
面試題剖析
其實問到你這問題，你起碼不能認慫，因爲是知識的掃盲，那我不可能給你深入講解什麼 kafka 源碼剖析，dubbo 源碼剖析，何況我就算講了，你要真的消化理解和吸收，起碼個把月以後了。
所以我給大家一個建議，遇到這類問題，起碼從你瞭解的類似框架的原理入手，自己說說參照 dubbo 的原理，你來設計一下，舉個例子，dubbo 不是有那麼多分層麼？而且每個分層是幹啥的，你大概是不是知道？那就按照這個思路大致說一下吧，起碼你不能懵逼，要比那些上來就懵，啥也說不出來的人要好一些。
舉個栗子，我給大家說個最簡單的回答思路：
- 上來你的服務就得去註冊中心註冊吧，你是不是得有個註冊中心，保留各個服務的信心，可以用 zookeeper 來做，對吧。
- 然後你的消費者需要去註冊中心拿對應的服務信息吧，對吧，而且每個服務可能會存在於多臺機器上。
- 接着你就該發起一次請求了，咋發起？當然是基於動態代理了，你面向接口獲取到一個動態代理，這個動態代理就是接口在本地的一個代理，然後這個代理會找到服務對應的機器地址。
- 然後找哪個機器發送請求？那肯定得有個負載均衡算法了，比如最簡單的可以隨機輪詢是不是。
- 接着找到一臺機器，就可以跟它發送請求了，第一個問題咋發送？你可以說用 netty 了，nio 方式；第二個問題發送啥格式數據？你可以說用 hessian 序列化協議了，或者是別的，對吧。然後請求過去了。
- 服務器那邊一樣的，需要針對你自己的服務生成一個動態代理，監聽某個網絡端口了，然後代理你本地的服務代碼。接收到請求的時候，就調用對應的服務代碼，對吧。
這就是一個最最基本的 rpc 框架的思路，先不說你有多牛逼的技術功底，哪怕這個最簡單的思路你先給出來行不行？
來源:“創享視界”，創享視界(creativeview.cn)是一個帶動全民顛覆八小時工作制，通過投稿把自己的創意智慧變現的方式創造被動收入，從而實現財務自由的平臺。我們相信，創新思維不僅有助於打造更出色的產品，還可以讓世界變得更美好，讓人人受益。