轉自：CSDN，作者：Crazy曉楓

https://blog.csdn.net/u010664947/article/details/80007767

Dubbo由于是二進制的傳輸，占用帶寬會更少。Spring Cloud 是 HTTP 協議傳輸，帶寬占用會比較多，同時使用 HTTP 協議一般會使用 JSON 報文，消耗會更大。

Dubbo 的開發難度較大，原因是 Dubbo 的 jar 包依賴問題很多大型工程無法解決；Spring Cloud 的接口協議約定比較自由且松散，需要有強有力的行政措施來限制接口無序升級。

Dubbo 的注冊中心可以選擇 Zookeeper、Redis 等多種；Spring Cloud 的注冊中心只能用 Eureka 或者自研。

但如果我選，我會用 Spring Cloud。

從公司整體規劃考慮

我不會選擇很久沒人維護的 Dubbo，重啟之后也未必是原班人馬。

從程序員招聘難度考慮

招 Spring Cloud 的程序員會更好招，因為更新更炫。

從系統結構簡易程度考慮

Spring Cloud的系統結構更簡單，“注冊+springmvc=springcloud”，而 Dubbo 各種復雜的 URL、protocol、register、invocation、dubbofilter、dubboSPI，dubbo序列化……炫技的成分更多一些。

從性能考慮

Dubbo 的網絡消耗小于 Spring Cloud，但是在國內95%的公司內，網絡消耗不是什么太大問題。如果真的成了問題，通過壓縮、二進制、高速緩存、分段降級等方法，很容易解。

從開發難易度考慮

Dubbo 的神坑是 jar 包依賴，開發階段難度極大。我曾經帶一個三十人的團隊，因為 jar 包升級問題，把每個人的電腦都操作過。尤其每個人電腦的庫路徑、命令、快捷鍵、鍵盤，鼠標快慢都不一樣，那會兒我默默的（此處省略200字）。Spring Cloud比較自由，但帶來的問題是無法“強力約束接口規范”，建議用行政方式解決，且我們團隊的強力行政約束做的還是比較好的，在接口管控層面比較強效，一個沒有行政組織能力的IT團隊真的是個廢渣，用什么框架都不好使。

從后續改進考慮

Dubbo 的改進是通過 dubbofilter，很多東西沒有，需要自己繼承，如監控、日志、限流、追蹤。Spring Cloud 自己帶了很多監控、限流措施，但是功能可能和歐美習慣相同，國內需要進行適當改造，但更簡單，就是 ServletFilter 而已，但是總歸比 Dubbo 多一些東西是好的。

從配套措施考慮

Spring Cloud 一直宣稱自己是“一套全方面的解決方案”…… 我起初信了，后來發現上當了。實話說：有，但是不是很健全，100分打50的樣子，很多你還需要改造。而 Dubbo 相反，一直宣稱自己是“一套全方面的服務化方案”…… 純服務化沒什么用，任何系統都是相輔相成配套的。一個完整的系統，要有前臺、中臺、后臺、前臺包括前端和交互，中臺包括交易、任務、數據，后臺包括財務、賬戶、管理……單純的服務化解決不了“任何問題”，唯有體系才能解決。在這個層面，Spring Cloud是個往“體系”方向發展的方案，而 Dubbo 僅是個工具而已，兩者相比，就好比始祖鳥與草履蟲的區別。

從技術實力層面考慮

對比雙方的源碼，不得不說 Dubbo 作者的技術能力要高于Spring Cloud，而 Spring Boot 的作者技術能力要高于 Dubbo，即：

Spring Boot > Dubbo > Spring Cloud

我喜歡 Spring Boot 這種大道至簡的風格，Keep it simple and stupid。而 Dubbo 好嘛...... 你先看看 dubboSPI，再看看 Protocol$Adpative 里面那一群繞來繞去的玩意兒，你會迅速判斷出：這群人在炫技。盡管 Dubbo 從上之下分為十層四五十個組件，第一感官上是哇塞好全面好偉大的樣子，但深入之后你會覺得，這技術是很炫，設計的確實很全面，但是用不到。例如：請各位大神給我解釋一下，在 Zookeeper 地址中，使用逗號分隔和分號分隔地址的區別……用途不大，但是代碼里為了這個就走向了“完全不同”的一條分支。用俗語評價，就是“臃腫且無用代碼過多，在文檔里還非得為了這個說出123456來”。說完 Dubbo 再說 Spring Cloud……它沒有技術含量，完全沒有，就是一堆簡單組件拼裝在一起，如 configserver、eurekaserver、robin、feignClient、htstrix等，每個都特別簡單，沒什么技術含量，但我喜歡這種的，就喜歡這種大道至簡的簡單。

最后說 Spring Boot，我要用“純粹”兩個字來評價這個框架。真的很純粹，并且從其代碼架構的總體思路一致性，目標的純粹性，具體模塊的干凈利落，確實是個好框架，值得大家一讀。

從系統應用層面考慮

在技術實力滿分一百能打85分的鄙人的眼中，Dubbo 和 Spring Cloud，不就是兩個框架么？我們是要拯救世界的人，這倆塊鵝卵石一塊圓的一塊方的，能墊腳就行，沒有區別。

簡而言之，Dubbo 確實類似于 Spring Cloud 的一個子集，Dubbo 功能和文檔完善，在國內有很多的成熟用戶，然而鑒于 Dubbo 的社區現狀（曾經長期停止維護，2017年7月31日團隊又宣布重點維護），使用起來還是有一定的門檻。

Dubbo 具有調度、發現、監控、治理等功能，支持相當豐富的服務治理能力。Dubbo架構下，注冊中心對等集群，并會緩存服務列表已被數據庫失效時繼續提供發現功能，本身的服務發現結構有很強的可用性與健壯性，足夠支持高訪問量的網站。

雖然 Dubbo 支持短連接大數據量的服務提供模式，但絕大多數情況下都是使用長連接小數據量的模式提供服務使用的。所以，對于類似于電商等同步調用場景多并且能支撐搭建 Dubbo 這套比較復雜環境的成本的產品而言，Dubbo 確實是一個可以考慮的選擇。但如果產品業務中由于后臺業務邏輯復雜、時間長而導致異步邏輯比較多的話，可能 Dubbo 并不合適。同時，對于人手不足的初創產品而言，這么重的架構維護起來也不是很方便。

Spring Cloud 由眾多子項目組成，如Spring Cloud Config、Spring Cloud Netflix、Spring Cloud Consul 等，提供了搭建分布式系統及微服務常用的工具，如配置管理、服務發現、斷路器、智能路由、微代理、控制總線、一次性 token、全局鎖、選主、分布式會話和集群狀態等，滿足了構建微服務所需的所有解決方案。比如使用 Spring Cloud Config 可以實現統一配置中心，對配置進行統一管理；使用Spring Cloud Netflix 可以實現 Netflix 組件的功能—服務發現（Eureka）、智能路由（Zuul）、客戶端負載均衡（Ribbon）。

但它并沒有重復造輪子，而是選用目前各家公司開發的比較成熟的、經得住實踐考驗的服務框架（我們需要特別感謝 Netflix ，這家很早就成功實踐微服務的公司，幾年前把自家幾乎整個微服務框架棧貢獻給了社區，Spring Cloud 主要是對 Netflix 開源組件的進一步封裝），通過 Spring Boot 進行封裝集成并簡化其使用方式。基于 Spring Boot，意味著其使用方式如 Spring Boot 簡單易用；能夠與Spring Framework、Spring Boot、Spring Data 等其它 Spring 項目完美融合，意味著能從 Spring 獲得巨大的便利，意味著能減少已有項目的遷移成本。

其實，從社區活躍度和功能完整度，再對照業務需求和團隊狀況，基本可以確定如何選型。這里分享網易考拉海購實踐以及團隊選型的心聲：

當前開源上可選用的微服務框架主要有 Dubbo、Spring Cloud 等，鑒于 Dubbo 完備的功能和文檔且在國內被眾多大型互聯網公司選用，考拉自然也選擇了Dubbo作為服務化的基礎框架。其實相比于 Dubbo、Spring Cloud 可以說是一個更完備的微服務解決方案，它從功能性上是 Dubbo 的一個超集，個人認為從選型上對于一些中小型企業 Spring Cloud 可能是一個更好的選擇。提起 Spring Cloud，一些開發的第一印象是 HTTP+JSON 的 REST 通信，性能上難堪重用，其實這也是一種誤讀。

微服務選型要評估以下幾點：內部是否存在異構系統集成的問題；備選框架功能特性是否滿足需求；HTTP 協議的通信對于應用的負載量會否真正成為瓶頸點（Spring Cloud也并不是和HTTP+JSON強制綁定的，如有必要 Thrift、ProtoBuf 等高效的 RPC、序列化協議同樣可以作為替代方案）；社區活躍度、團隊技術儲備等。作為已經沒有團隊持續維護的開源項目，選擇Dubbo框架內部就必須要組建一個維護團隊，先不論你要準備要集成多少功能做多少改造，作為一個支撐所有工程正常運轉的基礎組件，問題的及時響應與解答、重大缺陷的及時修復能力就已足夠重要。

詳見：網易考拉海購Dubbok框架優化詳解

https://blog.csdn.net/karamos/article/details/80127976

鑒于服務發現對服務化架構的重要性，再補充一點：Dubbo 實踐通常以 ZooKeeper 為注冊中心（Dubbo 原生支持的 Redis 方案需要服務器時間同步，且性能消耗過大）。針對分布式領域著名的CAP理論（C 數據一致性，A 服務可用性，P 服務對網絡分區故障的容錯性），Zookeeper 保證的是 CP ，但對于服務發現而言，可用性比數據一致性更加重要 ，而 Eureka 設計則遵循 AP 原則 。

為什么選擇使用 Spring Cloud 而放棄了 Dubbo

可能大家會問，為什么選擇了使用 Dubbo 之后，而又選擇全面使用 Spring Cloud呢？其中有幾個原因：

1）從兩個公司的背景來談：Dubbo，是阿里巴巴服務化治理的核心框架，并被廣泛應用于中國各互聯網公司；Spring Cloud 是大名鼎鼎的 Spring 家族的產品。阿里巴巴是一個商業公司，雖然也開源了很多的頂級的項目，但從整體戰略上來講，仍然是服務于自身的業務為主。Spring 專注于企業級開源框架的研發，不論是在中國還是在世界上使用都非常廣泛，開發出通用、開源、穩健的開源框架就是他們的主業。

2）從社區活躍度這個角度來對比，Dubbo 雖然也是一個非常優秀的服務治理框架，并且在服務治理、灰度發布、流量分發這方面做的比 Spring Cloud 還好，除過當當網在基礎上增加了 REST 支持外，已有兩年多的時間幾乎都沒有任何更新了。在使用過程中出現問題，提交到 GitHub 的 Issue 也少有回復。

相反 Spring Cloud 自從發展到現在，仍然在不斷的高速發展，從 GitHub 上提交代碼的頻度和發布版本的時間間隔就可以看出，現在 Spring Cloud 即將發布2.0版本，到了后期會更加完善和穩定。

3) 從整個大的平臺架構來講，Dubbo 框架只是專注于服務之間的治理，如果我們需要使用配置中心、分布式跟蹤這些內容都需要自己去集成，這樣無形中使用 Dubbo 的難度就會增加。Spring Cloud 幾乎考慮了服務治理的方方面面，更有 Spring Boot 這個大將的支持，開發起來非常的便利和簡單。

4）從技術發展的角度來講，Dubbo 剛出來的那會技術理念還是非常先進，解決了各大互聯網公司服務治理的問題，中國的各中小公司也從中受益不少。經過了這么多年的發展，互聯網行業也是涌現了更多先進的技術和理念，Dubbo 一直停滯不前，自然有些掉隊，有時候我個人也會感到有點可惜，如果 Dubbo 一直沿著當初的那個路線發展，并且延伸到周邊，今天可能又是另一番景象了。

Spring 推出 Spring Boot/Cloud 也是因為自身的很多原因。Spring 最初推崇的輕量級框架，隨著不斷的發展也越來越龐大，隨著集成項目越來越多，配置文件也越來越混亂，慢慢的背離最初的理念。隨著這么多年的發展，微服務、分布式鏈路跟蹤等更多新的技術理念的出現，Spring 急需一款框架來改善以前的開發模式，因此才會出現 Spring Boot/Cloud 項目，我們現在訪問 Spring 官網，會發現 Spring Boot 和 Spring Cloud 已經放到首頁最重點突出的三個項目中的前兩個，可見 Spring 對這兩個框架的重視程度。

總結一下，Dubbo 曾經確實很牛逼，但是 Spring Cloud 是站在近些年技術發展之上進行開發，因此更具技術代表性。Spring Cloud 是整機，Dubbo 需要自己組裝；整機的性能有保證，組裝的機子更自由。

歡迎關注我的公眾號：：一點教程。獲得獨家整理的學習資源和日常干貨推送。

如果您對我的系列教程感興趣，也可以關注我的網站：yiidian.com

總結

以上是生活随笔為你收集整理的Spring Cloud与Dubbo详细对比的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。