先上原理圖
-----Dubbo中的RPC實現原理源碼分析----
一、註冊與訂閱過程---都是和zk交互
在每個zk客戶端（生產者和消費者）啓動時，會調用zk註冊類的構造函數，初始化就監聽連接事件：
分爲註冊與訂閱兩種連接事件。
1）註冊----provider如何註冊服務到zookeeper；
加上註解後，啓動會從ServiceBean進入，仔細跟代碼，最後會走到創建zk持久節點和臨時節點的方法。節點創建會被zk客戶端監聽到。
調用鏈爲RegistryProtocol#doRefer–>RegistryProtocol#doRefer–>FailbackRegistry#register–>FailbackRegistry#doRegister–>ZookeeperRegistry#doRegister–>zkClient#create
同時，會把服務放進暴露的服務列表中
2）訂閱----consumer如何從zookeeper拉取provider信息；
消費者一樣，需要去zk上註冊節點，此爲訂閱。
調用鏈爲RegistryProtocol#doRefer–>RegistryProtocol#doRefer–>FailbackRegistry#register–>FailbackRegistry#doRegister–>ZookeeperRegistry#doRegister–>zkClient#create
二、rpc請求過程---異步+Netty長連接
異步：每個RPC請求線程A都有一個唯一的id，封裝在future對象中。
RPC請求的時候，會將此id也發送給provider，然後線程A會lock等待；
provider處理完請求後會將此id和返回結果一同返回給consumer；
consumer收到返回信息以後解析出id，找到對應的請求線程A，激活線程A，返回結果。
單一Netty長連接：上面的異步過程是每一個調用業務線程A，它們只進行到調用提供者時，就進入lock了。真正去調用提供者的是一個多個線程A共享的一個單一Netty長連接。Netty本身是異步的，只是通過監聽回調實現了同步。
客戶端接收到服務端的RPC調用響應，從底層到頂層依次是NettyClient獲取NettyServer的響應，NettyClient將響應向上傳遞給HeaderExchangeHandler的received方法：