29、dubbo的工作原理？註冊中心掛了可以繼續通訊嗎？
1、面試題
說一下的dubbo的工作原理？註冊中心掛了可以繼續通訊嗎？說說一次rpc請求的流程？
2、面試官心裡分析
MQ、ES、Redis、Dubbo，上來先問你一些思考的問題，原理（kafka高可用架構原理、es分散式架構原理、redis執行緒模型原理、Dubbo工作原理），生產環境裡可能會碰到的一些問題（每種技術引入之後生產環境都可能會碰到一些問題），系統設計（設計MQ，設計搜尋引擎，設計一個快取，設計rpc框架），
當然比如說，hard面試官，死扣，結合專案死扣細節，百度（深入底層，基礎性），阿里（結合專案死扣細節，扣很深的技術底層），小米（資料結構和演算法）。
那既然開始聊分散式系統了，自然重點先聊聊dubbo了，畢竟dubbo是目前事實上大部分公司的分散式系統的rpc框架標準，基於dubbo也可以構建一整套的微服務架構。但是需要自己大量開發。
當然去年開始spring cloud非常火，現在大量的公司開始轉向spring cloud了，spring cloud人家畢竟是微服務架構的全家桶式的這麼一個東西。但是因為很多公司還在用dubbo，所以dubbo肯定會是目前面試的重點，何況人家dubbo現在重啟開源社群維護了，未來應該也還是有一定市場和地位的。
既然聊dubbo，那肯定是先從dubbo原理開始聊了，你先說說dubbo支撐rpc分散式呼叫的架構是啥，然後說說一次rpc請求dubbo是怎麼給你完成的，對吧。
3、面試題剖析
（1）dubbo工作原理
第一層：service層，介面層，給服務提供者和消費者來實現的
第二層：config層，配置層，主要是對dubbo進行各種配置的
第三層：proxy層，服務代理層，透明生成客戶端的stub和服務單的skeleton
第四層：registry層，服務註冊層，負責服務的註冊與發現
第五層：cluster層，叢集層，封裝多個服務提供者的路由以及負載均衡，將多個例項組合成一個服務
第六層：monitor層，監控層，對rpc介面的呼叫次數和呼叫時間進行監控
第七層：protocol層，遠端呼叫層，封裝rpc呼叫
第八層：exchange層，資訊交換層，封裝請求響應模式，同步轉非同步
第九層：transport層，網路傳輸層，抽象mina和netty為統一介面
第十層：serialize層，資料序列化層
工作流程：
1）第一步，provider向註冊中心去註冊
2）第二步，consumer從註冊中心訂閱服務，註冊中心會通知consumer註冊好的服務
3）第三步，consumer呼叫provider
4）第四步，consumer和provider都非同步的通知監控中心
dubbo的工作原理.png
（2）註冊中心掛了可以繼續通訊嗎？
可以，因為剛開始初始化的時候，消費者會將提供者的地址等資訊拉取到本地快取，所以註冊中心掛了可以繼續通訊。