1.dubbo中zookeeper做註冊中心，如果註冊中心集群全都掛掉，發布者和訂閱者之間還能通訊麼？
可以的。
啟動dubbo時，消費者會從zk拉取註冊的生產者的位址介面等資料，快取在本地。每次呼叫時，按照本地儲存的位址進行呼叫。但是在註冊中心全部掛掉後增加新的提供者，則不能被消費者發現。
所以消費者本地有乙個生產者的列表，他會按照列表繼續工作，倒是無法從註冊中心去同步最新的服務列表，短時間內註冊中心掛掉是不要緊的，但一定要盡快修復。
健壯性監控中心宕掉不影響使用，只是丟失部分取樣資料
資料庫宕掉後，註冊中心仍能通過快取提供服務列表查詢，但不能註冊新服務
註冊中心對等集群，任意一台宕掉後，將自動切換到另一台
註冊中心全部宕掉後，服務提供者和服務消費者仍能通過本地快取通訊
服務提供者無狀態，任意一台宕掉後，不影響使用
服務提供者全部宕掉後，服務消費者應用將無法使用，並無限次重連等待服務提供者恢復
2.dubbo連線註冊中心和直連的區別
在開發及測試環境下，經常需要繞過註冊中心，只測試指定服務提供者，這時候可能需要點對點直連，點對點直聯方式，將以服務介面為單位，忽略註冊中心的提供者列表。
服務註冊中心，動態的註冊和發現服務，使服務的位置透明，並通過在消費方獲取服務提供方位址列表，實現軟負載均衡和failover， 註冊中心返回服務提供者位址列表給消費者，如果有變更，註冊中心將基於長連線推送變更資料給消費者。
服務消費者，從提供者位址列表中，基於軟負載均衡演算法，選一台提供者進行呼叫，如果呼叫失敗，再選另一台呼叫。註冊中心負責服務位址的註冊與查詢，相當於目錄服務，服務提供者和消費者只在啟動時與註冊中心互動，註冊中心不**請求，服務消費者向註冊中心獲取服務提供者位址列表，並根據負載演算法直接呼叫提供者，註冊中心，服務提供者，服務消費者三者之間均為長連線，監控中心除外，註冊中心通過長連線感知服務提供者的存在，服務提供者宕機，註冊中心將立即推送事件通知消費者。
註冊中心和監控中心全部宕機，不影響已執行的提供者和消費者，消費者在本地快取了提供者列表。
註冊中心和監控中心都是可選的，服務消費者可以直連服務提供者。
3.dubbo在安全機制方面是如何解決的
dubbo通過token令牌防止使用者繞過註冊中心直連，然後在註冊中心上管理授權。dubbo還提供服務黑白名單，來控**務所允許的呼叫方。
4.dubbo 在執行時，乙個新的提供者服務啟動，消費者是如何感知的
無法感知
當新的提供者啟動的時候，會去註冊中心註冊，但是 消費者用不用不一定。
註冊中心有以下兩個基本職責：
服務位址註冊，服務提供者主要把服務位址註冊到位址中心。在註冊中心聚合了服務提供者的位址列表。能夠提供給服務呼叫者使用。
服務位址發現，註冊中心需要為服務呼叫者提供，服務提供者的位址。並且能夠感知到服務提供者的變化，並及時的更新位址列表，並通知給呼叫者。
註冊中心感知服務上線，在服務提供者時，會主動的通知給註冊中心。在註冊中心拿到新的服務位址之後，會通知給呼叫者客戶端。
服務下線有兩種情況，一種是主動下線，另一種是心跳包檢測服務下線。主動下線的操作比較可靠。心跳包檢測到服務下線就有可能產生誤判。有以下兩種情況：
當註冊中心的負載比較高時，服務提供者的心跳包來不及處理，就誤認為服務已下線。並且通知給服務的呼叫者。導致本可以使用的服務，變成不可用。
註冊中心和服務提供者的網路斷了，這樣導致註冊中心產生誤判。
出處：
Dubbo簡單介紹及其和zookeeper的關係
dubbox 是乙個分布式服務框架，其前身是阿里巴巴開源專案dubbo 被國內電商及網際網路專案中使用，後期阿里巴巴停止了該項目的維護，當當網便在dubbo基礎上進行優化，並繼續維護，為了與原有的dubbo區分，故將其命名為dubbox。dubbox 致力於提供高效能和透明化的rpc遠端服務呼叫方案...
Dubbo整合步驟
dubbo協議實現與webservice一樣的效果，用於服務呼叫之間的介面。dubbo可在中間實現真正意義上的中間呼叫管理，是乙個中間管理系統。demo 同步服務端統一試用dubbo服務端整合到業務系統。目前的場景試用的是dubbo協議。1 加入dubbo jar包 附件2.4.10 jar.zip...
springBoot整合dubbo整合專案
傳統spring 整合dubbo，需要繁瑣的編寫一堆堆的 xml 配置檔案 而springboot整合dubbo後，不在需要寫 xml,通過jar包引用，完 成整合，通過註解的形式完成配置。提高我們的開發效率 目錄結構 1 服務層生產者開發 hs ldm server service 1.1新增du...