Dubbo

前幾天看到《Java高級面試必問—Dubbo面試題匯總》，針對裡面的問題自己試著回答一些，有不對的請大家指正。

Dubbo雖然已經不更新了，但是背靠阿里的技術實力，中文資料的豐富，很適合大多數中小型分布式項目的開發。

Dubbo的通信協議

1、 dubbo

默認的，單一長連接、NIO非同步通信。適合數據量小，並發大的場景，消費者數量多於提供者的情況。

傳輸個大文件、視頻、圖片什麼的還是不要用了。

絕大多數的一般項目用這個就夠了。

2、 RMI

這是JDK標準的遠程調用協議，阻塞式短連接&JDK標準的序列化方式。

輸入輸出的數據包大小混合，消費者和提供者數量差不多，是比較適用的，可以傳文件。

個人在項目中沒用過，不怎麼關注。

3、hessian

Hessian採用HTTP通信，由Servlet對外提供服務，在Dubbo中使用Jetty做伺服器。很適合傳輸頁面、文件。

4、Http

這個沒啥好介紹的，主要是適合同時給APP、網頁的Ajax提供服務。我在項目中到沒這麼用過，一般這種情況都是直接用SpringMVC打成war包，通過Keepalived+Nginx+Tomcat進行高可用和負載均衡。

5、WebService

老牌的數據交換技術了，SOAP協議，CXF框架實現，2010年之後我在項目中就沒用過了。

6、thrift

Facebook的RPC框架，Dubbo加了一些頭信息，不支持null值。

7、緩存

Dubbo支持緩存資料庫Memcached、Redis。

通信協議對比

註冊中心

推薦是Zookeeper，還有如下：

1、Multicast，沒有中心，只要節點的廣播地址是一樣的，都可以互相發現，這個也就是小規模應用，或者開發的時候用。

步驟是：

A） 提供者啟動時廣播地址。

B） 消費者啟動時廣播訂閱請求。

C）提供者收到訂閱請求是，單播或組播自己的地址給消費者。

D） 消費者收到提供者地址，進行RPC調用。

2、Redis，主要是用到了Redis的發布/訂閱模式（這個我在項目中用於消息隊列，可參看我之前的文章《基於Redis的消息隊列之發布訂閱模式》，以及相關閱讀：《Redis3.2.9單機版安裝》、《基於Redis的消息隊列之生產消費者模式（明天寫發布/訂閱模式）》）。要求各個伺服器時間必須保持一致，因為需要用心跳監測臟數據，對伺服器還是有一定壓力的。

步驟是：

A） 提供者啟動時提交自己的地址，發送註冊事件。

B） 消費者啟動時訂閱註冊&解除註冊事件，提交自己的地址。

C）消費者收到註冊和解除註冊事件後，去獲取提供者地址列表。

D） 監控中心啟動時訂閱註冊&解除註冊、訂閱&解除訂閱事件。

E）監控中心收到註冊&解除註冊事件後，去獲取提供者地址列表。

F）監控中心收到訂閱&解除訂閱事件後，去獲取消費者地址列表。

3、Simple註冊、監控中心，這是Dubbo自己實現一個服務。

4、Zookeeper，步驟如下：

A） 提供者啟動時寫入自己的URL。

B） 消費者啟動時訂閱提供者URL列表，並寫入自己的URL。

C）監控中心訂閱所有消費者提供者URL目錄。

提供者如何實現失效踢出

以Zookeeper註冊中心為例，有一個heartbeat_monitor心跳監測線程，檢查提供者是否存活，如果檢測不到心跳，就把提供者從提供者列表中移除，反之加入。

在不影響舊版本的情況下升級新版本服務

使用Dubbo就比較方便，因為在配置提供者和服務者的時候可以指定版本號。

服務調用鏈過長

還是應該結合業務來梳理模塊，一旦某個業務操作的調用鏈過長的時候，就要考慮把這一塊整合一下。

Dubbo核心配置

dubbo:application name應用名

dubbo:registry註冊中心

dubbo:protocol使用協議和埠

dubbo:reference訂閱的服務介面 check啟動時檢測服務是否可用 version 多版本

dubbo:service提供者 cluster容錯機制 retries失敗重試次數 loadbalance負載演算法

是否可以直連提供者

可以，在dubbo:reference通過配置url直接指向某個提供者，多地址用逗號分隔。

服務註冊與發現的流程圖

服務註冊與發現的流程圖

集群容錯

這個在我的《Dubbo消費者提供者簡單例子》中有描述，摘抄如下：

默認的failover，再加上retries，代表消費者調用提供者出現異常時，自動切換，默認試兩次。

failfast，失敗了就報異常，主要是用於非等冪性的寫操作。當然這個也等價於failover，retres=0。

failsafe，失敗就失敗了，也不報異常，用於一些不重要的操作，比如寫個不重要的日誌什麼的，錯個1、2條的不影響。

failback，失敗了重發，比如推送。

forking，調用所有提供者，誰最先返回結果就用誰的，這個太耗資源了。

broadcast，調用所有提供者，一個報錯就報錯，這個主要是用於通知提供者更新緩存啊，本地資源之類的操作。

相關閱讀：Dubbo管理控制台安裝、ZooKeeper單機版安裝配置——集群版後面再發、ZooKeeper集群安裝配置使用

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！