說一下Dubbo 的工做原理？註冊中心掛了能夠繼續通訊嗎？

面試題

說一下的 dubbo 的工做原理？註冊中心掛了能夠繼續通訊嗎？說說一次 rpc 請求的流程？

面試官心理分析

MQ、ES、Redis、Dubbo，上來先問你一些思考性的問題、原理，好比 kafka 高可用架構原理、es 分佈式架構原理、redis 線程模型原理、Dubbo 工做原理；以後就是生產環境裏可能會碰到的一些問題，由於每種技術引入以後生產環境均可能會碰到一些問題；再來點綜合的，就是系統設計，好比讓你設計一個 MQ、設計一個搜索引擎、設計一個緩存、設計一個 rpc 框架等等。

那既然開始聊分佈式系統了，天然重點先聊聊 dubbo 了，畢竟 dubbo 是目前事實上大部分公司的分佈式系統的 rpc 框架標準，基於 dubbo 也能夠構建一整套的微服務架構。可是須要本身大量開發。

固然去年開始 spring cloud 很是火，如今大量的公司開始轉向 spring cloud 了，spring cloud 人家畢竟是微服務架構的全家桶式的這麼一個東西。可是由於不少公司還在用 dubbo，因此 dubbo 確定會是目前面試的重點，況且人家 dubbo 如今重啓開源社區維護了，捐獻給了 apache，將來應該也仍是有必定市場和地位的。

既然聊 dubbo，那確定是先從 dubbo 原理開始聊了，你先說說 dubbo 支撐 rpc 分佈式調用的架構啥的，而後說說一次 rpc 請求 dubbo 是怎麼給你完成的，對吧。

面試題剖析

dubbo 工做原理

• 第一層：service 層，接口層，給服務提供者和消費者來實現的
• 第二層：config 層，配置層，主要是對 dubbo 進行各類配置的
• 第三層：proxy 層，服務代理層，不管是 consumer 仍是 provider，dubbo 都會給你生成代理，代理之間進行網絡通訊
• 第四層：registry 層，服務註冊層，負責服務的註冊與發現
• 第五層：cluster 層，集羣層，封裝多個服務提供者的路由以及負載均衡，將多個實例組合成一個服務
• 第六層：monitor 層，監控層，對 rpc 接口的調用次數和調用時間進行監控
• 第七層：protocal 層，遠程調用層，封裝 rpc 調用
• 第八層：exchange 層，信息交換層，封裝請求響應模式，同步轉異步
• 第九層：transport 層，網絡傳輸層，抽象 mina 和 netty 爲統一接口
• 第十層：serialize 層，數據序列化層

工做流程

• 第一步：provider 向註冊中心去註冊
• 第二步：consumer 從註冊中心訂閱服務，註冊中心會通知 consumer 註冊好的服務
• 第三步：consumer 調用 provider
• 第四步：consumer 和 provider 都異步通知監控中心

註冊中心掛了能夠繼續通訊嗎？

能夠，由於剛開始初始化的時候，消費者會將提供者的地址等信息拉取到本地緩存，因此註冊中心掛了能夠繼續通訊。

免費Java資料須要本身領取，涵蓋了Java、Redis、MongoDB、MySQL、Zookeeper、Spring Cloud、Dubbo高併發分佈式等教程，一共30G。 
傳送門： https://mp.weixin.qq.com/s/JzddfH-7yNudmkjT0IRL8Q