Spring Cloud與Dubbo詳細對比

轉自：CSDN，做者：Crazy曉楓 http://www.javashuo.com/article/p-bazfacgl-bc.html

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框架優化詳解 http://www.javashuo.com/article/p-rnhpwmjo-ko.html

鑑於服務發現對服務化架構的重要性，再補充一點：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