面試題：Dubbo中zookeeper做註冊中心，如果註冊中心叢集都掛掉，釋出者和訂閱者之間還能通訊麼？ 可以的，啟動dubbo時，消費者會從zk拉取註冊的生產者的地址介面等資料，快取在本地。每次呼叫時，按照本地儲存的地址進行呼叫 註冊中心對等叢集，任意一臺宕掉後，會自動切換到另一臺 註冊中心全部宕掉，服務提供者和消費者仍可以通過本地快取通訊 服務提供者無狀態，任一臺 宕機後，不影響使用 服務提供者全部宕機，服務消費者會無法使用，並無限次重連等待服務者恢復 2 dubbo連線註冊中心和直連的區別 在開發及測試環境下，經常需要繞過註冊中心，只測試指定服務提供者，這時候可能需要點對點直連， 點對點直聯方式，將以服務介面為單位，忽略註冊中心的提供者列表， 服務註冊中心，動態的註冊和發現服務，使服務的位置透明，並通過在消費方獲取服務提供方地址列表，實現軟負載均衡和Failover， 註冊中心返回服務提供者地址列表給消費者，如果有變更，註冊中心將基於長連線推送變更資料給消費者。 服務消費者，從提供者地址列表中，基於軟負載均衡演算法，選一臺提供者進行呼叫，如果呼叫失敗，再選另一臺呼叫。註冊中心負責服務地址的註冊與查詢，相當於目錄服務，服務提供者和消費者只在啟動時與註冊中心互動，註冊中心不轉發請求，服務消費者向註冊中心獲取服務提供者地址列表，並根據負載演算法直接呼叫提供者，註冊中心，服務提供者，服務消費者三者之間均為長連線，監控中心除外，註冊中心通過長連線感知服務提供者的存在，服務提供者宕機，註冊中心將立即推送事件通知消費者 註冊中心和監控中心全部宕機，不影響已執行的提供者和消費者，消費者在本地快取了提供者列表 註冊中心和監控中心都是可選的，服務消費者可以直連服務提供者 3、Dubbo在安全機制方面是如何解決的 Dubbo通過Token令牌防止使用者繞過註冊中心直連，然後在註冊中心上管理授權。Dubbo還提供服務黑白名單，來控制服務所允許的呼叫方。

什麼是RPC？ RPC（Remote Procedure Call）遠端過程呼叫。見名知意 - 從遠端主機呼叫一個過程/函式。  RPC的目標是：使得本程式呼叫其它遠端主機上的函式，好像呼叫本程式內的函式一樣簡單，並且遮蔽程式語言的差異性。  要實現上述目標首先是設計一種通訊協議，稱之為：RPC協議（Protocol） RPC協議不是一個具體的協議，而是一個型別名，代表一類協議，這類協議叫做RPC協議； RPC協議在TCP/UDP之上，廣義上可以跨越平臺、語言進行應用間通訊（說廣義是因為可以開發一個協議且不支援跨語言）； 為什麼要用RPC？  其實這是應用開發到一定的階段的強烈需求驅動的。 如果我們開發簡單的單一應用，邏輯簡單、使用者不多、流量不大，那我們用不著； 當我們的系統訪問量增大、業務增多時，我們會發現一臺單機執行此係統已經無法承受。此時，我們可以將業務拆分成幾個互不關聯的應用，分別部署在各自機器上，以劃清邏輯並減小壓力。此時，我們也可以不需要RPC，因為應用之間是互不關聯的。 當我們的業務越來越多、應用也越來越多時，自然的，我們會發現有些功能已經不能簡單劃分開來或者劃分不出來。此時，可以將公共業務邏輯抽離出來，將之組成獨立的服務Service應用 。而原有的、新增的應用都可以與那些獨立的Service應用 互動，以此來完成完整的業務功能。所以此時，我們急需一種高效的應用程式之間的通訊手段來完成這種需求，所以你看，RPC大顯身手的時候來了！ 其實#3描述的場景也是服務化 、微服務 和分散式系統架構 的基礎場景。即RPC框架就是實現以上結構的有力方式。 有哪些RPC？  有很多RPC框架：CORBAR、Thrift、Dubbo等等。基本上他們分為兩種類別： 一種是跨語言的； 一種是同語言的，如果你的分散式應用架構主體都是Java應用，顯然我們不應該使用跨語言的RPC來多一層中轉浪費效率。 就Java來說，我認為其本身API提供的RMI就是一種RPC協議，但是其畢竟太原始，需要自己去新增很多機制才能上生產環境。所以，今天介紹下我最近使用的Dubbo框架。 dubbo常用配置總結 1、關閉啟動時檢查  Dubbo預設會在啟動時檢查依賴的服務是否可用，不可用會丟擲異常，阻止Spring初始化完成。如果對有些服務不關心，或者出現了迴圈依賴，必須有一方先啟動時，可以關閉啟動時檢查。方式如下： <dubbo:reference interface="com.xxx.XxxService" check="false" /> 2、引用預設還是延遲初始化的，只有引用被注入到其它Bean，或者被getBean()獲取時，才會初始化。如果需要飢餓載入，即Dubbo啟動時就立即生成動態代理例項，則可以配置： <dubbo:reference interface="com.xx.XxxService" init="true" /> 3、給dubbo介面新增白名單——dubbo Filter的使用 4、有時候你的服務在本地開發測試時需要註冊到註冊中心，但又沒有完全做完的時候，如果就這樣註冊上去，其他消費者在呼叫該服務時，就會偶爾的呼叫到你本地的服務，這樣就報錯了。 <dubbo:registry protocol="zookeeper" address="${dubbo.registry.address}" register="false"/>  在<dubbo:registry >最後新增register="false",這樣別人就不會調你的本地服務，但你的本地服務所訂閱的服務正常執行。 5、直連提供者 開發測試環境下，需要繞過註冊中心，直接測試服務提供者 <dubbo:reference interface="com.changhf.service.DeptmentService" id="deptmentService" check="false" url="dubbo://192.168.1.1:20881"/>  serviceImpl里加個斷點，每次訪問都會走斷點。在管控臺本地服務介面最後點選禁用，還是可以正常訪問，說明繞過了註冊中心。 6、服務分組，可實現服務的穩步升級 <dubbo:service interface="com.changhf.service.IDubboGroupService" ref="dubboGroup1Service" group="feedback2"/>  <dubbo:reference interface="com.changhf.service.IDu

group屬性為該服務介面新增一個分組，消費者就只會呼叫同一分組的服務介面了。 也可以用version屬性來替代： 　　<dubbo:service interface="com.changhf.service.DeptmentService" ref="deptmentService" version="2.0"/>  　　<dubbo:reference interface="com.changhf.service.DeptmentService" id="deptmentService" check="false" version="2.0"/>