1.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協議
2.Dubbo超時時間怎樣設置？
Dubbo超時時間設置有兩種方式：
- 服務提供者端設置超時時間，在Dubbo的用戶文檔中，推薦如果能在服務端多配置就盡量多配置，因為服務提供者比消費者更清楚自己提供的服務特性。
- 服務消費者端設置超時時間，如果在消費者端設置了超時時間，以消費者端為主，即優先級更高。因為服務調用方設置超時時間控制性更靈活。如果消費方超時，服務端線程不會定制，會產生警告。
3.Dubbo有些哪些注冊中心？
- Multicast注冊中心： Multicast注冊中心不需要任何中心節點，只要廣播地址，就能進行服務注冊和發現。基於網絡中組播傳輸實現；
- Zookeeper注冊中心： 基於分布式協調系統Zookeeper實現，采用Zookeeper的watch機制實現數據變更；
- redis注冊中心： 基於redis實現，采用key/Map存儲，住key存儲服務名和類型，Map中key存儲服務URL，value服務過期時間。基於redis的發布/訂閱模式通知數據變更；
- Simple注冊中心
4.Dubbo集群的負載均衡有哪些策略
Dubbo提供了常見的集群策略實現，並預擴展點予以自行實現。
- Random LoadBalance: 隨機選取提供者策略，有利於動態調整提供者權重。截面碰撞率高，調用次數越多，分布越均勻；
- RoundRobin LoadBalance: 輪循選取提供者策略，平均分布，但是存在請求累積的問題；
- LeastActive LoadBalance: 最少活躍調用策略，解決慢提供者接收更少的請求；
- ConstantHash LoadBalance: 一致性Hash策略，使相同參數請求總是發到同一提供者，一台機器宕機，可以基於虛擬節點，分攤至其他提供者，避免引起提供者的劇烈變動；
5.Dubbo監控中心搭建
自行搭建