最近，開源社群發生了一件大事，那個全國 Java 開發者使用最廣的開源服務框架 Dubbo 低調重啟維護，並且 3 個月連續釋出了 4 個維護版本。
我上次在寫放棄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 版本，更新內容如下：
依賴升級
| 依賴 | 當前版本 | 目標版本 | 影響點 |
|---|---|---|---|
| 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、oauth2、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 是當仁不讓之選，它可以說是目前最好的微服務框架沒有之一。
最後，技術選型是一個綜合的問題，需要考慮團隊的情況、業務的發展以及公司的產品特徵。最炫最酷的技術並不一定是最好的，選擇適合自己團隊、符合公司業務的框架才是最佳方案。技術的發展永遠沒有盡頭，因此我們對技術也要保持空杯、保持飢餓、保持敬畏！