1. Dubbo中zookeeper做註冊中心，如果註冊中心集羣都掛掉，發佈者和訂閱者之間還能通信麼？
可以通信的，啓動dubbo時，消費者會從zk拉取註冊的生產者的地址接口等數據，緩存在本地。每次調用時，按照本地存儲的地址進行調用；
註冊中心對等集羣，任意一臺宕機後，將會切換到另一臺；註冊中心全部宕機後，服務的提供者和消費者仍能通過本地緩存通訊。服務提供者無狀態，任一臺 宕機後，不影響使用；服務提供者全部宕機，服務消費者會無法使用，並無限次重連等待服務者恢復；
掛掉是不要緊的，但前提是你沒有增加新的服務，如果你要調用新的服務，則是不能辦到的。
2. dubbo服務負載均衡策略？
l Random LoadBalance
隨機，按權重設置隨機概率。在一個截面上碰撞的概率高，但調用量越大分佈越均勻，而且按概率使用權重後也比較均勻，有利於動態調整提供者權重。(權重可以在dubbo管控臺配置)
l RoundRobin LoadBalance
輪循，按公約後的權重設置輪循比率。存在慢的提供者累積請求問題，比如：第二臺機器很慢，但沒掛，當請求調到第二臺時就卡在那，久而久之，所有請求都卡在調到第二臺上。
l LeastActive LoadBalance
最少活躍調用數，相同活躍數的隨機，活躍數指調用前後計數差。使慢的提供者收到更少請求，因爲越慢的提供者的調用前後計數差會越大。
l ConsistentHash LoadBalance
一致性Hash，相同參數的請求總是發到同一提供者。當某一臺提供者掛時，原本發往該提供者的請求，基於虛擬節點，平攤到其它提供者，不會引起劇烈變動。缺省只對第一個參數Hash，如果要修改，請配置
[AppleScript]
|
1 |
<dubbo:parameter key="hash.arguments" value="0,1" /> |
缺省用160份虛擬節點，如果要修改，請配置
[AppleScript]
|
1 |
<dubbo:parameter key="hash.nodes" value="320" /> |
3. Dubbo在安全機制方面是如何解決的
Dubbo通過Token令牌防止用戶繞過註冊中心直連，然後在註冊中心上管理授權。Dubbo還提供服務黑白名單，來控制服務所允許的調用方。
4. dubbo連接註冊中心和直連的區別
在開發及測試環境下，經常需要繞過註冊中心，只測試指定服務提供者，這時候可能需要點對點直連，
點對點直聯方式，將以服務接口爲單位，忽略註冊中心的提供者列表，
服務註冊中心，動態的註冊和發現服務，使服務的位置透明，並通過在消費方獲取服務提供方地址列表，實現軟負載均衡和Failover， 註冊中心返回服務提供者地址列表給消費者，如果有變更，註冊中心將基於長連接推送變更數據給消費者。
服務消費者，從提供者地址列表中，基於軟負載均衡算法，選一臺提供者進行調用，如果調用失敗，再選另一臺調用。註冊中心負責服務地址的註冊與查找，相當於目錄服務，服務提供者和消費者只在啓動時與註冊中心交互，註冊中心不轉發請求，服務消費者向註冊中心獲取服務提供者地址列表，並根據負載算法直接調用提供者，註冊中心，服務提供者，服務消費者三者之間均爲長連接，監控中心除外，註冊中心通過長連接感知服務提供者的存在，服務提供者宕機，註冊中心將立即推送事件通知消費者
註冊中心和監控中心全部宕機，不影響已運行的提供者和消費者，消費者在本地緩存了提供者列表
註冊中心和監控中心都是可選的，服務消費者可以直連服務提供者。
1. dubbo服務集羣配置（集羣容錯模式）
在集羣調用失敗時，Dubbo 提供了多種容錯方案，缺省爲 failover 重試。可以自行擴展集羣容錯策略
l Failover Cluster(默認)
失敗自動切換，當出現失敗，重試其它服務器。(缺省)通常用於讀操作，但重試會帶來更長延遲。可通過retries="2"來設置重試次數(不含第一次)。
[AppleScript]
|
1 2 3 4 |
<dubbo:service retries="2" cluster="failover"/> 或： <dubbo:reference retries="2" cluster="failover"/> cluster="failover"可以不用寫,因爲默認就是failover |
l Failfast Cluster
快速失敗，只發起一次調用，失敗立即報錯。通常用於非冪等性的寫操作，比如新增記錄。
[AppleScript]
|
1 2 3 4 |
dubbo:service cluster="failfast" /> 或： <dubbo:reference cluster="failfast" /> cluster="failfast"和 把cluster="failover"、retries="0"是一樣的效果,retries="0"就是不重試 |
l Failsafe Cluster
失敗安全，出現異常時，直接忽略。通常用於寫入審計日誌等操作。
[AppleScript]
|
1 2 3 |
<dubbo:service cluster="failsafe" /> 或： <dubbo:reference cluster="failsafe" /> |
l Failback Cluster
失敗自動恢復，後臺記錄失敗請求，定時重發。通常用於消息通知操作。
[AppleScript]
|
1 2 3 |
<dubbo:service cluster="failback" /> 或： <dubbo:reference cluster="failback" /> |
l Forking Cluster
並行調用多個服務器，只要一個成功即返回。通常用於實時性要求較高的讀操作，但需要浪費更多服務資源。可通過forks="2"來設置最大並行數。
[AppleScript]
|
1 2 3 |
<dubbo:service cluster=“forking" forks="2"/> 或： <dubbo:reference cluster=“forking" forks="2"/> |
l 配置
[AppleScript]
|
1 2 3 4 5 6 |
服務端服務級別 <dubbo:service interface="..." loadbalance="roundrobin" /> 客戶端服務級別 <dubbo:reference interface="..." loadbalance="roundrobin" /> 服務端方法級別 <dubbo:service interface="..."> <dubbo:method name="..." loadbalance="roundrobin"/> </dubbo:service> 客戶端方法級別 <dubbo:reference interface="..."> <dubbo:method name="..." loadbalance="roundrobin"/> </dubbo:reference> |
1. dubbo通信協議dubbo協議爲什麼要消費者比提供者個數多：
因dubbo協議採用單一長連接，假設網絡爲千兆網卡(1024Mbit=128MByte)，
根據測試經驗數據每條連接最多隻能壓滿7MByte(不同的環境可能不一樣，供參考)，理論上1個服務提供者需要20個服務消費者才能壓滿網卡。
2. dubbo通信協議dubbo協議爲什麼不能傳大包：
因dubbo協議採用單一長連接，
如果每次請求的數據包大小爲500KByte，假設網絡爲千兆網卡(1024Mbit=128MByte)，每條連接最大7MByte(不同的環境可能不一樣，供參考)，
單個服務提供者的TPS(每秒處理事務數)最大爲：128MByte / 500KByte = 262。
單個消費者調用單個服務提供者的TPS(每秒處理事務數)最大爲：7MByte / 500KByte = 14。
如果能接受，可以考慮使用，否則網絡將成爲瓶頸。
3. dubbo通信協議dubbo協議爲什麼採用異步單一長連接：
因爲服務的現狀大都是服務提供者少，通常只有幾臺機器，
而服務的消費者多，可能整個網站都在訪問該服務，
比如Morgan的提供者只有6臺提供者，卻有上百臺消費者，每天有1.5億次調用，
如果採用常規的hessian服務，服務提供者很容易就被壓跨，
通過單一連接，保證單一消費者不會壓死提供者，
長連接，減少連接握手驗證等，
並使用異步IO，複用線程池，防止C10K問題。
4. dubbo通信協議dubbo協議適用範圍和適用場景
適用範圍：傳入傳出參數數據包較小（建議小於100K），消費者比提供者個數多，單一消費者無法壓滿提供者，儘量不要用dubbo協議傳輸大文件或超大字符串。
適用場景：常規遠程服務方法調用
dubbo協議補充：
連接個數：單連接
連接方式：長連接
傳輸協議：TCP
傳輸方式：NIO異步傳輸
序列化：Hessian二進制序列化
5. RMI協議
RMI協議採用JDK標準的java.rmi.*實現，採用阻塞式短連接和JDK標準序列化方式，Java標準的遠程調用協議。
連接個數：多連接
連接方式：短連接
傳輸協議：TCP
傳輸方式：同步傳輸
序列化：Java標準二進制序列化
適用範圍：傳入傳出參數數據包大小混合，消費者與提供者個數差不多，可傳文件。
適用場景：常規遠程服務方法調用，與原生RMI服務互操作
6. Hessian協議
Hessian協議用於集成Hessian的服務，Hessian底層採用Http通訊，採用Servlet暴露服務，Dubbo缺省內嵌Jetty作爲服務器實現
基於Hessian的遠程調用協議。
連接個數：多連接
連接方式：短連接
傳輸協議：HTTP
傳輸方式：同步傳輸
序列化：Hessian二進制序列化
適用範圍：傳入傳出參數數據包較大，提供者比消費者個數多，提供者壓力較大，可傳文件。
適用場景：頁面傳輸，文件傳輸，或與原生hessian服務互操作
7. http
採用Spring的HttpInvoker實現
基於http表單的遠程調用協議。
連接個數：多連接
連接方式：短連接
傳輸協議：HTTP
傳輸方式：同步傳輸
序列化：表單序列化（JSON）
適用範圍：傳入傳出參數數據包大小混合，提供者比消費者個數多，可用瀏覽器查看，可用表單或URL傳入參數，暫不支持傳文件。
適用場景：需同時給應用程序和瀏覽器JS使用的服務。
8. Webservice
基於CXF的frontend-simple和transports-http實現
基於WebService的遠程調用協議。
連接個數：多連接
連接方式：短連接
傳輸協議：HTTP
傳輸方式：同步傳輸
序列化：SOAP文本序列化
適用場景：系統集成，跨語言調用。
9. Thrif
Thrift是Facebook捐給Apache的一個RPC框架，當前 dubbo 支持的 thrift 協議是對 thrift 原生協議的擴展，在原生協議的基礎上添加了一些額外的頭信息，比如service name，magic number等
emmmm，還沒弄好，有什麼意見可以聯繫微信：下課鈴聲
