4、默認使用什么序列化框架，你知道的還有哪些？

在Dubbo RPC中，同時支持多種序列化方式：

dubbo序列化，阿里尚不成熟的java序列化實現。

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

json序列化：目前有兩種實現，一種是采用的阿里的fastjson庫，另一種是采用dubbo中自已實現的簡單json庫，一般情況下，json這種文本序列化性能不如二進制序列化。

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

另外還有專門針對Java語言的Kryo，FST，及跨語言的Protostuff、ProtoBuf，Thrift，Avro等。

5、服務提供者能實現失效踢出是什么原理？

利用的是zookeeper的臨時節點原理

Zookeeper

持久節點

所謂持久節點,是指在節點創建后,就一直存在,直到有刪除操作來主動清除這個節點,也就是說不會因為創建該節點的客戶端會話失效而消失

臨時節點

臨時節點的生命周期和客戶端會話綁定,也就是說,如果客戶端會話失效,那么這個節點就會自動被清除掉

Dubbo創建的zookeeper樹結構

當提供者出現斷電等異常停機時，注冊中心能自動刪除提供者信息（通過臨時節點及watch機制實現）
詳見，Dubbo zookeeper注冊中心，傳送門

5、服務上線怎么不影響舊版本？

來自dubbo文檔

<!--當一個接口實現，出現不兼容升級時，可以用版本號過渡，版本號不同的服務相互間不引用。在低壓力時間段，先升級一半提供者為新版本再將所有消費者升級為新版本然后將剩下的一半提供者升級為新版本--> <dubbo:service interface="com.foo.BarService" version="1.0.0" /> <dubbo:service interface="com.foo.BarService" version="2.0.0" /> <dubbo:reference id="barService" interface="com.foo.BarService" version="1.0.0" /> <dubbo:reference id="barService" interface="com.foo.BarService" version="2.0.0" />不區分版本：(2.2.0以上版本支持)<dubbo:reference id="barService" interface="com.foo.BarService" version="*" />

6、如何解決服務調用鏈過長的問題？

使用分布式服務追蹤，如zipkin

7、核心的配置有哪些

核心配置有：

dubbo:service/dubbo:reference/dubbo:protocol/dubbo:registry/dubbo:application/dubbo:provider/dubbo:consumer/dubbo:method/

8、dubbo推薦用什么協議？

默認使用dubbo協議。

dubbo共支持如下幾種通信協議：

• dubbo://
• rmi://
• hessian://
• http://
• webservice://
• thrift://
• memcached://
• redis://
• rest://

詳見：http://dubbo.apache.org/zh-cn/docs/user/references/protocol/introduction.html

9、同一個服務多個提供者，消費者可以直連嗎

可以直連，修改配置即可，也可以通過telnet直接某個服務。

10、畫一畫服務注冊與發現的流程圖

11、集群容錯怎么做？

讀操作建議使用Failover失敗自動切換，默認重試兩次其他服務器。寫操作建議使用Failfast快速失敗，發一次調用失敗就立即報錯。

11.1 集群容錯模式：

Failover Cluster

失敗自動切換，當出現失敗，重試其它服務器。(缺省)

通常用于讀操作，但重試會帶來更長延遲。

可通過retries="2"來設置重試次數(不含第一次)。正是文章剛開始說的那種情況.

Failfast Cluster

快速失敗，只發起一次調用，失敗立即報錯。

通常用于非冪等性的寫操作，比如新增記錄。

Failsafe Cluster

失敗安全，出現異常時，直接忽略。

通常用于寫入審計日志等操作。

Failback Cluster

失敗自動恢復，后臺記錄失敗請求，定時重發。

通常用于消息通知操作。

Forking Cluster

并行調用多個服務器，只要一個成功即返回。

通常用于實時性要求較高的讀操作，但需要浪費更多服務資源。

可通過forks="2"來設置最大并行數。

Broadcast Cluster

廣播調用所有提供者，逐個調用，任意一臺報錯則報錯。(2.1.0開始支持)

通常用于通知所有提供者更新緩存或日志等本地資源信息。

重試次數配置如：(failover集群模式生效)

詳見：http://dubbo.apache.org/zh-cn/docs/source_code_guide/cluster.html

12、負載均衡策略

Dubbo提供了多種均衡策略，缺省為random隨機調用。

Random LoadBalance

隨機，按權重設置隨機概率。

在一個截面上碰撞的概率高，但調用量越大分布越均勻，而且按概率使用權重后也比較均勻，有利于動態調整提供者權重。

RoundRobin LoadBalance

輪循，按公約后的權重設置輪循比率。

存在慢的提供者累積請求問題，比如：第二臺機器很慢，但沒掛，當請求調到第二臺時就卡在那，久而久之，所有請求都卡在調到第二臺上。

LeastActive LoadBalance

最少活躍調用數，相同活躍數的隨機，活躍數指調用前后計數差。

使慢的提供者收到更少請求，因為越慢的提供者的調用前后計數差會越大。

ConsistentHash LoadBalance

一致性Hash，相同參數的請求總是發到同一提供者。

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

Dubbo的集群容錯和負載均衡同樣也是Dubbo本身的高級特性.正如我們在說自定義擴展的時候一樣,這兩個特征同樣也可以進行自定義擴展,用戶可以根據自己實際的需求來擴展他們從而滿足項目的實際需求.

13、Dubbo和Spring Cloud

14、Dubbo如何優雅停機？

Dubbo 是通過 JDK 的 ShutdownHook 來完成優雅停機的，所以如果使用 kill -9 PID 等強制關閉指令，是不會執行優雅停機的，只有通過 kill PID 時，才會執行。

總結

以上是生活随笔為你收集整理的Dubbo——面试问题集（4~14）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。