阿里Dubbo瘋狂更新，關Spring Cloud什麼事？

時間 2019-11-12

標籤阿里 dubbo 瘋狂更新 spring cloud 什麼事欄目阿里巴巴简体版

原文原文鏈接

最近，開源社區發生了一件大事，那個全國 Java 開發者使用最廣的開源服務框架 Dubbo 低調重啓維護，而且 3 個月連續發佈了 4 個維護版本。java

我上次在寫放棄Dubbo，選擇最流行的Spring Cloud微服務架構實踐與經驗總結這篇文章的時候，就有不少的網友給我留言說，Dubbo 又開始更新了。我固然是清楚的，我也一直在關注着 Dubbo 的走向，在幾個月前技術圈裏面就有一個消息說是 Dubbo 又開始更新了，你們議論紛紛不知真僞。我還專門跑到 GitHub 上面進行了留言詢問，最後在 Dubbo 的 gitter 聊天室裏面找到了確信的答案，說是正在組建團隊。雖然稍稍有所期待，但也不知道阿里此次拿出了多少的誠意來作這件事，因而我昨天又到 GitHub 逛了一下，發現從 9 月開始，阿里三個月連着發佈了四個版本，仍是很是有誠意的，值得關注。git

Dubbo簡介

Dubbo 是阿里巴巴公司一個開源的高性能服務框架，致力於提供高性能和透明化的 RPC 遠程服務調用方案，以及 SOA 服務治理方案，使得應用可經過高性能 RPC 實現服務的輸出、輸入功能和 Spring 框架無縫集成。Dubbo 包含遠程通信、集羣容錯和自動發現三個核心部分。web

它提供透明化的遠程方法調用，實現像調用本地方法同樣調用遠程方法，只需簡單配置，沒有任何 API 侵入。同時它具有軟負載均衡及容錯機制，可在內網替代 F5 等硬件負載均衡器，下降成本，減小單點。它能夠實現服務自動註冊與發現，再也不須要寫死服務提供方地址，註冊中心基於接口名查詢服務提供者的 IP 地址，而且可以平滑添加或刪除服務提供者。redis

2011 年底，阿里巴巴在 GitHub 上開源了基於 Java 的分佈式服務治理框架 Dubbo，以後它成爲了國內該類開源項目的佼佼者，許多開發者對其表示青睞。同時，前後有很多公司在實踐中基於 Dubbo 進行分佈式系統架構。目前在 GitHub 上，它的 fork、star 數均已破萬。算法

Dubbo核心功能:spring

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

Dubbo發展史

發展到開源json

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 版本，更新內容以下：

依賴升級

依賴	當前版本	目標版本	影響點
spring	3.2.16.RELEASE	4.3.10.RELEASE	schema配置解析；Http RPC協議
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	日誌實現集成
hessian	4.0.6	4.0.38	hessian RPC協議
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規範
cxf	2.6.1	3.0.14	webservice
jcache	0.4	1.0.0	jcache規範

這版在升級相關依賴版本的同時，以問題反饋頻率和影響面排定優先級，優先解決了幾個反饋最多、影響較大的一些缺陷，包括優雅停機、異步調用、動態配置、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 下一步會作什麼？

根據阿里技術的信息，最近三個版本會作的事情以下：
優先解決社區使用過程當中的問題和框架的缺陷，吸取社區貢獻的新特性，解決文檔訪問和不全面的問題。
提供服務延遲暴亂、優雅停機 API 接口支持 RESTFULE 風格服務調用，提供 netty http 的支持，集成高性能序列化協議。
路由功能優化、消費端異步功能優化、提供端異步調用支持註冊中心推送通知異步、合併處理改造等。

將來計劃：

重構動態配置模塊，動態配置和註冊中心分離，集成流行的開源分佈式配置管理框架，服務元數據註冊與註冊中心分離，豐富元數據內容，適配流行的 consul etcd 等註冊中心方案。考慮提供 opentrace、oauth二、metrics、health、gateway 等部分服務化基礎組件的支持，服務治理平臺 OPS 重作，除代碼、UI 重構外，指望能提供更強的服務測試、健康檢查、服務動態治理等特性。Dubbo 模塊化，各個模塊可單獨打包、單獨依賴，集羣熔斷和自動故障檢測能力。

繼續在 Dubbo 框架現代化、國際化這兩個大的方向上進行探索。現代化方面主要是考慮到目前微服務架構以及容器化日漸流行的大趨勢，Dubbo 做爲 RPC 框架如何很好地融入其中，成爲其生態體系中不可或缺的一個組件。強調的是 Dubbo 將來的定位並非要成爲一個微服務的全面解決方案，而是專一在 RPC 領域，成爲微服務生態體系中的一個重要組件。至於你們關注的微服務化衍生出的服務治理需求， Dubbo 將積極適配開源解決方案，甚至啓動獨立的開源項目予以支持。

Dubbo和Spring Cloud有何不一樣？

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

	Dubbo	Spring Cloud
服務註冊中心	Zookeeper	Spring Cloud Netflix Eureka
服務調用方式	RPC	REST API
服務監控	Dubbo-monitor	Spring Boot Admin
斷路器	不完善	Spring Cloud Netflix Hystrix
服務網關	無	Spring Cloud Netflix Zuul
分佈式配置	無	Spring Cloud Config
服務跟蹤	無	Spring Cloud Sleuth
消息總線	無	Spring Cloud Bus
數據流	無	Spring Cloud Stream
批量任務	無	Spring Cloud Task
……	……	……

從上圖能夠看出其實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專一於服務治理；Spring Cloud關注於微服務架構生態。

Dubbo發佈對Spring Cloud有影響嗎？

國內技術人喜歡拿 Dubbo 和 Spring Cloud 進行對比，是由於二者都是服務治理很是優秀的開源框架。但它們二者的出發點是不同的，Dubbo 關注於服務治理這塊而且之後也會繼續往這個方向去發展。Spring Cloud 關注的是微服務治理的生態。由於微服務治理的方方面面都是它所關注的內容，服務治理也只是微服務生態的一部分而已。所以能夠大膽的判定，Dubbo 將來會在服務治理方面更爲出色，而 Spring Cloud 在微服務治理上面無人能敵。

同時根據 Dubbo 最新的更新技術來看，Dubbo 也會積極的擁抱開源，擁抱新技術。Dubbo 接下來的版本將會很快的支持 Spring Boot，方便咱們享受高效開發的同時，也能夠支持高效的服務調用。Dubbo 被普遍應用於中國各互聯網公司，現在阿里又從新重視起來而且發佈了新版本和一系列的計劃，對於正在使用 Dubbo 的公司來講是一個喜訊，對於中國廣大的開發者來講更是一件很是喜悅的事情。咱們很是樂於看到中國有一款很是優秀的開源框架，讓咱們有更多的選擇，有更好的支持。

二者其實不必定有競爭關係，若是使用得當甚至能夠互補；另外兩個關注的領域也不一致，所以對 Spring Cloud 的影響甚微。

如何選擇？

可能不少人正在猶豫，在服務治理的時候應該選擇那個框架呢？若是公司對效率有極高的要求建議使用 Dubbo，相對比 RPC 的效率會比 HTTP 高不少；若是團隊不想對技術架構作大的改造建議使用 Dubbo，Dubbo 僅僅須要少許的修改就能夠融入到內部系統的架構中。但若是技術團隊喜歡挑戰新技術，建議選擇 Spring Cloud，Spring Cloud 架構體系有有趣很酷的技術。若是公司選擇微服務架構去重構整個技術體系，那麼 Spring Cloud 是當仁不讓之選，它能夠說是目前最好的微服務框架沒有之一。

最後，技術選型是一個綜合的問題，須要考慮團隊的狀況、業務的發展以及公司的產品特徵。最炫最酷的技術並不必定是最好的，選擇適合本身團隊、符合公司業務的框架纔是最佳方案。技術的發展永遠沒有盡頭，所以咱們對技術也要保持空杯、保持飢餓、保持敬畏！

原文出處阿里Dubbo瘋狂更新，關Spring Cloud什麼事？