1。
dubbo 工作原理
① service 層，介面層，給服務提供者和消費者來實現的
② config 層，配置層，主要是對 dubbo 進行各種配置的
③ proxy 層，服務代理層，無論是 consumer 還是 provider，dubbo 都會給你生成代理，代理之間進行網路通訊
④ registry 層，服務註冊層，負責服務的註冊與發現
⑤ cluster 層，叢集層，封裝多個服務提供者的路由以及負載均衡，將多個例項組合成一個服務
⑥ monitor 層，監控層，對 rpc 介面的呼叫次數和呼叫時間進行監控
⑦ protocal 層，遠端呼叫層，封裝 rpc 呼叫
⑧ exchange 層，資訊交換層，封裝請求響應模式，同步轉非同步
⑨ transport 層，網路傳輸層，抽象 mina 和 netty 為統一介面
⑩ serialize 層，資料序列化層
2。
工作流程
① 第一步：provider 向註冊中心去註冊
② consumer 從註冊中心訂閱服務，註冊中心會通知 consumer 註冊好的服務
③ consumer 呼叫 provider
④ consumer 和 provider 都非同步通知監控中心
3。
dubbo 支援不同的通訊協議
① dubbo 協議 預設就是走 dubbo 協議，單一長連線，進行的是 NIO 非同步通訊，基於 hessian 作為序列化協議。使用的場景是：傳輸資料量小（每次請求在 100kb 以內），但是併發量很高。
② rmi 協議 走 Java 二進位制序列化，多個短連線 適用於檔案的傳輸，一般較少用
③ hessian 協議 走 hessian 序列化協議，多個短連線，適用於提供者數量比消費者數量還多的情況，適用於檔案的傳輸，一般較少用。
④ http 協議 走表單序列化。
⑤ webservice 走 SOAP 文字序列化。
4。
dubbo 支援的序列化協議
dubbo 支援 hession、Java 二進位制序列化、json、SOAP 文字序列化多種序列化協議。但是hessian 是其預設的序列化協議。
Hessian 的物件序列化機制有 8 種原始型別：原始二進位制資料、boolean、64-bit date（64 位毫秒值的日期）、64-bit double、32-bit int、64-bit long、null、UTF-8 編碼的 string
另外還包括 3 種遞迴型別： list for lists and arrays 、map for maps and dictionaries、object for objects
還有一種特殊的型別：ref：用來表示對共享物件的引用。
5。
為什麼 PB 的效率是最高的？
其實 PB 之所以效能如此好，主要得益於兩個：第一，它使用 proto 編譯器，自動進行序列化和反序列化，速度非常快，應該比 XML 和 JSON 快上了 20~100 倍；第二，它的資料壓縮效果好，就是說它序列化後的資料量體積小。因為體積小，傳輸起來頻寬和速度上會有最佳化。
6。
dubbo 負載均衡策略
①RandomLoadBalance 預設 即隨機呼叫實現負載均衡
②RoundRobinLoadBalance 輪詢 均勻地將流量打到各個機器上去 可以設定權重
③LeastActiveLoadBalance 自動感知一下不活躍的效能差的機器更少的請求
④ConsistentHashLoadBalance 一致性 Hash 演算法，相同引數的請求一定分發到一個 provider 上去
7。
dubbo 叢集容錯策略
①Failover Cluster 模式 失敗自動切換，自動重試其他機器，預設就是這個 透過調節retries次數
②Failfast Cluster 模式 一次呼叫失敗就立即失敗常見於非冪等性的寫操作，比如新增一條記錄
③Failsafe Cluster 模式 出現異常時忽略掉，常用於不重要的介面呼叫，比如記錄日誌
④Failback Cluster模式 失敗了後臺自動記錄請求，然後定時重發，比較適合於寫訊息佇列這種。
⑤Forking Cluster 模式 並行呼叫多個 provider，只要一個成功就立即返回常用於實時性要求比較高的讀操作，但是會浪費更多的服務資源，可透過 forks=“2” 來設定最大並行數
⑥Broadcast Cluster 模式 逐個呼叫所有的 provider。任何一個 provider 出錯則報錯（從 2。1。0 版本開始支援）。通常用於通知所有提供者更新快取或日誌等本地資源資訊。
8。
dubbo 動態代理策略
預設使用 javassist 動態位元組碼生成，建立代理類。但是可以透過 spi 擴充套件機制配置自己的動態代理策略。
9。
如何自己設計一個類似 Dubbo 的 RPC 框架？
舉個栗子，我給大家說個最簡單的回答思路：
上來你的服務就得去註冊中心註冊吧，你是不是得有個註冊中心，保留各個服務的資訊，可以用 zookeeper 來做，對吧。
然後你的消費者需要去註冊中心拿對應的服務資訊吧，對吧，而且每個服務可能會存在於多臺機器上。
接著你就該發起一次請求了，咋發起？當然是基於動態代理了，你面向介面獲取到一個動態代理，這個動態代理就是介面在本地的一個代理，然後這個代理會找到服務對應的機器地址。
然後找哪個機器傳送請求？那肯定得有個負載均衡演算法了，比如最簡單的可以隨機輪詢是不是。
接著找到一臺機器，就可以跟它傳送請求了，第一個問題咋傳送？你可以說用 netty 了，nio 方式；第二個問題傳送啥格式資料？你可以說用 hessian 序列化協議了，或者是別的，對吧。然後請求過去了。
伺服器那邊一樣的，需要針對你自己的服務生成一個動態代理，監聽某個網路埠了，然後代理你本地的服務程式碼。接收到請求的時候，就呼叫對應的服務程式碼，對吧。
這就是一個最最基本的 rpc 框架的思路，先不說你有多牛逼的技術功底，哪怕這個最簡單的思路你先給出來行不行？
