比較spring cloud和dubbo，各自的優缺點是什麼

dubbo因爲是二進制的傳輸，佔用帶寬會更少

springCloud是http協議傳輸，帶寬會比較多，同時使用http協議通常會使用JSON報文，消耗會更大

dubbo的開發難度較大，緣由是dubbo的jar包依賴問題不少大型工程沒法解決

springcloud的接口協議約定比較自由且鬆散，須要有強有力的行政措施來限制接口無序升級

dubbo的註冊中心能夠選擇zk,redis等多種，springcloud的註冊中心只能用eureka或者自研

但若是我選，我會用springcloud。

從公司總體規劃：我不會選擇好久沒人維護的dubbo，重啓以後也未必是原班人馬

從程序員招聘難度：招springcloud的程序員會更好招，由於更新更炫

從系統結構簡易程序：springcloud的系統結構更簡單、「註冊+springmvc=springcloud」，而dubbo各類複雜的Url，protocol，register，invocation，dubbofilter，dubboSPI，dubbo序列化..........炫技的成分更多一些

從性能：dubbo的網絡消耗小於springcloud，可是在國內95%的公司內，網絡消耗不是什麼太大問題，若是真的成了問題，經過壓縮、二進制、高速緩存、分段降級等方法，很容易解

從開發難易度：dubbo的神坑是jar包依賴，開發階段難度極大，我曾經帶一個三十人的團隊，由於jar包升級問題，把每一個人的電腦都操做過，尤爲每一個人電腦的庫路徑、命令、快捷鍵、鍵盤，鼠標快慢都不同，那會兒我默默的在心中艹了dubbo發明者全家老少一百二十遍。springcloud比較自由，但帶來的問題是沒法「強力約束接口規範」，建議用行政方式解決，且咱們團隊的強力行政約束作的仍是比較好的，在接口管控層面比較強效，一個沒有行政組織能力的IT團隊真的是個廢渣，用什麼框架都很差使。

從後續改進：dubbo的改進是經過dubbofilter，不少東西沒有，須要本身繼承，如監控，如日誌，如限流，如追蹤。springcloud本身帶了不少監控、限流措施，可是功能可能和歐美習慣相同，國內須要進行適當改造，但更簡單，就是ServletFilter而已，可是總歸比dubbo多一些東西是好的

從配套措施：springcloud一直宣稱本身是「一套全方面的解決方案」。。。。。。我起初信了，後來發現上當了，實話說：有，可是不是很健全，100分打50的樣子，不少你還須要改造。而DUBBO相反，一直宣稱本身是「一套全方面的服務化方案」。。。。。。純服務化頂個鳥用，任何系統都是相輔相成配套的，一個完整的系統，要有前臺、中臺、後臺、前臺包括前端和交互，中臺包括交易、任務、數據，後臺包括財務、帳戶、管理...........單純的服務化解決不了「任何問題」，惟有體系才能解決。在這個層面，springcloud是個往「體系」方向發展的方案，而dubbo僅是個工具而已，二者相比，就比如始祖鳥與草履蟲的區別。

從技術實力層面：對比雙方的源碼，不得不說dubbo做者的技術能力要高於springCloud，而springBoot的做者技術能力要高於dubbo。即：springboot>dubbo>springcloud。我喜歡springboot這種大道至簡的風格，keep it simple and stupid。而dubbo好嘛......你先看看dubboSPI，再看看Protocol$Adpative裏面那一羣繞來繞去的瞎幾把繞的玩意兒，你會迅速判斷出：這羣屌絲在炫技。儘管dubbo從上之下分爲十層四五十個組件，第一感官上是哇塞好全面好偉大的樣子，但深刻以後你會以爲，這技術是很炫，設計的確實很全面，可是用不到，例如：請各位大神給我解釋一下，在zookeeper地址中，使用逗號分隔和分號分隔地址的區別。。。。。用途不大，可是代碼裏爲了這個就走向了「徹底不一樣」的一條分支。用俗語評價，就是「臃腫且無用代碼過多，在文檔裏還非得爲了這個說出123456來」。說完dubbo再說springCloud........它沒有技術含量，徹底沒有，就是一堆簡單組件拼裝在一塊兒，如configserver、eurekaserver、robin、feignClient、htstrix等，每一個都特別簡單，沒什麼技術含量，但我喜歡這種的，就喜歡這種大道至簡的簡單。

最後說springBoot，我要用「純粹」兩個字來評價這個框架，真的很純粹，而且從其代碼架構的整體思路一致性，目標的純粹性，具體模塊的乾淨利落，確實是個好框架，值得你們一讀。

從系統應用層面：在技術實力滿分一百能打85分的鄙人的眼中，dubbo和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框架優化詳解

 

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

 

做者：純潔的微笑
連接：https://www.zhihu.com/question/45413135/answer/128315403
來源：知乎
著做權歸做者全部。商業轉載請聯繫做者得到受權，非商業轉載請註明出處。

爲何選擇使用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是站在近些年技術發展之上進行開發，所以更具技術表明性。