【51CTO.com原創稿件】最近，開源社區發生了一件大事，那個全國 Java 開發者使用最廣的開源服務框架 Dubbo 低調重啟維護，并且 3 個月連續發布了 4 個維護版本。

[[210451]]

我上次在寫“放棄Dubbo，選擇最流行的Spring Cloud微服務架構實踐與經驗總結”這篇文章的時候，就有很多的網友給我留言說，Dubbo 又開始更新了。

我當然是清楚的，我也一直在關注著 Dubbo 的走向，在幾個月前技術圈里面就有一個消息說是 Dubbo 又開始更新了，大家議論紛紛不知真偽。

我還專門跑到 GitHub 上面進行了留言詢問，最后在 Dubbo 的 gitter 聊天室里面找到了確信的答案，說是正在組建團隊。

雖然稍稍有所期待，但也不知道阿里這次拿出了多少的誠意來做這件事，于是我昨天又到 GitHub 逛了一下，發現從 9 月開始，阿里三個月連著發布了四個版本，還是非常有誠意的，值得關注。

Dubbo 簡介

Dubbo 是阿里巴巴公司一個開源的高性能服務框架，致力于提供高性能和透明化的 RPC 遠程服務調用方案，以及 SOA 服務治理方案，使得應用可通過高性能 RPC 實現服務的輸出、輸入功能和 Spring 框架無縫集成。

Dubbo 包含遠程通訊、集群容錯和自動發現三個核心部分。它提供透明化的遠程方法調用，實現像調用本地方法一樣調用遠程方法，只需簡單配置，沒有任何 API 侵入。

同時它具備軟負載均衡及容錯機制，可在內網替代 F5 等硬件負載均衡器，降低成本，減少單點。

它可以實現服務自動注冊與發現，不再需要寫死服務提供方地址，注冊中心基于接口名查詢服務提供者的 IP 地址，并且能夠平滑添加或刪除服務提供者。

2011 年末，阿里巴巴在 GitHub 上開源了基于 Java 的分布式服務治理框架 Dubbo，之后它成為了國內該類開源項目的佼佼者，許多開發者對其表示青睞。

同時，先后有不少公司在實踐中基于 Dubbo 進行分布式系統架構。目前在 GitHub 上，它的 fork、star 數均已破萬。

Dubbo 核心功能：

• 遠程通訊，提供對多種基于長連接的 NIO 框架抽象封裝，包括多種線程模型，序列化，以及“請求-響應”模式的信息交換方式。
• 集群容錯，提供基于接口方法的透明遠程過程調用，包括多協議支持，以及軟負載均衡，失敗容錯，地址路由，動態配置等集群支持。
• 自動發現，基于注冊中心目錄服務，使服務消費方能動態的查找服務提供方，使地址透明，使服務提供方可以平滑增加或減少機器。

Dubbo 發展史

發展到開源

2008 年底在阿里內部開始規劃調用，2009 年初開發 1.0 版本;2010 年 04 月在 1.0 的版本之上進行了重構，發布了 2.0 版本;2011 年 10 月阿里宣布將 Dubbo 開源，開源的第一個版本為版本 dubbo-2.0.7。

開源成長

Dubbo 開源之后，框架發展比較迅速，幾乎兩三個月會發布一個版本，于 2012 年 3 月 14 號發布版本 dubbo-2.1.0。

隨后又進入另一個快速發展期，版本發布頻繁，幾乎每一個月會發布好幾次。直到 2013 年 3 月 17 號發布了 dubbo-2.4.10，版本陷入停滯;2014 年 10 月 30 號發布版本 dubbo-2.4.11，修復了一個小 Bug，版本又陷入漫長的停滯到現在。

阿里之外的發展

2014 年的 10 月 20 號，當當網 Fork 了阿里的一個 Dubbo 版本開始維護，并命名為 dubbox-2.8.0。

值得注意的是，當當網擴展 Dubbo 服務框架支持 REST 風格遠程調用，并且跟隨著 ZooKeepe 和 Spring 升級了對應的版本。之后 Dubbox 一直在小版本維護，2015 年 3 月 31 號發布了最后一個版本 dubbox-2.8.4。

Dubbo 團隊這三個月都做了什么?

目前 Dubbo 的主力開發以阿里巴巴中間件團隊為主，同時在阿里內部也招募了一些對 Dubbo 感興趣的同事。

大家要知道，Dubbo 距離今年開始維護的上一個版本是什么時間發布的嗎?是 2014 年 10 月 30 號，差了整整將近 3 年，Dubbo 所依賴的 Jdk、Spring、Zookeeper、Zkclient 等等不知道都更新了多少個版本。

因此阿里恢復更新的第一步就是適配所依賴的各組件版本，讓 Dubbo 所依賴的基礎環境不要太落伍，另外也 Fixed 掉了一些嚴重的 Bug。

dubbo-2.5.4/5 版本

2017 年 9 月，阿里發布了 dubbo-2.5.4/5 版本，更新內容如下：

依賴升級

這版在升級相關依賴版本的同時，以問題反饋頻率和影響面排定優先級，優先解決了幾個反饋最多、影響較大的一些缺陷，包括優雅停機、異步調用、動態配置、MonitorFilter 監控統計等問題。

dubbo-2.5.6 版本

2017 年 10 月，阿里發布了 dubbo-2.5.6 版本，又 Fixed 掉了一大批嚴重的 Bug。

發布內容主要包括：

• 泛化調用 PojoUtils 工具類不能正確處理枚舉類型、私有字段等問題。
• provider 業務線程池滿后，拒絕請求的異常無法通知到 consumer 端。
• 業務返回值 payload 超閾值時，payload 被重復發送回 consumer。
• slf4jLogger 正確輸出 log 調用實際所在行號。
• 延遲(delay)暴露存在潛在并發問題，導致不同服務占用多個端口。
• 無 provider 時，consumer 端 mock 邏輯不能生效。
• 一些小優化：OverrideListener 監聽邏輯、provider 端關閉心跳請求、Main 啟動類停機邏輯等。
• 一些小 Bug 修復：動態配置不能刪除、telnet 支持泛型 json 調用、monitor 統計錯誤等。

dubbo-2.5.7 版本

2017 年 11 月，也就是 12 天前，阿里發布了 dubbo-2.5.7。這次不但修復了一批主要的 Bug，還做了一處小功能的完善。

發布內容主要包括：

• 完善注解配置方式，修復社區反饋的舊版注解 Bug。
• 支持啟動時從環境變量讀取注冊 ip port、綁定 ip port，支持社區反饋的容器化部署場景等。
• 調整、開放一些不完善的 xml 配置項，如 dump.directory 等。
• 解決啟動階段 ZK 無法連接導致應用無限阻塞的問題。
• 解決 ZK 無法連接時，MonitorService 初次訪問會導致 rpc 請求阻塞問題 #672。
• 內部 json 實現標記 deprecate，轉為依賴開源 fastjson 實現。
• RMI 協議支持傳遞 attachments。
• Hessian 支持 EnumSet 類型序列化。
• 社區反饋的一些小 Bug 修復及優化。

這次版本發布內容較多，因此還給出了升級建議：

• 此次升級存在以下不兼容或需要注意點，但對核心功能均無影響，且只需添加依賴或遵守配置規則即可避免。這里只是把潛在的注意點列出來，如果你沒用到這些功能無需額外關注。
• AccesslogFilter、telnet、mock 等部分功能依賴了老版 JSON 實現，如開啟以上功能，升級后請添加 fastjson 作為第三方依賴。
• 此次升級完善了注解配置方式，同時保留了老的注解配置代碼，如工程從之前的老版本注解配置轉到 2.5.7 版本，請確保刪除老的注解掃描配置，使用新的配置形式。
• 在工程啟動階段，如遇到 ZK 不可達，當前版本的行為是使用注冊中心緩存繼續啟動。具體由 check 參數決定，MonitorService 初次調用，如遇 ZK 不可達，當前版本會忽略 monitor 數據上傳，以避免阻塞 rpc 主流程。

在 2.5.7 版本更新的同時還給出了下一步的預告，近期即將提供 dubbo-spring-boot-starter 啟動配置模塊。

這個提示說明了兩個事情：

• Dubbo 還會繼續完善，后續會開發很多的新的功能，所以希望大家關注。
• 說明 Spring Boot 的影響力也越來越大，各種牛逼的開源軟件紛紛給出了支持，現在也將包括 Dubbo。

Dubbo 下一步會做什么?

根據阿里技術的信息，最近三個版本會做的事情如下：

1. 優先解決社區使用過程中的問題和框架的缺陷，吸收社區貢獻的新特性，解決文檔訪問和不全面的問題。
2. 提供服務延遲暴亂、優雅停機 API 接口支持 RESTFULE 風格服務調用，提供 netty http 的支持，集成高性能序列化協議。
3. 路由功能優化、消費端異步功能優化、提供端異步調用支持注冊中心推送通知異步、合并處理改造等。

未來計劃

重構動態配置模塊，動態配置和注冊中心分離，集成流行的開源分布式配置管理框架，服務元數據注冊與注冊中心分離，豐富元數據內容，適配流行的 consul etcd 等注冊中心方案。

考慮提供 opentrace、oauth2、metrics、health、gateway 等部分服務化基礎組件的支持，服務治理平臺 OPS 重做，除代碼、UI 重構外，期望能提供更強的服務測試、健康檢查、服務動態治理等特性。

Dubbo 模塊化，各個模塊可單獨打包、單獨依賴，集群熔斷和自動故障檢測能力。

繼續在 Dubbo 框架現代化、國際化這兩個大的方向上進行探索。現代化方面主要是考慮到目前微服務架構以及容器化日漸流行的大趨勢，Dubbo 作為 RPC 框架如何很好地融入其中，成為其生態體系中不可或缺的一個組件。

強調的是 Dubbo 未來的定位并不是要成為一個微服務的全面解決方案，而是專注在 RPC 領域，成為微服務生態體系中的一個重要組件。

至于大家關注的微服務化衍生出的服務治理需求， Dubbo 將積極適配開源解決方案，甚至啟動獨立的開源項目予以支持。

Dubbo 和 Spring Cloud 有何不同?

首先做一個簡單的功能對比：

從上圖可以看出 Dubbo 的功能只是 Spring Cloud 體系的一部分。

這樣對比是不夠公平的，首先 Dubbo 是 SOA 時代的產物，它的關注點主要在于服務的調用，流量分發、流量監控和熔斷。

而 Spring Cloud 誕生于微服務架構時代，考慮的是微服務治理的方方面面，另外由于依托了 Spirng、Spirng Boot 的優勢之上，兩個框架在開始目標就不一致，Dubbo 定位服務治理、Spirng Cloud 是一個生態。

如果僅僅關注于服務治理的這個層面，Dubbo 還優于 Spring Cloud 很多：

• Dubbo 支持更多的協議，如：rmi、hessian、http、webservice、thrift、memcached、redis 等。
• Dubbo 使用 RPC 協議效率更高，在極端壓力測試下，Dubbo 的效率會高于 Spring Cloud 效率一倍多。
• Dubbo 有更強大的后臺管理，Dubbo 提供的后臺管理 Dubbo Admin 功能強大，提供了路由規則、動態配置、訪問控制、權重調節、均衡負載等諸多強大的功能。
• 可以限制某個 IP 流量的訪問權限，設置不同服務器分發不同的流量權重，并且支持多種算法，利用這些功能我們可以在線上做灰度發布、故障轉移等，Spring Cloud 到現在還不支持灰度發布、流量權重等功能。

下圖為 Dubbo Admin 后臺截圖：

所以 Dubbo 專注于服務治理，Spring Cloud 關注于微服務架構生態。

Dubbo 發布對 Spring Cloud 有影響嗎?

國內技術人喜歡拿 Dubbo 和 Spring Cloud 進行對比，是因為兩者都是服務治理非常優秀的開源框架。

但它們兩者的出發點是不一樣的，Dubbo 關注于服務治理這塊并且以后也會繼續往這個方向去發展。

Spring Cloud 關注的是微服務治理的生態。因為微服務治理的方方面面都是它所關注的內容，服務治理也只是微服務生態的一部分而已。

因此可以大膽的斷定，Dubbo 未來會在服務治理方面更為出色，而 Spring Cloud 在微服務治理上面無人能敵。

同時根據 Dubbo 最新的更新技術來看，Dubbo 也會積極的擁抱開源，擁抱新技術。

Dubbo 接下來的版本將會很快的支持 Spring Boot，方便我們享受高效開發的同時，也可以支持高效的服務調用。

Dubbo 被廣泛應用于中國各互聯網公司，如今阿里又重新重視起來并且發布了新版本和一系列的計劃，對于正在使用 Dubbo 的公司來說是一個喜訊，對于中國廣大的開發者來說更是一件非常喜悅的事情。

我們非常樂于看到中國有一款非常優秀的開源框架，讓我們有更多的選擇，有更好的支持。

所以說兩者其實不一定有競爭關系，如果使用得當甚至可以互補;另外兩個關注的領域也不一致，因此對 Spring Cloud 的影響甚微。

Dubbo 和 Spring Cloud 該如何選擇?

可能很多人正在猶豫，在服務治理的時候應該選擇那個框架呢?

如果公司對效率有極高的要求建議使用 Dubbo，相對比 RPC 的效率會比 HTTP 高很多;如果團隊不想對技術架構做大的改造建議使用 Dubbo，Dubbo 僅僅需要少量的修改就可以融入到內部系統的架構中。

但如果技術團隊喜歡挑戰新技術，建議選擇 Spring Cloud，Spring Cloud 架構體系有有趣很酷的技術。

如果公司選擇微服務架構去重構整個技術體系，那么 Spring Cloud 是當仁不讓之選，它可以說是目前最好的微服務框架沒有之一。

最后，技術選型是一個綜合的問題，需要考慮團隊的情況、業務的發展以及公司的產品特征。

最炫最酷的技術并不一定是最好的，選擇適合自己團隊、符合公司業務的框架才是最佳方案。技術的發展永遠沒有盡頭，因此我們對技術也要保持空杯、保持饑餓、保持敬畏!

[[210453]]

張強，曾經先后在互聯網金融、第三方支付公司擔任高級 Java 工程師、架構師、技術經理、技術負責人等職務。在互聯網金融工作期間，從零參與公司技術平臺建設，組織平臺進行過四次大架構升級。目前在一家第三方支付公司做架構師，負責支付公司大數據平臺建設。

【51CTO原創稿件，合作站點轉載請注明原文作者和出處為51CTO.com】