本文首發自「慕課網」，想了解更多IT乾貨內容，程式設計師圈內熱聞，歡迎關注！

作者| 慕課網精英講師陳于吉吉

我們都知道，現在在微服務市場比較流行的有 2 大框架，一個是 Ali 的 Dubbo，一個是 SpringCloud。兩者孰優孰劣一直是一個比較令人頭疼的問題。

1。 技術選型考慮的要素

其實我們可以先不去考慮是採用 Dubbo 還是 SpringCloud，而是回到技術選型本身，先看下技術選型可能存在的指標，然後根據這些指標來考慮到底是選擇那個微服務框架。

可以看到，技術選型需要評估的指標還是非常多的，也是要個很需要經驗的決策。要進行大量的調研和輸入，根據現有的業務情況作出一個符合自身情況的決策。

慕課網免費好課

慕課網

智慧小程式

我們在做技術選型的時候最忌諱的是臨時抱佛腳，在網上隨意搜尋幾個對比文章利用這些碎片化資訊來做出決策。一定要確保我們的選型是基於當前業務增長的判斷，還要弄清楚業務事實背後的假設。

即使這樣，也未必能選出一個最優的方案，但是透過這一系列的評判標準絕對可以挑選出滿足當下業務的技術棧。

2。 Dubbo 還是 SprigCloud

2。1 Dubbo

Dubbo，阿里巴巴公司開源的一個高效能優秀的服務框架，當前 Dubbo 支撐的阿里分散式應用內支撐萬級別的應用數，執行在 20 多萬的伺服器例項上，每天呼叫量萬億級別，是國內最高的分散式應用叢集。目前 Dubbo 已經被阿里贈予 apache 基金會成為頂級專案。

Dubbo 其實也經歷過一段坎坷，中間出現一大段無人維護的階段，可能是讓路於阿里雲收費專案 HSF。不過目前已經在 apache 頂級專案下重新維護，目前最新版本是 3。0。

2。2 SpringCloud

SpringCloud 是 Spring Source 的產物，Spring 社群的強大背書可以說是 Java 業務界無人能匹敵的組織，SpringBoot 和 SpringCloud 更是無縫的緊密相連，在 SpringCloud 發展得初期，Netfix 為其提供了強大的技術輸出，在一開始的階段 Netfix 開關套件基本上是 SpringCloud 的核心。不過隨著 Netfix 的部分元件不更新，SpringCloud 已經在各個方面提供了替代甚至更強的方案。

如果只是拿兩者的背景做比較，前者在國內影響力更大，後者在國外和國內新興企業中影響力更大。但由於背靠 Spring Source 強大的靠山，在背景上，應該是 SpringCloud 略勝一籌。不過不應該作為選型框架主要依據。

2。3 社群活躍度

有人在 2017 年，Dubbo 還未加入 apache 頂級專案時，有人在做了兩個框架在 github 上的活躍度對比，可以看出 SpringCloud 是以小時為活躍維度，而 Dubbo 基本上以年為維度。

但在今天，Dubbo 在加入 apache 頂級專案後，在 github 重新對比，可以看出差距正在縮小

當然真正的活躍不是這麼簡單就做出評判，不過粗略的觀察還是可以得出結論，Dubbo 在社群特別是中國區，活躍已經在恢復。當官方沒有維護之後，還是有一些公司對 Dubbo 做了進一步的開發和維護，例如噹噹基於 Dubbo 研發的分散式框架 Dubbox。

2。4 兩者的效能

Dubbo 和 SpringCloud 其實只是解決方案的框架，集中效能的差異主要體現在服務呼叫和傳輸協議上，Dubbo 使用的是 RPC 通訊協議，提供了 Dubbo 的序列化，Dubbo 預設協議採用單一長連結和 NIO 非同步通訊（保持連線、輪訓處理），使用自定義的報文，適合小數量大併發的服務呼叫場景，而 SpringCloud 預設採用的是 HTTP 協議的 REST API。

網上有人特意做了個模擬測試兩者的效能，使用一個 Pojo 物件包含 10 個屬性，請求 10 萬次，Dubbo 和 SpringCloud 在不同執行緒數量下，每次請求耗時（ms）

以上圖片和測試結果均採自網上

不出意外，採用 HTTP 的 SpringCloud 確實比不過採用 RPC 的 Dubbo。但由此產生了：Http + Json 的 Rest 通訊，效能上難堪重用，其實也是一種誤讀。

評估效能更大的程度是判斷 Http 協議的通訊對於應用的負載是否會成為真正的瓶頸點。

在大部分的公司網路下，網路消耗並不能算上什麼太大的問題。如果真的有問題，SpringCloud 也並不是 Http + Json 強制繫結，也可以選用 Thrift，Protobuf 等高效能 RPC，序列化作為替代方案。

2。5 架構完整性

上述的幾點在這次選型中，最多是參考點之一，真正決定選擇的是架構的完整性，他決定了是否滿足我們的需求。

其實把 SpringCloud 和 Dubbo 進行在架構完整性對比有點不太公平，Dubbo 只是實現了服務治理，而 SpringCloud 到目前為止在 github 上已經有三十多個專案，已經覆蓋了微服務架構下的方方面面。在一定得程度來說，Dubbo 是指 SpringCloud 的一個子集，但在選擇框架的問題上，方案完整度卻恰恰是一個最需要我們重點關注。

在上面章節中，說到了，微服務雖然帶來了模組清晰劃分，獨立部署，技術多樣式的好處，但是由於分散式，也帶來了非常多的複雜度，這些複雜度，是需要進行治理和必要的元件進行支撐。

以上列舉出來一些常用的核心元件，從表格不難發現為何說 Dubbo 只是 SpringCloud 的一個子集，不過有一點必須宣告，Dubbo 裡面對比項中的” 無 “並不是代表不能實現，只是預設 Dubbo 框架自身沒有提供，而我們在市面上還是可以找到很多與之相匹配的開源元件。

例如：

服務閘道器：可以採用 Nginx+lua 作為基礎閘道器，可以起到鑑權，路由等簡單閘道器的規則；

斷路器 ：可以採用 ali 的 Sentinel，Sentinel 比 Hystrix 功能還要強大，並有控制檯；

分散式配置 ： 可以採用百度的 Disconf 或者攜程的 Apollo 作為分散式配置管理，對比起，SpringCloud 的 Config，Config 是儲存和配置在 git 上，使用預設配置不夠直觀，而 Disconf 和 Apollo 都提供了優秀的控制檯，有灰度釋出，許可權隔離功能更加強大；

鏈路跟蹤 ： 可以使用 SkyWalking，目前 SkyWalking 也已經納入 apache 的頂級專案，這 2 年發展迅速，相比 Zipkin，Cat 更加強大，更不用說 Sleuth；

訊息匯流排 ： 可以使用 RabbitMq，採用 AMQP 協議的 RabbitMq 也可以實現訊息代理將分散式系統節點串聯，達到廣播狀態；

批次任務 ： 可以使用 xxl-job。

你可以認為 Dubbo 是組裝電腦，SpringCloud 是品牌電腦。下面給出我們組裝完的 Dubbo 和 SpringCloud 的對比，其中選擇組裝的元件大部分來自國產：

Dubbo 在各個環節我們的選擇自由度很高，也可以說，只能外部去選裝。但畢竟是外部的選裝，例如我們為一臺組裝電腦選擇了一條記憶體或一塊硬碟存在問題導致整臺電腦都奔潰。如果你是 DIY 的高手，這些都不是問題，但如果你是一名小白，或對各個元件不是太熟悉，那可能品牌機會更適合你。

SpringCloud 像品牌機，在 Spring Source 的整合下，做了大量的相容性測試，保證了機器擁有較高的穩定性，但 SpringCloud 的預設元件中也有一些不太好用的元件。

除了以上我們講的元件的區別，還有一些小的細節，例如

筆者在早年使用 Dubbo 為了實現隱式傳參，就對 Dubbo 的原始碼進行了改動，（因為早點 dubbo 停止了維護，所以進行了區域性二次開發），在使用 SpringCloud，發現直接實現 RequestInterceptor 就可以實現，可能 SpingCloud 是後發，所以在一些細節上更加考慮周到，更適合小白的使用。

2。6 學習，招聘成本

應該說，學習成本是 SpringCloud 相比較 Dubbo 是更低的，各種元件基本都是開箱即用，並且依託於 SpringSource 大樹，相容性和可靠性是有保障的，相信寫 Java 程式碼的人無人不熟 Spring。在編碼上，依託 SpringBoot，各種元件配置即可使用，很大的降低的學習和入門成本。

3。 小結

關於 Dubbo 和 SpringCloud 的相關概念和對比，上面已經敘述清楚了，至於選型是 選擇 Dubbo 還是 SpringCloud，這裡得根據自身的情況需求出發，這裡不做推薦選擇。

筆者之前用的一直都是 Dubbo，但後面去了一家新公司新的團隊，選擇了是 ali 版本的 SpringCloud，考慮的原因是：新團隊這方面相關經驗還是比較欠缺，SpringCloud 提供了完整的元件支援，SpringCloud 不失為比較穩妥的選擇。

作為後起之秀，SpringCloud 使用簡單方便，並且 SpringCloud 也有強大的社群支援，文件方面也是非常完善，新團隊沒有必要在此投入過多的時間去閱讀分散的文件和研究各種開源元件，可以分出精力和時間在業務上。

而且公司還存在其他技術棧的團隊，存在介面互調的需求。Dubbo 預設使用的 RPC 並不能很好的實現跨語言，而 SpringCloud 預設 Http REST 本身就是支援跨語言實現。

歡迎關注「慕課網」，發現更多IT圈優質內容，分享乾貨知識，幫助你成為更好的程式設計師！