Dubbo 面試題整理：

https://blog.csdn.net/Soinice/article/details/83858764

下面我為大家準備了一些 Dubbo 整合 Zookeeper 常見的的面試題，一些是我經常問別人的，一些是我過去面試遇到的一些問題，總結給大家，希望對大家能有所幫助。

1.Dubbo中zookeeper做註冊中心，如果註冊中心叢集全都掛掉，釋出者和訂閱者之間還能通訊麼？

可以的。

啟動dubbo時，消費者會從zk拉取註冊的生產者的地址介面等資料，快取在本地。每次呼叫時，按照本地儲存的地址進行呼叫。但是在註冊中心全部掛掉後增加新的提供者，則不能被消費者發現。

所以消費者本地有一個生產者的列表，他會按照列表繼續工作，倒是無法從註冊中心去同步最新的服務列表，短時間內註冊中心掛掉是不要緊的，但一定要儘快修復。

健壯性

• 監控中心宕掉不影響使用，只是丟失部分取樣資料
• 資料庫宕掉後，註冊中心仍能通過快取提供服務列表查詢，但不能註冊新服務
• 註冊中心對等叢集，任意一臺宕掉後，將自動切換到另一臺
• 註冊中心全部宕掉後，服務提供者和服務消費者仍能通過本地快取通訊
• 服務提供者無狀態，任意一臺宕掉後，不影響使用
• 服務提供者全部宕掉後，服務消費者應用將無法使用，並無限次重連等待服務提供者恢復

2.Dubbo連線註冊中心和直連的區別

在開發及測試環境下，經常需要繞過註冊中心，只測試指定服務提供者，這時候可能需要點對點直連，點對點直聯方式，將以服務介面為單位，忽略註冊中心的提供者列表。
服務註冊中心，動態的註冊和發現服務，使服務的位置透明，並通過在消費方獲取服務提供方地址列表，實現軟負載均衡和Failover， 註冊中心返回服務提供者地址列表給消費者，如果有變更，註冊中心將基於長連線推送變更資料給消費者。
服務消費者，從提供者地址列表中，基於軟負載均衡演算法，選一臺提供者進行呼叫，如果呼叫失敗，再選另一臺呼叫。註冊中心負責服務地址的註冊與查詢，相當於目錄服務，服務提供者和消費者只在啟動時與註冊中心互動，註冊中心不轉發請求，服務消費者向註冊中心獲取服務提供者地址列表，並根據負載演算法直接呼叫提供者，註冊中心，服務提供者，服務消費者三者之間均為長連線，監控中心除外，註冊中心通過長連線感知服務提供者的存在，服務提供者宕機，註冊中心將立即推送事件通知消費者。
註冊中心和監控中心全部宕機，不影響已執行的提供者和消費者，消費者在本地快取了提供者列表。
註冊中心和監控中心都是可選的，服務消費者可以直連服務提供者。

3.Dubbo在安全機制方面是如何解決的

Dubbo通過Token令牌防止使用者繞過註冊中心直連，然後在註冊中心上管理授權。Dubbo還提供服務黑白名單，來控制服務所允許的呼叫方。

4.Dubbo 在執行時，一個新的提供者服務啟動，消費者是如何感知的

服務地址發現，註冊中心需要為服務呼叫者提供服務提供者的地址。並且能夠感知到服務提供者的變化，並及時的更新地址列表，並通知給呼叫者。

註冊中心感知服務上線，在服務提供者時，會主動的通知給註冊中心。在註冊中心拿到新的服務地址之後，會通知給呼叫者客戶端。