為什么用微服務；
為什么zookeeper能作為注冊中心；
使用分布式碰到的bug，
zookeeper有集群嗎？怎么實現的；
zookeeper宕機還能訪問嗎；
服務失效踢出zookeeper中臨時節點的原理；
dubbo集群負載均衡策略
zookeeper持久化節點和臨時節點，注冊中心怎么與服務方保持心跳的
dubbo和springCloud區別，dubbo是做什么的。dubbo解決了什么難題，內部用了什么協議。
現在市面上比較成熟的分布式框架有兩種，要么采用dubbo，要么采用Spring cloud，至於他們兩個的區別，這個網上都有，主要的一點就是如果使用dubbo，像這些服務的降級限流熔斷，監控，鏈路跟蹤等等，只能說自己搞，dubbo沒有集成，阿里支付寶用的dubbo，淘寶用的Spring cloud
1 面試題：Dubbo中zookeeper做注冊中心，如果注冊中心集群都掛掉，發布者和訂閱者之間還能通信么？
可以的，啟動dubbo時，消費者會從zk拉取注冊的生產者的地址接口等數據，緩存在本地。每次調用時，按照本地存儲的地址進行調用
注冊中心對等集群，任意一台宕掉后，會自動切換到另一台
注冊中心全部宕掉，服務提供者和消費者仍可以通過本地緩存通訊
服務提供者無狀態，任一台 宕機后，不影響使用
服務提供者全部宕機，服務消費者會無法使用，並無限次重連等待服務者恢復
2 dubbo連接注冊中心和直連的區別
在開發及測試環境下，經常需要繞過注冊中心，只測試指定服務提供者，這時候可能需要點對點直連，
點對點直聯方式，將以服務接口為單位，忽略注冊中心的提供者列表，
服務注冊中心，動態的注冊和發現服務，使服務的位置透明，並通過在消費方獲取服務提供方地址列表，實現軟負載均衡和Failover， 注冊中心返回服務提供者地址列表給消費者，如果有變更，注冊中心將基於長連接推送變更數據給消費者。
服務消費者，從提供者地址列表中，基於軟負載均衡算法，選一台提供者進行調用，如果調用失敗，再選另一台調用。注冊中心負責服務地址的注冊與查找，相當於目錄服務，服務提供者和消費者只在啟動時與注冊中心交互，注冊中心不轉發請求，服務消費者向注冊中心獲取服務提供者地址列表，並根據負載算法直接調用提供者，注冊中心，服務提供者，服務消費者三者之間均為長連接，監控中心除外，注冊中心通過長連接感知服務提供者的存在，服務提供者宕機，注冊中心將立即推送事件通知消費者
注冊中心和監控中心全部宕機，不影響已運行的提供者和消費者，消費者在本地緩存了提供者列表
注冊中心和監控中心都是可選的，服務消費者可以直連服務提供者
3、Dubbo在安全機制方面是如何解決的
Dubbo通過Token令牌防止用戶繞過注冊中心直連，然后在注冊中心上管理授權。Dubbo還提供服務黑白名單，來控制服務所允許的調用方。
怎么進行服務注冊發現 zk實現具體說說
注冊，即將服務節點寫入到 ZooKeeper 中對應 app_id 和 cluster 的目錄下，寫入成功則視為服務啟動成功；發現，即通過 ZooKeeper 的 watch 原語監聽對方 app_id 和 cluster 之下的實例節點，發現更新則寫入到本地文件系統緩存，供客戶的的連接池取用。
原文：https://blog.csdn.net/luwei42768/article/details/54847427