【51CTO.com原創(chuàng)稿件】最近，開源社區(qū)發(fā)生了一件大事，那個(gè)全國(guó) Java 開發(fā)者使用最廣的開源服務(wù)框架 Dubbo 低調(diào)重啟維護(hù)，并且 3 個(gè)月連續(xù)發(fā)布了 4 個(gè)維護(hù)版本。

[[210451]]

我上次在寫“放棄Dubbo，選擇最流行的Spring Cloud微服務(wù)架構(gòu)實(shí)踐與經(jīng)驗(yàn)總結(jié)”這篇文章的時(shí)候，就有很多的網(wǎng)友給我留言說，Dubbo 又開始更新了。

我當(dāng)然是清楚的，我也一直在關(guān)注著 Dubbo 的走向，在幾個(gè)月前技術(shù)圈里面就有一個(gè)消息說是 Dubbo 又開始更新了，大家議論紛紛不知真?zhèn)巍?/p>

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

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

Dubbo 簡(jiǎn)介

Dubbo 是阿里巴巴公司一個(gè)開源的高性能服務(wù)框架，致力于提供高性能和透明化的 RPC 遠(yuǎn)程服務(wù)調(diào)用方案，以及 SOA 服務(wù)治理方案，使得應(yīng)用可通過高性能 RPC 實(shí)現(xiàn)服務(wù)的輸出、輸入功能和 Spring 框架無縫集成。

Dubbo 包含遠(yuǎn)程通訊、集群容錯(cuò)和自動(dòng)發(fā)現(xiàn)三個(gè)核心部分。它提供透明化的遠(yuǎn)程方法調(diào)用，實(shí)現(xiàn)像調(diào)用本地方法一樣調(diào)用遠(yuǎn)程方法，只需簡(jiǎn)單配置，沒有任何 API 侵入。

同時(shí)它具備軟負(fù)載均衡及容錯(cuò)機(jī)制，可在內(nèi)網(wǎng)替代 F5 等硬件負(fù)載均衡器，降低成本，減少單點(diǎn)。

它可以實(shí)現(xiàn)服務(wù)自動(dòng)注冊(cè)與發(fā)現(xiàn)，不再需要寫死服務(wù)提供方地址，注冊(cè)中心基于接口名查詢服務(wù)提供者的 IP 地址，并且能夠平滑添加或刪除服務(wù)提供者。

2011 年末，阿里巴巴在 GitHub 上開源了基于 Java 的分布式服務(wù)治理框架 Dubbo，之后它成為了國(guó)內(nèi)該類開源項(xiàng)目的佼佼者，許多開發(fā)者對(duì)其表示青睞。

同時(shí)，先后有不少公司在實(shí)踐中基于 Dubbo 進(jìn)行分布式系統(tǒng)架構(gòu)。目前在 GitHub 上，它的 fork、star 數(shù)均已破萬(wàn)。

Dubbo 核心功能：

• 遠(yuǎn)程通訊，提供對(duì)多種基于長(zhǎng)連接的 NIO 框架抽象封裝，包括多種線程模型，序列化，以及“請(qǐng)求-響應(yīng)”模式的信息交換方式。
• 集群容錯(cuò)，提供基于接口方法的透明遠(yuǎn)程過程調(diào)用，包括多協(xié)議支持，以及軟負(fù)載均衡，失敗容錯(cuò)，地址路由，動(dòng)態(tài)配置等集群支持。
• 自動(dòng)發(fā)現(xiàn)，基于注冊(cè)中心目錄服務(wù)，使服務(wù)消費(fèi)方能動(dòng)態(tài)的查找服務(wù)提供方，使地址透明，使服務(wù)提供方可以平滑增加或減少機(jī)器。

Dubbo 發(fā)展史

發(fā)展到開源

2008 年底在阿里內(nèi)部開始規(guī)劃調(diào)用，2009 年初開發(fā) 1.0 版本;2010 年 04 月在 1.0 的版本之上進(jìn)行了重構(gòu)，發(fā)布了 2.0 版本;2011 年 10 月阿里宣布將 Dubbo 開源，開源的第一個(gè)版本為版本 dubbo-2.0.7。

開源成長(zhǎng)

Dubbo 開源之后，框架發(fā)展比較迅速，幾乎兩三個(gè)月會(huì)發(fā)布一個(gè)版本，于 2012 年 3 月 14 號(hào)發(fā)布版本 dubbo-2.1.0。

隨后又進(jìn)入另一個(gè)快速發(fā)展期，版本發(fā)布頻繁，幾乎每一個(gè)月會(huì)發(fā)布好幾次。直到 2013 年 3 月 17 號(hào)發(fā)布了 dubbo-2.4.10，版本陷入停滯;2014 年 10 月 30 號(hào)發(fā)布版本 dubbo-2.4.11，修復(fù)了一個(gè)小 Bug，版本又陷入漫長(zhǎng)的停滯到現(xiàn)在。

阿里之外的發(fā)展

2014 年的 10 月 20 號(hào)，當(dāng)當(dāng)網(wǎng) Fork 了阿里的一個(gè) Dubbo 版本開始維護(hù)，并命名為 dubbox-2.8.0。

值得注意的是，當(dāng)當(dāng)網(wǎng)擴(kuò)展 Dubbo 服務(wù)框架支持 REST 風(fēng)格遠(yuǎn)程調(diào)用，并且跟隨著 ZooKeepe 和 Spring 升級(jí)了對(duì)應(yīng)的版本。之后 Dubbox 一直在小版本維護(hù)，2015 年 3 月 31 號(hào)發(fā)布了最后一個(gè)版本 dubbox-2.8.4。

Dubbo 團(tuán)隊(duì)這三個(gè)月都做了什么?

目前 Dubbo 的主力開發(fā)以阿里巴巴中間件團(tuán)隊(duì)為主，同時(shí)在阿里內(nèi)部也招募了一些對(duì) Dubbo 感興趣的同事。

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

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

dubbo-2.5.4/5 版本

2017 年 9 月，阿里發(fā)布了 dubbo-2.5.4/5 版本，更新內(nèi)容如下：

依賴升級(jí)

這版在升級(jí)相關(guān)依賴版本的同時(shí)，以問題反饋頻率和影響面排定優(yōu)先級(jí)，優(yōu)先解決了幾個(gè)反饋?zhàn)疃?、影響較大的一些缺陷，包括優(yōu)雅停機(jī)、異步調(diào)用、動(dòng)態(tài)配置、MonitorFilter 監(jiān)控統(tǒng)計(jì)等問題。

dubbo-2.5.6 版本

2017 年 10 月，阿里發(fā)布了 dubbo-2.5.6 版本，又 Fixed 掉了一大批嚴(yán)重的 Bug。

發(fā)布內(nèi)容主要包括：

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

dubbo-2.5.7 版本

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

發(fā)布內(nèi)容主要包括：

• 完善注解配置方式，修復(fù)社區(qū)反饋的舊版注解 Bug。
• 支持啟動(dòng)時(shí)從環(huán)境變量讀取注冊(cè) ip port、綁定 ip port，支持社區(qū)反饋的容器化部署場(chǎng)景等。
• 調(diào)整、開放一些不完善的 xml 配置項(xiàng)，如 dump.directory 等。
• 解決啟動(dòng)階段 ZK 無法連接導(dǎo)致應(yīng)用無限阻塞的問題。
• 解決 ZK 無法連接時(shí)，MonitorService 初次訪問會(huì)導(dǎo)致 rpc 請(qǐng)求阻塞問題 #672。
• 內(nèi)部 json 實(shí)現(xiàn)標(biāo)記 deprecate，轉(zhuǎn)為依賴開源 fastjson 實(shí)現(xiàn)。
• RMI 協(xié)議支持傳遞 attachments。
• Hessian 支持 EnumSet 類型序列化。
• 社區(qū)反饋的一些小 Bug 修復(fù)及優(yōu)化。

這次版本發(fā)布內(nèi)容較多，因此還給出了升級(jí)建議：

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

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

這個(gè)提示說明了兩個(gè)事情：

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

Dubbo 下一步會(huì)做什么?

根據(jù)阿里技術(shù)的信息，最近三個(gè)版本會(huì)做的事情如下：

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

未來計(jì)劃

重構(gòu)動(dòng)態(tài)配置模塊，動(dòng)態(tài)配置和注冊(cè)中心分離，集成流行的開源分布式配置管理框架，服務(wù)元數(shù)據(jù)注冊(cè)與注冊(cè)中心分離，豐富元數(shù)據(jù)內(nèi)容，適配流行的 consul etcd 等注冊(cè)中心方案。

考慮提供 opentrace、oauth2、metrics、health、gateway 等部分服務(wù)化基礎(chǔ)組件的支持，服務(wù)治理平臺(tái) OPS 重做，除代碼、UI 重構(gòu)外，期望能提供更強(qiáng)的服務(wù)測(cè)試、健康檢查、服務(wù)動(dòng)態(tài)治理等特性。

Dubbo 模塊化，各個(gè)模塊可單獨(dú)打包、單獨(dú)依賴，集群熔斷和自動(dòng)故障檢測(cè)能力。

繼續(xù)在 Dubbo 框架現(xiàn)代化、國(guó)際化這兩個(gè)大的方向上進(jìn)行探索。現(xiàn)代化方面主要是考慮到目前微服務(wù)架構(gòu)以及容器化日漸流行的大趨勢(shì)，Dubbo 作為 RPC 框架如何很好地融入其中，成為其生態(tài)體系中不可或缺的一個(gè)組件。

強(qiáng)調(diào)的是 Dubbo 未來的定位并不是要成為一個(gè)微服務(wù)的全面解決方案，而是專注在 RPC 領(lǐng)域，成為微服務(wù)生態(tài)體系中的一個(gè)重要組件。

至于大家關(guān)注的微服務(wù)化衍生出的服務(wù)治理需求， Dubbo 將積極適配開源解決方案，甚至啟動(dòng)獨(dú)立的開源項(xiàng)目予以支持。

Dubbo 和 Spring Cloud 有何不同?

首先做一個(gè)簡(jiǎn)單的功能對(duì)比：

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

這樣對(duì)比是不夠公平的，首先 Dubbo 是 SOA 時(shí)代的產(chǎn)物，它的關(guān)注點(diǎn)主要在于服務(wù)的調(diào)用，流量分發(fā)、流量監(jiān)控和熔斷。

而 Spring Cloud 誕生于微服務(wù)架構(gòu)時(shí)代，考慮的是微服務(wù)治理的方方面面，另外由于依托了 Spirng、Spirng Boot 的優(yōu)勢(shì)之上，兩個(gè)框架在開始目標(biāo)就不一致，Dubbo 定位服務(wù)治理、Spirng Cloud 是一個(gè)生態(tài)。

如果僅僅關(guān)注于服務(wù)治理的這個(gè)層面，Dubbo 還優(yōu)于 Spring Cloud 很多：

• Dubbo 支持更多的協(xié)議，如：rmi、hessian、http、webservice、thrift、memcached、redis 等。
• Dubbo 使用 RPC 協(xié)議效率更高，在極端壓力測(cè)試下，Dubbo 的效率會(huì)高于 Spring Cloud 效率一倍多。
• Dubbo 有更強(qiáng)大的后臺(tái)管理，Dubbo 提供的后臺(tái)管理 Dubbo Admin 功能強(qiáng)大，提供了路由規(guī)則、動(dòng)態(tài)配置、訪問控制、權(quán)重調(diào)節(jié)、均衡負(fù)載等諸多強(qiáng)大的功能。
• 可以限制某個(gè) IP 流量的訪問權(quán)限，設(shè)置不同服務(wù)器分發(fā)不同的流量權(quán)重，并且支持多種算法，利用這些功能我們可以在線上做灰度發(fā)布、故障轉(zhuǎn)移等，Spring Cloud 到現(xiàn)在還不支持灰度發(fā)布、流量權(quán)重等功能。

下圖為 Dubbo Admin 后臺(tái)截圖：

所以 Dubbo 專注于服務(wù)治理，Spring Cloud 關(guān)注于微服務(wù)架構(gòu)生態(tài)。

Dubbo 發(fā)布對(duì) Spring Cloud 有影響嗎?

國(guó)內(nèi)技術(shù)人喜歡拿 Dubbo 和 Spring Cloud 進(jìn)行對(duì)比，是因?yàn)閮烧叨际欠?wù)治理非常優(yōu)秀的開源框架。

但它們兩者的出發(fā)點(diǎn)是不一樣的，Dubbo 關(guān)注于服務(wù)治理這塊并且以后也會(huì)繼續(xù)往這個(gè)方向去發(fā)展。

Spring Cloud 關(guān)注的是微服務(wù)治理的生態(tài)。因?yàn)槲⒎?wù)治理的方方面面都是它所關(guān)注的內(nèi)容，服務(wù)治理也只是微服務(wù)生態(tài)的一部分而已。

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

同時(shí)根據(jù) Dubbo 最新的更新技術(shù)來看，Dubbo 也會(huì)積極的擁抱開源，擁抱新技術(shù)。

Dubbo 接下來的版本將會(huì)很快的支持 Spring Boot，方便我們享受高效開發(fā)的同時(shí)，也可以支持高效的服務(wù)調(diào)用。

Dubbo 被廣泛應(yīng)用于中國(guó)各互聯(lián)網(wǎng)公司，如今阿里又重新重視起來并且發(fā)布了新版本和一系列的計(jì)劃，對(duì)于正在使用 Dubbo 的公司來說是一個(gè)喜訊，對(duì)于中國(guó)廣大的開發(fā)者來說更是一件非常喜悅的事情。

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

所以說兩者其實(shí)不一定有競(jìng)爭(zhēng)關(guān)系，如果使用得當(dāng)甚至可以互補(bǔ);另外兩個(gè)關(guān)注的領(lǐng)域也不一致，因此對(duì) Spring Cloud 的影響甚微。

Dubbo 和 Spring Cloud 該如何選擇?

可能很多人正在猶豫，在服務(wù)治理的時(shí)候應(yīng)該選擇那個(gè)框架呢?

如果公司對(duì)效率有極高的要求建議使用 Dubbo，相對(duì)比 RPC 的效率會(huì)比 HTTP 高很多;如果團(tuán)隊(duì)不想對(duì)技術(shù)架構(gòu)做大的改造建議使用 Dubbo，Dubbo 僅僅需要少量的修改就可以融入到內(nèi)部系統(tǒng)的架構(gòu)中。

但如果技術(shù)團(tuán)隊(duì)喜歡挑戰(zhàn)新技術(shù)，建議選擇 Spring Cloud，Spring Cloud 架構(gòu)體系有有趣很酷的技術(shù)。

如果公司選擇微服務(wù)架構(gòu)去重構(gòu)整個(gè)技術(shù)體系，那么 Spring Cloud 是當(dāng)仁不讓之選，它可以說是目前最好的微服務(wù)框架沒有之一。

最后，技術(shù)選型是一個(gè)綜合的問題，需要考慮團(tuán)隊(duì)的情況、業(yè)務(wù)的發(fā)展以及公司的產(chǎn)品特征。

最炫最酷的技術(shù)并不一定是最好的，選擇適合自己團(tuán)隊(duì)、符合公司業(yè)務(wù)的框架才是最佳方案。技術(shù)的發(fā)展永遠(yuǎn)沒有盡頭，因此我們對(duì)技術(shù)也要保持空杯、保持饑餓、保持敬畏!

[[210453]]

張強(qiáng)，曾經(jīng)先后在互聯(lián)網(wǎng)金融、第三方支付公司擔(dān)任高級(jí) Java 工程師、架構(gòu)師、技術(shù)經(jīng)理、技術(shù)負(fù)責(zé)人等職務(wù)。在互聯(lián)網(wǎng)金融工作期間，從零參與公司技術(shù)平臺(tái)建設(shè)，組織平臺(tái)進(jìn)行過四次大架構(gòu)升級(jí)。目前在一家第三方支付公司做架構(gòu)師，負(fù)責(zé)支付公司大數(shù)據(jù)平臺(tái)建設(shè)。

【51CTO原創(chuàng)稿件，合作站點(diǎn)轉(zhuǎn)載請(qǐng)注明原文作者和出處為51CTO.com】