Github

1 面試題

如何設計一個類似Dubbo的RPC架構

就跟問你如何設計一個MQ一樣的道理，就考兩個:

其實一般問到你這問題，你起碼不能認慫，因為這既然是面試突擊教程，那不可能給你深入講解什麼kafka源碼剖析，dubbo源碼剖析，何況就算講了，你要真的消化了解和吸收，起碼個把月以後了!

是以我給大家一個建議，遇到這類問題，起碼從你了解的類似架構的原理入手，自己說說參照Dubbo的原理，你來設計一下，舉個例子，Dubbo不是有那麼多分層麼？而且每個分層是幹啥的，你大概是不是知道？那就按照這個思路大緻說一下吧，起碼你不能懵逼，要比那些上來就懵，啥也說不出來的人要好一些

給大家說個最簡單的回答思路

首先服務就得去注冊中心注冊吧，你是不是得有個注冊中心，保留各個服務的資訊，可以用zookeeper來做吧
然後你的消費者需要去注冊中心拿對應的服務資訊吧,而且每個服務可能會存在于多台機器上
接着你就該發起一次請求了，怎麼發起請求？懵逼了吧,當然是基于動态代理了!

你面向接口擷取到一個動态代理，這個動态代理就是接口在本地的一個代理，然後這個代理會找到服務對應的機器位址
然後找哪個機器發送請求？那肯定得有個負載均衡算法了，比如最簡單的可以随機輪詢是不是
找到一台機器後，就可以跟它發送請求了
- 咋發送呢？
  
  你可以說用netty了，nio方式
- 發送什麼格式的資料？
  
  你可以說用hessian序列化協定了，或者是别的，對吧。然後請求過去了
伺服器那邊一樣的，需要針對你自己的服務生成一個動态代理，監聽某個網絡端口，然後代理你本地的服務代碼。接收到請求的時候，就調用對應的服務代碼.

這就是一個最最基本的RPC架構的思路，先不說你有多牛逼的技術功底，哪怕這個最簡單的思路你先給出來行不行？好，突擊教程，那就到這兒結束了，這教程定位是幫你快速梳理一遍，掃清盲點，不是打通你任督二脈，給你九陽神功的!