1.dubbo是什麼
dubbo是一個分佈式，高性能，透明化的RPC服務框架，提供服務自動註冊、自動發現等高效服務治理方案，可以和spring框架無縫集成。（RPC指的是遠程過程調用，也就是說兩個服務器交互數據）
2.dubbo主要應用場景
透明化的遠程方法調用，就像調用本地方法一樣調用遠程方法，只需簡單配置，沒有任何API侵入
軟負載均衡及容錯機制，可在內網替代F5等硬件負載均衡器，降低成本，減少單點
服務自動註冊與發現，不再需要寫死服務提供方地址，註冊中心基於接口名查詢服務提供者的IP地址，並且能夠平滑添加或者刪除服務提供者
3.dubbo的核心功能
- Remoting:網絡通信框架，提供對多種NIO框架抽象封裝，包括“同步轉異步”和“請求-響應”模式的信息交換方式。
- Cluster:服務框架，提供基於接口方法的透明遠程過程調用，包括多協議支持，以及負載均衡，失敗容錯，地址路由，動態配置等集羣支持。
- Registry:服務註冊，基於註冊中心目錄服務，使服務消費方能動態查找服務提供方，使地址透明，使服務提供方可以平滑增加或者減少機器。
4.dubbo的核心組件
- Provider:暴露服務的服務提供方
- Consumer：調用遠程服務的服務消費方
- Registry:服務註冊與發現的註冊中心
- Monitor:統計服務的調用次數和調用時間的監控中心
- Container：服務運行容器
5.dubbo的架構設計
dubbo框架設計一共劃分10層：
服務接口層（Service）:該層是與實際業務邏輯相關的，根據服務提供方和服務消費方的業務設計對應的接口和實現。
配置層（Config）:對外配置接口，以ServiceConfig和ReferenceConfig爲中心。
服務代理層（Proxy）:服務接口透明代理，生成服務的客戶端Stub和服務器端Skeleton。
服務註冊層（Registry）:封裝服務地址的註冊與發現，以服務URL爲中心。
集羣層（Cluster）:封裝多個提供者的路由及負載均衡，並橋接註冊中心，以Invoker爲中心。
遠程調用層（Protocol）:封裝RPC調用，以Invocation和Result爲中心，擴展接口爲Protocol、Invoker和Exporter。
信息交換層（Exchange）:封裝請求響應模式，同步轉異步，以Request和Response爲中心。
網絡傳輸層（Transport）:抽象mina和netty爲統一接口，以Message爲中心。
6.dubbo支持哪些協議，每種協議的應用場景
- dubbo:單一長連接和NIO異步通訊，適合大併發小數據量的服務調用，以及消費者遠大於提供者。傳輸協議TCP，異步，Hessian序列化；
- rmi:採用JDK標準的rmi協議實現，傳輸參數和返回參數對象需要實現Serializable接口，使用java標準序列化機制，使用阻塞式短連接，傳輸數據包大小混合，消費者和提供者個數差不多，可傳文件，傳輸協議TCP。多個短連接，TCP協議傳輸，同步傳輸，使用常規的遠程服務調用和rmi互操作。在依賴低版本的Common-Collections包，java序列化存在安全漏洞；
- webservice：基於WebService遠程調用協議，集成CXF實現，提供和原生WebService的互操作。多個短連接，基於HTTP傳輸，同步傳輸，適用系統集成和跨語言調用；
- http:基於HTTP表單提交的遠程調用協議，適用Spring的HttpInvoke實現，多個短連接，傳輸協議HTTP，傳入參數大小混合，提供者個數多餘消費者，需要給應用程序和瀏覽器JS調用；
- hessian:集成Hessian服務，基於HTTP通訊，採用Servlet暴露服務，Dubbo內嵌Jetty作爲服務器時默認實現，提供與Hession服務互操作。多個短連接，同步HTTP傳輸，Hessian序列化，傳入參數較大，提供者大於消費者，提供者壓力較大，可傳文件；
- memcache:基於memcached實現的RPC協議
- redis:基於redis實現的RPC協議
7.dubbo有哪些註冊中心
- Multicast註冊中心：Multicast註冊中心不需要任何中心節點，只要廣播地址，就能進行服務註冊和發現。基於網絡中組播傳輸實現；
- Zookeeper註冊中心：基於分佈式協調系統Zookeeper實現，採用Zookeeper的watch機制實現數據變更；
- redis註冊中心：基於redis實現，採用key/Map存儲，住key存儲服務名和類型，Map中key存儲服務URL，value服務過期時間。基於redis的發佈/訂閱模式通知數據變更；
- Simple註冊中心
8.dubbo集羣提供的負載均衡策略
- Random LoadBalance:隨機選取提供者策略，有利於動態調整提供者權重
- RoundRobin LoadBalance:輪詢選取提供者策略，平均分佈，但是存在請求累積的問題
- LeastActive LoadBalance:最少活躍調用策略，解決慢提供者接收更少的請求
- ConstantHash LoadBalance:一致性Hash策略，使相同參數請求總是發到同一提供者，一臺機器宕機，可以基於虛擬節點，分攤至其他提供者，避免引起提供者的劇烈變動
9.dubbo的集羣容錯方案
- Failover Cluster：失敗自動切換，當出現失敗，重試其它服務器。通常用於讀操作，但重試會帶來更長延遲。
- Failfast Cluster：快速失敗，只發起一次調用，失敗立即報錯。通常用於非冪等性的寫操作，比如新增記錄。
- Failsafe Cluster：失敗安全，出現異常時，直接忽略。通常用於寫入審計日誌等操作。
- Failback Cluster：失敗自動恢復，後臺記錄失敗請求，定時重發。通常用於消息通知操作。
- Forking Cluster:並行調用多個服務器，只要一個成功即返回。通常用於實時性要求較高的讀操作，但需要浪費更多服務資源。可通過 forks=”2″ 來設置最大並行數。
- Broadcast Cluster:廣播調用所有提供者，逐個調用，任意一臺報錯則報錯 。通常用於通知所有提供者更新緩存或日誌等本地資源信息。
10.dubbo不同粒度配置的覆蓋關係
以 timeout 爲例，下圖顯示了配置的查找順序，其它 retries, loadbalance, actives 等類似：
- 方法級優先，接口級次之，全局配置再次之。
- 如果級別一樣，則消費方優先，提供方次之。
其中，服務提供方配置，通過 URL 經由註冊中心傳遞給消費方。
（建議由服務提供方設置超時，因爲一個方法需要執行多長時間，服務提供方更清楚，如果一個消費方同時引用多個服務，就不需要關心每個服務的超時設置）。