請問哪位大神比較過spring cloud和dubbo，各自的優缺點是什麼?

01-07

dubbo不限於dubbo本身，還有dubbox等。
要是大神還能談談微服務未來的發展趨勢那就更好了。

從項目的背景來看，Dubbo 國內用的公司挺多，國內影響力大，Spring Cloud 自然在國外影響力較大，所以這個來看不分伯仲了，畢竟都有大公司在使用。

從社區的活躍度來看，可以看下各自的Github託管項目來區分，Dubbo · GitHub 與 Spring Cloud · GitHub ，從更新頻率與更新時間來看 Spring Cloud 優於Dubbo，Dubbo基本不維護了。

從框架的完整度來看，Dubbo只是實現了服務治理（註冊發現等），而Spring Cloud下面有很多個子項目覆蓋了微服務架構下的方方面面，服務治理只是其中的一個方面，一定程度來說，Dubbo只是Spring Cloud Netflix中的一個子集。如果選擇Spring Cloud，基本上每個環節都已經有了對應的組件支持，可能有些也不一定能滿足你所有的需求，但是其活躍的社區與快速的迭代更新也會讓你沒有後顧之憂。

我司正在嘗試使用SpringCloud，有興趣可以進行交流。

簡而言之，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框架優化詳解

---------------------2017.9.8補充---------------

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

利益相關：

本回復有很多內容摘自網易雲基礎服務架構團隊著《雲原生應用架構實踐》，更多內容，譬如分散式事務的核心——分散式鎖的解析，可以參閱圖書。部分內容預覽可以參考這裡。

引用之前看到的一篇文章：

微服務架構的基礎框架選擇：Spring Cloud還是Dubbo【程序猿DD】

文章對這兩個框架進行了對比和分析，

希望對你有所幫助。

spring-boot有pivotal和netfix背書，是一套完整的企業級應用的開發方案，天然集成分散式雲架構spring-cloud，重點是有配套的更加完善的軟體基礎設施，但是實際編碼會有侵入性。

Dubbo有阿里巴巴背書，是一套RPC的半完善解決方案，配套的軟體基礎設施不全，好處是編碼環節基本沒有侵入性。

我們在用dubbo，朋友的公司也有在用的，面臨的問題也大致相似，問題定位、熔斷和監控方面的問題讓人沒有那麼的放心，最近打算嘗試在spring-cloud中尋找答案。

----------------------插播一條廣告----------------------

http://spring-cloud.io

http://bbs.spring-cloud.io

Spring Cloud與分散式系統

使用Spring Cloud Netflix技術棧實施微服務架構 - 王鴻飛的專欄 - 博客頻道 - CSDN.NET

Spring Cloud主要有以下特點：

1. 是一套完整的分散式系統解決方案，它的子項目涵蓋了所有實現布式系統所需要的基礎軟體設施

2. 基於Spring Boot, 使得開發部署極其簡單(加依賴，加註解，就能運行了)

要說Dubbo，算是Spring Cloud的一個子集好了,大致相當於Spring Cloud里的 Eureka + Feign + 1/2Hystrix

另外，我認為Spring Cloud極有可能是未來Java生態中微服務架構實現的標配

spring cloud 是一整套微服務的組件。從功能上來說spring cloud包含的功能遠多於dubbo。

dubbo目前處於不維護狀態。而spring cloud netflix社區活躍度高

兩者的坑都不少，dubbo不維護後，噹噹的dubbox坑稍微比dubbo的要少。

而spring cloud由於時間問題項目還不是特別成熟，包括新組件不斷的添加，集成方面坑也不少。

就拿一個簡單的spring cloud config來說，在配置中心修改配置文件，到Brixton.SR6版本才能正常推送給對應的server。

長遠角度上來看。spring cloud 還是挺不錯的。

最後

分享一下自己踩坑後構建的腳手架的項目。

基於 spring cloud 的一個微服務系統的實例項目包括如下功能：

配置管理、服務發現、熔斷,、動態路由、分散式跟蹤、應用監控

GitHub - yidongnan/spring-cloud-netflix-example: spring-cloud-netflix-example is a example for microservices system

spring Cloud是一個基於Spring Boot實現的雲應用開發工具，它為基於JVM的雲應用開發中的配置管理、服務發現、斷路器、智能路由、微代理、控制匯流排、全局鎖、決策競選、分散式會話和集群狀態管理等操作提供了一種簡單的開發方式。

spring boot 的優點是可以快速啟動，快速構建應用程序，而不需要太多的配置文件。

spring cloud 是分散式開發的解決方案，基於spring boot,在spring boot做較少的配置，

便可成為 spring cloud 中的一個微服務。

微服務架構本質上就是分散式服務化架構，微服務架構的流行，讓分散式事務問題日益突出！尤其是在訂單業務、資金業務等系統核心業務流程中，一定要有可靠的分散式事務解決方案來保證業務數據的可靠性和準確性。

目前比較多的解決方案有幾個：

一、結合MQ消息中間件實現的可靠消息最終一致性

二、TCC補償性事務解決方案

三、最大努力通知型方案

第一種方案：可靠消息最終一致性，需要業務系統結合MQ消息中間件實現，在實現過程中需要保證消息的成功發送及成功消費。即需要通過業務系統控制MQ的消息狀態

第二種方案：TCC補償性，分為三個階段TRYING-CONFIRMING-CANCELING。每個階段做不同的處理。

TRYING階段主要是對業務系統進行檢測及資源預留

CONFIRMING階段是做業務提交，通過TRYING階段執行成功後，再執行該階段。默認如果TRYING階段執行成功，CONFIRMING就一定能成功。

CANCELING階段是回對業務做回滾，在TRYING階段中，如果存在分支事務TRYING失敗，則需要調用CANCELING將已預留的資源進行釋放。

第三種方案：最大努力通知xing型，這種方案主要用在與第三方系統通訊時，比如：調用微信或支付寶支付後的支付結果通知。這種方案也是結合MQ進行實現，例如：通過MQ發送http請求，設置最大通知次數。達到通知次數後即不再通知。

具體的案例你也可以參考下這篇博客，它上面有完整的電商系統分散式事務實現案例：http://www.roncoo.com/article/detail/124243

兩者不能直接進行對比，dubbo只是作為服務治理的rpc層，而Spring Cloud 提供了一整套分散式服務開發的工具，從邊緣服務的Zuul，到服務發現Eureka ，再到hystrix 熔斷機制，是一套完整的生態，但是我覺得這裡面最有幫助的可能是hystrix ，它提供了完整的熔斷機制，可以很輕易的引入現有系統。

有關微服務架構的討論最近一直很火。近期也看到一些分享Spring Cloud的相關實施經驗，這對於最近正在整理Spring Cloud相關套件內容與實例應用的我而言，還是有不少激勵的。目前，Spring Cloud在國內的知名度並不高，與一些互聯網公司的架構師、技術VP或者CTO在交流時，有些甚至還不知道該項目的存在。這也許與國內的開源服務治理框架Dubbo有一定的關係，除了Dubbo本身較為完善的中文文檔之外，不少科技公司的架構師均出自阿里系，所以就目前情況看，短期國內還是Dubbo的天下。

那麼第一次實施微服務架構時，我們應該選擇哪個基礎框架更好呢？我個人有一些觀點，如有不妥，還請包涵。

1背景

Dubbo，是阿里巴巴服務化治理的核心框架，並被廣泛應用於阿里巴巴集團的各成員站點。阿里巴巴近幾年對開源社區的貢獻不論在國內還是國外都是引人注目的，比如：JStorm捐贈給Apache並加入Apache基金會等，為中國互聯網人爭足了面子，使得阿里巴巴在國人眼裡已經從電商升級為一家科技公司了。

Spring Cloud，從命名我們就可以知道，它是Spring Source的產物，Spring社區的強大背書可以說是Java企業界最有影響力的組織了，除了Spring Source之外，還有Pivotal和Netfix是其強大的後盾與技術輸出。其中Netflix開源的整套微服務架構套件是Spring Cloud的核心。

小結：如果拿Dubbo與Netflix套件做對比，前者在國內影響力較大，後者在國外影響力較大，但是若要與Spring Cloud做對比，由於Spring Source的加入，在背書上，Spring Cloud略勝一籌。不過，英雄不問出處，在背景這一點上，不能作為選擇框架的主要因素，當您一籌莫展的時候，可以作為參考依據。

2社區活躍度

我們選擇一個開源框架，社區的活躍度是我們極為關注的一個要點。社區越活躍，解決問題的速度越快，框架也會越來越完善，不然當我們碰到問題，就不得不自己解決。而對於團隊來說，也就意味著我們不得不自己去維護框架的源碼，這對於團隊來說也將會是一個很大的負擔。

小結：在社區活躍度上，Spring Cloud毋庸置疑的優於Dubbo，這對於沒有大量精力與財力維護這部分開源內容的團隊來說，Spring Cloud會是更優的選擇。

3架構完整度

或許很多人會說Spring Cloud和Dubbo的對比有點不公平，Dubbo只是實現了服務治理，而Spring Cloud下面有17個子項目（可能還會新增）分別覆蓋了微服務架構下的方方面面，服務治理只是其中的一個方面，一定程度來說，Dubbo只是Spring Cloud Netflix中的一個子集。但是在選擇框架上，方案完整度恰恰是一個需要重點關注的內容。

根據Martin Fowler對微服務架構的描述中，雖然該架構相較於單體架構有模塊化解耦、可獨立部署、技術多樣性等諸多優點，但是由於分散式環境下解耦，也帶出了不少測試與運維複雜度。

根據微服務架構在各方面的要素，看看Spring Cloud和Dubbo都提供了哪些支持。

Dubbo Spring Cloud

服務註冊中心 Zookeeper Spring Cloud Netflix Eureka

服務調用方式 RPC REST API

服務網關無 Spring Cloud Netflix Zuul

斷路器不完善 Spring Cloud Netflix Hystrix

分散式配置無 Spring Cloud Config

服務跟蹤無 Spring Cloud Sleuth

消息匯流排無 Spring Cloud Bus

數據流無 Spring Cloud Stream

批量任務無 Spring Cloud Task

…… …… ……

以上列舉了一些核心部件，大致可以理解為什麼之前說Dubbo只是類似Netflix的一個子集了吧。當然這裡需要申明一點，Dubbo對於上表中總結為「無」的組件不代表不能實現，而只是Dubbo框架自身不提供，需要另外整合以實現對應的功能，比如：

分散式配置：可以使用淘寶的diamond、百度的disconf來實現分散式配置管理。但是Spring Cloud中的Config組件除了提供配置管理之外，由於其存儲可以使用git，因此它天然的實現了配置內容的版本管理，可以完美的與應用版本管理整合起來。

服務跟蹤：可以使用京東開源的Hydra

批量任務：可以使用噹噹開源的Elastic-Job

……

雖然，Dubbo自身只是實現了服務治理的基礎，其他為保證集群安全、可維護、可測試等特性方面都沒有很好的實現，但是幾乎大部分關鍵組件都能找到第三方開源來實現，這些組件主要來自於國內各家大型互聯網企業的開源產品。

RPC vs REST

另外，由於Dubbo是基礎框架，其實現的內容對於我們實施微服務架構是否合理，也需要我們根據自身需求去考慮是否要修改，比如Dubbo的服務調用是通過RPC實現的，但是如果仔細拜讀過Martin Fowler的 microservices 一文，其定義的服務間通信是HTTP協議的REST API。那麼這兩種有何區別呢？

先來說說，使用Dubbo的RPC來實現服務間調用的一些痛點：

服務提供方與調用方介面依賴方式太強：我們為每個微服務定義了各自的service抽象介面，並通過持續集成發布到私有倉庫中，調用方應用對微服務提供的抽象介面存在強依賴關係，因此不論開發、測試、集成環境都需要嚴格的管理版本依賴，才不會出現服務方與調用方的不一致導致應用無法編譯成功等一系列問題，以及這也會直接影響本地開發的環境要求，往往一個依賴很多服務的上層應用，每天都要更新很多代碼並install之後才能進行後續的開發。若沒有嚴格的版本管理制度或開發一些自動化工具，這樣的依賴關係會成為開發團隊的一大噩夢。而REST介面相比RPC更為輕量化，服務提供方和調用方的依賴只是依靠一紙契約，不存在代碼級別的強依賴，當然REST介面也有痛點，因為介面定義過輕，很容易導致定義文檔與實際實現不一致導致服務集成時的問題，但是該問題很好解決，只需要通過每個服務整合swagger，讓每個服務的代碼與文檔一體化，就能解決。所以在分散式環境下，REST方式的服務依賴要比RPC方式的依賴更為靈活。

服務對平台敏感，難以簡單復用：通常我們在提供對外服務時，都會以REST的方式提供出去，這樣可以實現跨平台的特點，任何一個語言的調用方都可以根據介面定義來實現。那麼在Dubbo中我們要提供REST介面時，不得不實現一層代理，用來將RPC介面轉換成REST介面進行對外發布。若我們每個服務本身就以REST介面方式存在，當要對外提供服務時，主要在API網關中配置映射關係和許可權控制就可實現服務的復用了。

相信這些痛點也是為什麼噹噹網在dubbox（基於Dubbo的開源擴展）中增加了對REST支持的原因之一。

小結：Dubbo實現了服務治理的基礎，但是要完成一個完備的微服務架構，還需要在各環節去擴展和完善以保證集群的健康，以減輕開發、測試以及運維各個環節上增加出來的壓力，這樣才能讓各環節人員真正的專註於業務邏輯。而Spring Cloud依然發揚了Spring Source整合一切的作風，以標準化的姿態將一些微服務架構的成熟產品與框架揉為一體，並繼承了Spring Boot簡單配置、快速開發、輕鬆部署的特點，讓原本複雜的架構工作變得相對容易上手一些（如果您讀過我之前關於Spring Cloud的一些核心組件使用的文章，應該能體會這些讓人興奮而激動的特性，傳送門）。所以，如果選擇Dubbo請務必在各個環節做好整套解決方案的準備，不然很可能隨著服務數量的增長，整個團隊都將疲於應付各種架構上不足引起的困難。而如果選擇Spring Cloud，相對來說每個環節都已經有了對應的組件支持，可能有些也不一定能滿足你所有的需求，但是其活躍的社區與高速的迭代進度也會是你可以依靠的強大後盾。

4文檔質量

Dubbo的文檔可以說在國內開源框架中算是一流的，非常全，並且講解的也非常深入，由於版本已經穩定不再更新，所以也不太會出現不一致的情況，另外提供了中文與英文兩種版本，對於國內開發者來說，閱讀起來更加容易上手，這也是dubbo在國內更火一些的原因吧。

Spring Cloud由於整合了大量組件，文檔在體量上自然要比dubbo多很多，文檔內容上還算簡潔清楚，但是更多的是偏向整合，更深入的使用方法還是需要查看其整合組件的詳細文檔。另外由於Spring Cloud基於Spring Boot，很多例子相較於傳統Spring應用要簡單很多（因為自動化配置，很多內容都成了約定的默認配置），這對於剛接觸的開發者可能會有些不適應，比較建議了解和學習Spring Boot之後再使用Spring Cloud，不然可能會出現很多一知半解的情況。

小結：雖然Spring Cloud的文檔量大，但是如果使用Dubbo去整合其他第三方組件，實際也是要去閱讀大量第三方組件文檔的，所以在文檔量上，我覺得區別不大。對於文檔質量，由於Spring Cloud的迭代很快，難免會出現不一致的情況，所以在質量上我認為Dubbo更好一些。而對於文檔語言上，Dubbo自然對國內開發團隊來說更有優勢。

總結

通過上面再幾個環節上的分析，相信大家對Dubbo和Spring Cloud有了一個初步的了解。就我個人對這兩個框架的使用經驗和理解，打個不恰當的比喻：使用Dubbo構建的微服務架構就像組裝電腦，各環節我們的選擇自由度很高，但是最終結果很有可能因為一條內存質量不行就點不亮了，總是讓人不怎麼放心，但是如果你是一名高手，那這些都不是問題；而Spring Cloud就像品牌機，在Spring Source的整合下，做了大量的兼容性測試，保證了機器擁有更高的穩定性，但是如果要在使用非原裝組件外的東西，就需要對其基礎有足夠的了解。

spring cloud強太多了，功能應有盡有，性能略平庸但是肯定夠用。實在要用rpc的，或者想追求高性能的，也麻煩去試試grpc之類。技術要常更新，還抱著老黃曆天天dubbo dubbo的，未來被淘汰就不要怨天尤人了。

為什麼選擇使用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需要自己組裝；整機的性能有保證，組裝的機子更自由。

摘錄子我的文章：中小型互聯網公司微服務實踐-經驗和教訓

怒答。

先說應用場景，兩者都是分散式服務治理相關的組件。都具備了服務註冊、發現、路由、負載均衡等能力。

區別之一就是用的時候感覺springcloud集成了springcboot，且與docker集成起來也很方便，dubbo則是一個中規中矩的服務治理框架。

其他當年的異同如實現啦性能啦之後整理一下繼續回答。

歡迎大家一起討論。

這個問題就像多年以前大家比較 Spring 和 EJB，最終EJB因為太重而逐漸走向消亡。

Dubbo是阿里巴巴開源的分散式服務化治理框架（微服務框架），久經阿里巴巴電商平台的大規模複雜業務的高並發考驗，到目前為止Dubbo仍然是開源界中體系最完善的服務化治理框架，因此Dubbo被國內大量的的互聯網公司和專統企業使用，國內使用Dubbo的企業有：阿里巴巴、京東、噹噹、攜程、去哪兒、搜狐、南方航空、中軟國際、軟通動力、各大電信運營商等；Spring Cloud是一個基於Spring Boot來實現的一系列工具框架的集合體。

在微服務架構中，Spring Cloud為基於JVM的雲應用開發中的服務發現、負載均衡、斷路器、智能路由、配置管理、控制匯流排等等操作提供了一種簡單、快捷的開發方式。 Spring Cloud包含了多個子項目，比如：Spring Cloud Netflix 、Spring Cloud Config、Spring Cloud Stream、Spring Cloud Bus、Spring Cloud Sleuth等項目。

從項目的背景來看，Dubbo 國內用的公司挺多，國內影響力大，Spring Cloud 自然在國外影響力較大，所以這個來看不分伯仲了，畢竟都有大公司在使用。

從框架的完整度來看，Dubbo只是實現了服務治理（註冊，發現等），而Spring Cloud下面有很多個子項目覆蓋了微服務架構下的方方面面，服務治理只是其中的一個方面，一定程度來說，Dubbo只是Spring Cloud Netflix中的一個子集。如果選擇Spring Cloud，基本上每個環節都已經有了對應的組件支持，可能有些也不一定能滿足你所有的需求，但是其活躍的社區與快速的迭代更新也會讓你沒有後顧之憂。

dubbo是可數集，springcloud是連續統。

dubbo的原理很清晰

Spring Cloud 是Pivotal提供的用於簡化分散式系統構建的工具集。Spring Cloud引入了雲平台連接器（Cloud Connector）和服務連接器（Service Connector）的概念。雲平台連接器是一個介面，需要由雲平台提供者進行實現，以便庫中的其他模塊可以與該雲平台協同工作。

Spring Cloud最重要的一點是它可以和Spring Boot一起工作，Spring Boot可以幫助開發者更容易地創建基於Spring的應用程序和服務。

從Spring Boot項目名稱中的Boot就可以看出來，Spring Boot的作用在於創建和啟動新的基於Spring框架的項目。Spring Boot會選擇最適合的Spring子項目和第三方開源庫進行整合。大部分Spring Boot應用只需要非常少的配置就可以快速運行起來。

看好spring cloud

總之還是成本的問題。

已經到了要構建成一個分散式系統，自然會涉及到緩存、消息、rpc等，以及維護成本。

每一個模塊要能用好，自然有深入學習，對程序員來說，在&<再包裝一層&>上面去，增加學習成本和維護的不可控性。

所以&<微服務&>不是一套技術組價的包裝，更應側重在研發的流程上，如何能從整體提高效率。

沒有可比性，dubbo首先不再被維護了，然後dubbo和spring cloud相比，只是相當於spring cloud 中的一個組件。

spring cloud = zk + dubbo + deploy

主要是架構上的難點和分散式事務，大家可有經驗

dubbo都不維護了還有用的必要嗎？