最近，開源社區(qū)發(fā)生了一件大事，那個全國 Java 開發(fā)者使用最廣的開源服務框架 Dubbo 低調(diào)重啟維護，并且 3 個月連續(xù)發(fā)布了 4 個維護版本。
我上次在寫放棄Dubbo，選擇最流行的Spring Cloud微服務架構(gòu)實踐與經(jīng)驗總結(jié)這篇文章的時候，就有很多的網(wǎng)友給我留言說，Dubbo 又開始更新了。我當然是清楚的，我也一直在關(guān)注著 Dubbo 的走向，在幾個月前技術(shù)圈里面就有一個消息說是 Dubbo 又開始更新了，大家議論紛紛不知真?zhèn)?。我還專門跑到 GitHub 上面進行了留言詢問，最后在 Dubbo 的 gitter 聊天室里面找到了確信的答案，說是正在組建團隊。雖然稍稍有所期待，但也不知道阿里這次拿出了多少的誠意來做這件事，于是我昨天又到 GitHub 逛了一下，發(fā)現(xiàn)從 9 月開始，阿里三個月連著發(fā)布了四個版本，還是非常有誠意的，值得關(guān)注。
Dubbo簡介Dubbo 是阿里巴巴公司一個開源的高性能服務框架，致力于提供高性能和透明化的 RPC 遠程服務調(diào)用方案，以及 SOA 服務治理方案，使得應用可通過高性能 RPC 實現(xiàn)服務的輸出、輸入功能和 Spring 框架無縫集成。Dubbo 包含遠程通訊、集群容錯和自動發(fā)現(xiàn)三個核心部分。
它提供透明化的遠程方法調(diào)用，實現(xiàn)像調(diào)用本地方法一樣調(diào)用遠程方法，只需簡單配置，沒有任何 API 侵入。同時它具備軟負載均衡及容錯機制，可在內(nèi)網(wǎng)替代 F5 等硬件負載均衡器，降低成本，減少單點。它可以實現(xiàn)服務自動注冊與發(fā)現(xiàn)，不再需要寫死服務提供方地址，注冊中心基于接口名查詢服務提供者的 IP 地址，并且能夠平滑添加或刪除服務提供者。
2011 年末，阿里巴巴在 GitHub 上開源了基于 Java 的分布式服務治理框架 Dubbo，之后它成為了國內(nèi)該類開源項目的佼佼者，許多開發(fā)者對其表示青睞。同時，先后有不少公司在實踐中基于 Dubbo 進行分布式系統(tǒng)架構(gòu)。目前在 GitHub 上，它的 fork、star 數(shù)均已破萬。
Dubbo核心功能:
遠程通訊，提供對多種基于長連接的 NIO 框架抽象封裝，包括多種線程模型，序列化，以及“請求-響應”模式的信息交換方式。
集群容錯，提供基于接口方法的透明遠程過程調(diào)用，包括多協(xié)議支持，以及軟負載均衡，失敗容錯，地址路由，動態(tài)配置等集群支持。
自動發(fā)現(xiàn)，基于注冊中心目錄服務，使服務消費方能動態(tài)的查×××提供方，使地址透明，使服務提供方可以平滑增加或減少機器。
p_w_picpath
Dubbo發(fā)展史發(fā)展到開源
2008 年底在阿里內(nèi)部開始規(guī)劃調(diào)用，2009 年初開發(fā) 1.0 版本；2010 年 04 月在 1.0 的版本之上進行了重構(gòu)，發(fā)布了 2.0 版本；2011 年 10 月阿里宣布將 Dubbo 開源，開源的第一個版本為版本 dubbo-2.0.7。
開源成長
Dubbo 開源之后，框架發(fā)展比較迅速，幾乎兩三個月會發(fā)布一個版本，于 2012 年 3 月 14 號發(fā)布版本 dubbo-2.1.0。隨后又進入另一個快速發(fā)展期，版本發(fā)布頻繁，幾乎每一個月會發(fā)布好幾次。直到 2013 年 3 月 17 號發(fā)布了 dubbo-2.4.10，版本陷入停滯；2014 年 10 月 30 號發(fā)布版本 dubbo-2.4.11，修復了一個小 Bug，版本又陷入漫長的停滯到現(xiàn)在。
阿里之外的發(fā)展
2014 年的 10 月 20 號，當當網(wǎng) Fork 了阿里的一個 Dubbo 版本開始維護，并命名為 dubbox-2.8.0。值得注意的是，當當網(wǎng)擴展 Dubbo 服務框架支持 REST 風格遠程調(diào)用，并且跟隨著 ZooKeepe 和 Spring 升級了對應的版本。之后 Dubbox 一直在小版本維護，2015 年 3 月 31 號發(fā)布了最后一個版本 dubbox-2.8.4。
p_w_picpath
Dubbo團隊這三個月都做了什么目前 Dubbo 的主力開發(fā)以阿里巴巴中間件團隊為主，同時在阿里內(nèi)部也招募了一些對 Dubbo 感興趣的同事。大家要知道，Dubbo 距離今年開始維護的上一個版本是什么時間發(fā)布的嗎？是 2014 年 10 月 30 號，差了整整將近 3 年，Dubbo 所依賴的 Jdk、Spring、Zookeeper、Zkclient 等等不知道都更新了多少個版本。因此阿里恢復更新的第一步就是適配所依賴的各組件版本，讓 Dubbo 所依賴的基礎(chǔ)環(huán)境不要太落伍，另外也 Fixed 掉了一些嚴重的 Bug。
dubbo-2.5.4/5版本
2017 年 9 月，阿里發(fā)布了 dubbo-2.5.4/5 版本，更新內(nèi)容如下：
依賴升級
| 依賴 | 當前版本 | 目標版本 | 影響點 |
|---|---|---|---|
| spring | 3.2.16.RELEASE | 4.3.10.RELEASE | schema配置解析；Http RPC協(xié)議 |
| zookeeper | 3.3.3 | 3.4.9 | 常用注冊中心 |
| zkclient | 0.1 0.10 | zookeeper | 客戶端工具 |
| curator | 1.1.16 | 2.12.0 | zookeeper客戶端工具 |
| commons-logging | 1.1.1 | 1.2 | 日志實現(xiàn)集成 |
| hessian | 4.0.6 | 4.0.38 | hessian RPC協(xié)議 |
| jedis | 2.1.0 | 2.9.0 | redis注冊中心；緩存RPC |
| httpclient | 4.1.2 | 4.5.3 | hessian等用http連接池 |
| validator | 1.0.0 | 1.1.0.Final | java validation規(guī)范 |
| cxf | 2.6.1 | 3.0.14 | webservice |
| jcache | 0.4 | 1.0.0 | jcache規(guī)范 |
這版在升級相關(guān)依賴版本的同時，以問題反饋頻率和影響面排定優(yōu)先級，優(yōu)先解決了幾個反饋最多、影響較大的一些缺陷，包括優(yōu)雅停機、異步調(diào)用、動態(tài)配置、MonitorFilter 監(jiān)控統(tǒng)計等問題。
dubbo-2.5.6版本
2017 年 10 月，阿里發(fā)布了 dubbo-2.5.6 版本，又 Fixed 掉了一大批嚴重的 Bug。
發(fā)布內(nèi)容
泛化調(diào)用PojoUtils工具類不能正確處理枚舉類型、私有字段等問題
provider業(yè)務線程池滿后，拒絕請求的異常無法通知到consumer端
業(yè)務返回值payload超閾值時，payload被重復發(fā)送回consumer
slf4jLogger正確輸出log調(diào)用實際所在行號
延遲(delay)暴露存在潛在并發(fā)問題，導致不同服務占用多個端口
無provider時，consumer端mock邏輯不能生效
一些小優(yōu)化：OverrideListener監(jiān)聽邏輯、provider端關(guān)閉心跳請求、Main啟動類停機邏輯等
一些小bug修復：動態(tài)配置不能刪除、telnet支持泛型json調(diào)用、monitor統(tǒng)計錯誤等
dubbo-2.5.7版本
2017 年 11 月，也就是 12 天前，阿里發(fā)布了 dubbo-2.5.7。這次不但修復了一批主要的 Bug，還做了一處小功能的完善。
發(fā)布內(nèi)容
完善注解配置方式，修復社區(qū)反饋的舊版注解bug
支持啟動時從環(huán)境變量讀取注冊ip port、綁定ip port，支持社區(qū)反饋的容器化部署場景等
調(diào)整、開放一些不完善的xml配置項，如dump.directory等
解決啟動階段zk無法連接導致應用無限阻塞的問題
解決zk無法連接時，MonitorService初次訪問會導致rpc請求阻塞問題 #672
內(nèi)部json實現(xiàn)標記deprecate，轉(zhuǎn)為依賴開源fastjson實現(xiàn)
RMI協(xié)議支持傳遞p_w_uploads
Hessian支持EnumSet類型序列化
社區(qū)反饋的一些小bug修復及優(yōu)化
這次版本發(fā)布內(nèi)容較多，因此還給出了升級建議。
升級請注意
此次升級存在以下不兼容或需要注意點，但對核心功能均無影響，且只需添加依賴或遵守配置規(guī)則即可避免。這里只是把潛在的注意點列出來，如果你沒用到這些功能無需額外關(guān)注。
AccesslogFilter、telnet、mock等部分功能依賴了老版JSON實現(xiàn)，如開啟以上功能，升級后請?zhí)砑觙astjson作為第三方依賴。
此次升級完善了注解配置方式，同時保留了老的注解配置代碼，如工程從之前的老版本注解配置轉(zhuǎn)到2.5.7版本，請確保刪除老的注解掃描配置，使用新的配置形式。
在工程啟動階段，如遇到zk不可達，當前版本的行為是使用注冊中心緩存繼續(xù)啟動（具體由check參數(shù)決定。
MonitorService初次調(diào)用，如遇zk不可達，當前版本會忽略monitor數(shù)據(jù)上傳，以避免阻塞rpc主流程。
重點
在 2.5.7 版本更新的同時還給出了下一步的預告，近期即將提供 dubbo-spring-boot-starter 啟動配置模塊。
這個提示說明了兩個事情：
Dubbo 還會繼續(xù)完善，后續(xù)會開發(fā)很多的新的功能，所以希望大家關(guān)注。
說明 Spring Boot 的影響力也越來越大，各種牛逼的開源軟件紛紛給出了支持，現(xiàn)在也將包括 Dubbo。
根據(jù)阿里技術(shù)的信息，最近三個版本會做的事情如下：
優(yōu)先解決社區(qū)使用過程中的問題和框架的缺陷，吸收社區(qū)貢獻的新特性，解決文檔訪問和不全面的問題。
提供服務延遲暴亂、優(yōu)雅停機 API 接口支持 RESTFULE 風格服務調(diào)用，提供 netty http 的支持，集成高性能序列化協(xié)議。
路由功能優(yōu)化、消費端異步功能優(yōu)化、提供端異步調(diào)用支持注冊中心推送通知異步、合并處理改造等。
未來計劃：
重構(gòu)動態(tài)配置模塊，動態(tài)配置和注冊中心分離，集成流行的開源分布式配置管理框架，服務元數(shù)據(jù)注冊與注冊中心分離，豐富元數(shù)據(jù)內(nèi)容，適配流行的 consul etcd 等注冊中心方案?？紤]提供 opentrace、oauth3、metrics、health、gateway 等部分服務化基礎(chǔ)組件的支持，服務治理平臺 OPS 重做，除代碼、UI 重構(gòu)外，期望能提供更強的服務測試、健康檢查、服務動態(tài)治理等特性。Dubbo 模塊化，各個模塊可單獨打包、單獨依賴，集群熔斷和自動故障檢測能力。
繼續(xù)在 Dubbo 框架現(xiàn)代化、國際化這兩個大的方向上進行探索。現(xiàn)代化方面主要是考慮到目前微服務架構(gòu)以及容器化日漸流行的大趨勢，Dubbo 作為 RPC 框架如何很好地融入其中，成為其生態(tài)體系中不可或缺的一個組件。強調(diào)的是 Dubbo 未來的定位并不是要成為一個微服務的全面解決方案，而是專注在 RPC 領(lǐng)域，成為微服務生態(tài)體系中的一個重要組件。至于大家關(guān)注的微服務化衍生出的服務治理需求， Dubbo 將積極適配開源解決方案，甚至啟動獨立的開源項目予以支持。
Dubbo和Spring Cloud有何不同？首先做一個簡單的功能對比：
| Dubbo | Spring Cloud | |
|---|---|---|
| 服務注冊中心 | Zookeeper | Spring Cloud Netflix Eureka |
| 服務調(diào)用方式 | RPC | REST API |
| 服務監(jiān)控 | Dubbo-monitor | Spring Boot Admin |
| 斷路器 | 不完善 | Spring Cloud Netflix Hystrix |
| 服務網(wǎng)關(guān) | 無 | Spring Cloud Netflix Zuul |
| 分布式配置 | 無 | Spring Cloud Config |
| 服務跟蹤 | 無 | Spring Cloud Sleuth |
| 消息總線 | 無 | Spring Cloud Bus |
| 數(shù)據(jù)流 | 無 | Spring Cloud Stream |
| 批量任務 | 無 | Spring Cloud Task |
| …… | …… | …… |
從上圖可以看出其實Dubbo的功能只是Spring Cloud體系的一部分。
這樣對比是不夠公平的，首先 Dubbo 是 SOA 時代的產(chǎn)物，它的關(guān)注點主要在于服務的調(diào)用，流量分發(fā)、流量監(jiān)控和熔斷。而 Spring Cloud 誕生于微服務架構(gòu)時代，考慮的是微服務治理的方方面面，另外由于依托了 Spirng、Spirng Boot 的優(yōu)勢之上，兩個框架在開始目標就不一致，Dubbo 定位服務治理、Spirng Cloud 是一個生態(tài)。
如果僅僅關(guān)注于服務治理的這個層面，Dubbo其實還優(yōu)于Spring Cloud很多：
Dubbo 支持更多的協(xié)議，如：rmi、hessian、http、webservice、thrift、memcached、redis 等。
Dubbo 使用 RPC 協(xié)議效率更高，在極端壓力測試下，Dubbo 的效率會高于 Spring Cloud 效率一倍多。
Dubbo 有更強大的后臺管理，Dubbo 提供的后臺管理 Dubbo Admin 功能強大，提供了路由規(guī)則、動態(tài)配置、訪問控制、權(quán)重調(diào)節(jié)、均衡負載等諸多強大的功能。
可以限制某個 IP 流量的訪問權(quán)限，設(shè)置不同服務器分發(fā)不同的流量權(quán)重，并且支持多種算法，利用這些功能我們可以在線上做灰度發(fā)布、故障轉(zhuǎn)移等，Spring Cloud 到現(xiàn)在還不支持灰度發(fā)布、流量權(quán)重等功能。
p_w_picpath
所以Dubbo專注于服務治理；Spring Cloud關(guān)注于微服務架構(gòu)生態(tài)。
Dubbo發(fā)布對Spring Cloud有影響嗎？國內(nèi)技術(shù)人喜歡拿 Dubbo 和 Spring Cloud 進行對比，是因為兩者都是服務治理非常優(yōu)秀的開源框架。但它們兩者的出發(fā)點是不一樣的，Dubbo 關(guān)注于服務治理這塊并且以后也會繼續(xù)往這個方向去發(fā)展。Spring Cloud 關(guān)注的是微服務治理的生態(tài)。因為微服務治理的方方面面都是它所關(guān)注的內(nèi)容，服務治理也只是微服務生態(tài)的一部分而已。因此可以大膽的斷定，Dubbo 未來會在服務治理方面更為出色，而 Spring Cloud 在微服務治理上面無人能敵。
同時根據(jù) Dubbo 最新的更新技術(shù)來看，Dubbo 也會積極的擁抱開源，擁抱新技術(shù)。Dubbo 接下來的版本將會很快的支持 Spring Boot，方便我們享受高效開發(fā)的同時，也可以支持高效的服務調(diào)用。Dubbo 被廣泛應用于中國各互聯(lián)網(wǎng)公司，如今阿里又重新重視起來并且發(fā)布了新版本和一系列的計劃，對于正在使用 Dubbo 的公司來說是一個喜訊，對于中國廣大的開發(fā)者來說更是一件非常喜悅的事情。我們非常樂于看到中國有一款非常優(yōu)秀的開源框架，讓我們有更多的選擇，有更好的支持。
兩者其實不一定有競爭關(guān)系，如果使用得當甚至可以互補；另外兩個關(guān)注的領(lǐng)域也不一致，因此對 Spring Cloud 的影響甚微。
如何選擇？可能很多人正在猶豫，在服務治理的時候應該選擇那個框架呢？如果公司對效率有極高的要求建議使用 Dubbo，相對比 RPC 的效率會比 HTTP 高很多；如果團隊不想對技術(shù)架構(gòu)做大的改造建議使用 Dubbo，Dubbo 僅僅需要少量的修改就可以融入到內(nèi)部系統(tǒng)的架構(gòu)中。但如果技術(shù)團隊喜歡挑戰(zhàn)新技術(shù)，建議選擇 Spring Cloud，Spring Cloud 架構(gòu)體系有有趣很酷的技術(shù)。如果公司選擇微服務架構(gòu)去重構(gòu)整個技術(shù)體系，那么 Spring Cloud 是當仁不讓之選，它可以說是目前最好的微服務框架沒有之一。
最后，技術(shù)選型是一個綜合的問題，需要考慮團隊的情況、業(yè)務的發(fā)展以及公司的產(chǎn)品特征。最炫最酷的技術(shù)并不一定是最好的，選擇適合自己團隊、符合公司業(yè)務的框架才是最佳方案。技術(shù)的發(fā)展永遠沒有盡頭，因此我們對技術(shù)也要保持空杯、保持饑餓、保持敬畏！
原文出處阿里Dubbo瘋狂更新，關(guān)Spring Cloud什么事?
重慶分公司
重慶分公司
