【面試題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協議

傳入傳出參數數據包較小(建議小于100K)，消費者比提供者個數多，單一消費者無法壓滿提供者，盡量不要用dubbo協議傳輸大文件或超大字符串。

redis： 基于redis實現的RPC協議

【面試題2】Dubbo推薦用什么協議?使用該協議有哪些優缺點?

傳入傳出參數數據包較小(建議小于100K)，消費者比提供者個數多，單一消費者無法壓滿提供者，盡量不要用dubbo協議傳輸大文件或超大字符串。

【面試題3】Dubbo超時時間的設置

通過timeout屬性配置超時時間,服務的提供者和消費者都可以配置，盡量在服務提供者中配置，因為服務的提供者會對自己提供的服務情況更清楚超時時間不要設置太大(1~5S),會影響并發性能問題。

【面試題4】Dubbo自動重試機

Dubbo在調用服務不成功時，默認會重試2次。Dubbo的路由機制，會把超時的請求路由到其他機器上，而不是本機嘗試，所以 dubbo的重試機制也能一定程度的保證服務的質量。

【面試題5】Dubbo支持的注冊中心

Multicast 注冊中心

Multicast 注冊中心不需要任何中心節點，只要廣播地址，就能進行服務注冊和發現。基于網絡中組播傳輸實現

Zookeeper 注冊中心

基于分布式協調系統 Zookeeper 實現，采用Zookeeper 的 watch 機制實現數據變更

redis 注冊中心

基于redis實現，采用key/Map存儲，住key存儲服務名和類型，Map中key存儲服務URL，value 服務過期時間。基于redis 的發布/訂閱模式通知數據變更;

【面試題6】Dubbo集群的負載均衡策略

隨機

按權重設置隨機概率。在一個截面上碰撞的概率高，但調用量越大分布越均勻，而且按概率使用權重后也比較均勻，有利于動態調整提供者權重。(權重可以在dubbo管控臺配置)

輪循

按公約后的權重設置輪循比率。存在慢的提供者累積請求問題，比如：第二臺機器很慢，但沒掛，當請求調到第二臺時就卡在那，久而久之，所有請求都卡在調到第二臺上。

最少活躍調用數

相同活躍數的隨機，活躍數指調用前后計數差。使慢的提供者收到更少請求，因為越慢的提供者的調用前后計數差會越大。

一致性Hash

相同參數的請求總是發到同一提供者。當某一臺提供者掛時，原本發往該提供者的請求，基于虛擬節點，平攤到其它提供者，不會引起劇烈變動。

【面試題7】Dubbo支持哪些序列化方式?

dubbo序列化：阿里尚未開發成熟的高效java序列化實現，阿里不建議在生產環境使用它

hessian2序列化(默認推薦)：hessian是一種跨語言的高效二進制序列化方式。但這里實際不是原生的hessian2序列化，而是阿里修改過的hessian lite，它是dubbo RPC默認啟用的序列化方式

json序列化：目前有兩種實現，一種是采用的阿里的fastjson庫，另一種是采用dubbo中自己實現的簡單json庫，但其實現都不是特別成熟，而且json這種文本序列化性能一般不如上面兩種二進制序列化。

java序列化：主要是采用JDK自帶的Java序列化實現，性能很不理想。

【面試題8】注冊中心宕機，服務間是否可以繼續通信

可以通信的，啟動dubbo時，消費者會從zk拉取注冊的生產者的地址接口等數據，緩存在本地。每次調用時，按照本地存儲的地址進行調用;

但前提是你沒有增加新的服務，如果你要調用新的服務，則是不能辦到的。

另外如果服務的提供者全部宕機，服務消費者會無法使用，并無限次重連等待服務者恢復;

【面試題9】Dubbo與spring的關系

Dubbo采用全Spring 配置方式，透明化接入應用，對應用沒有任何API 侵入，只需用Spring加載Dubbo的配置即可。

【面試題10】Dubbo使用的是什么通信框架?

NIO Netty框架

【面試題11】Dubbo的集群容錯方案

Failover Cluster(默認):

失敗自動切換，當出現失敗，重試其它服務器。通常用于讀操作，但重試會帶來更長延遲。

Failfast Cluster

快速失敗，只發起一次調用，失敗立即報錯。通常用于非冪等性的寫操作，比如新增記錄。

Failsafe Cluster

失敗安全，出現異常時，直接忽略。通常用于寫入審計日志等操作。

Failback Cluster

失敗自動恢復，后臺記錄失敗請求，定時重發。通常用于消息通知操作。

Forking Cluster

并行調用多個服務器，只要一個成功即返回。通常用于實時性要求較高的讀操作，但需要浪費更多服務資源。可通過 forks="2" 來設置最大并行數。

Broadcast Cluster

廣播調用所有提供者，逐個調用，任意一臺報錯則報錯 。通常用于通知所有提供者更新緩存或日志等本地資源信息。

【面試題12】Dubbo 和 Spring Cloud 的關系?

Dubbo 是 SOA 時代的產物，它的關注點主要在于服務的調用，流量分發、流量監控和熔斷。而 Spring Cloud 誕生于微服務架構時代，考慮的是微服務治理的方方面面，另外由于依托了 Spirng、Spirng Boot 的優勢之上，兩個框架在開始目標就不一致，Dubbo定位服務治理、Spirng Cloud 是一個生態。最大的區別：Dubbo 底層是使用 Netty 這樣的 NIO 框架，是基于TCP 協議傳輸的，配合以 Hession 序列化完成 RPC 通信。而 SpringCloud 是基于 Http 協議+Rest 接口調用遠程過程的通信，相對來說，Http 請求會有更大的報文，占的帶寬也會更多。但是REST相比RPC更為靈活，服務提供方和調用方的依賴只依靠一紙契約，不存在代碼級別的強依賴。


猜你喜歡：

Spring Cloud和Dubbo的區別是什么?

Zookeeper+dubbo視頻教程

Java高級軟件工程師課程