雖然Dubbo支持短連接大數(shù)據(jù)量的服務提供模式，但絕大多數(shù)情況下都是使用長連接小數(shù)據(jù)量的模式提供服務使用的。
所以，對于類似于電商等同步調用場景多并且能支撐搭建Dubbo 這套比較復雜環(huán)境的成本的產(chǎn)品而言，Dubbo 確實是一個可以考慮的選擇。
但如果產(chǎn)品業(yè)務中由于后臺業(yè)務邏輯復雜、時間長而導致異步邏輯比較多的話，可能Dubbo 并不合適。同時，對于人手不足的初創(chuàng)產(chǎn)品而言，這么重的架構維護起來也不是很方便。
Spring
Cloud由眾多子項目組成，如Spring
Cloud Config、Spring
Cloud Netflix、Spring Cloud Consul 等，提供了搭建分布式系統(tǒng)及微服務常用的工具，如配置管理、服務發(fā)現(xiàn)、斷路器、智能路由、微代理、控制總線、一次性token、全局鎖、選主、分布式會話和集群狀態(tài)等，滿足了構建微服務所需的所有解決方案。
比如使用Spring Cloud Config 可以實現(xiàn)統(tǒng)一配置中心，對配置進行統(tǒng)一管理；使用Spring Cloud Netflix 可以實現(xiàn)Netflix 組件的功能 - 服務發(fā)現(xiàn)（Eureka）、智能路由（Zuul）、客戶端負載均衡（Ribbon）。
但它并沒有重復造輪子，而是選用目前各家公司開發(fā)的比較成熟的、經(jīng)得住實踐考驗的服務框架（我們需要特別感謝Netflix ，這家很早就成功實踐微服務的公司，幾年前把自家?guī)缀跽麄€微服務框架棧貢獻給了社區(qū)，Spring Cloud主要是對Netflix開源組件的進一步封裝），通過Spring Boot 進行封裝集成并簡化其使用方式。
基于Spring Boot，意味著其使用方式如Spring Boot 簡單易用；能夠與Spring Framework、Spring Boot、Spring Data 等其他Spring 項目完美融合，意味著能從Spring獲得巨大的便利，意味著能減少已有項目的遷移成本。
其實，從社區(qū)活躍度和功能完整度，再對照業(yè)務需求和團隊狀況，基本可以確定如何選型。這里分享網(wǎng)易考拉海購實踐以及團隊選型的心聲：
當前開源上可選用的微服務框架主要有Dubbo、Spring Cloud等，鑒于Dubbo完備的功能和文檔且在國內被眾多大型互聯(lián)網(wǎng)公司選用，考拉自然也選擇了Dubbo作為服務化的基礎框架。
提起Spring Cloud，一些開發(fā)的第一印象是http+JSON的rest通信，性能上難堪重用，其實這也是一種誤讀。
微服務選型要評估以下幾點：內部是否存在異構系統(tǒng)集成的問題；備選框架功能特性是否滿足需求；http協(xié)議的通信對于應用的負載量會否真正成為瓶頸點（Spring Cloud也并不是和http+JSON強制綁定的，如有必要Thrift、protobuf等高效的RPC、序列化協(xié)議同樣可以作為替代方案）；社區(qū)活躍度、團隊技術儲備等。
作為已經(jīng)沒有團隊持續(xù)維護的開源項目，選擇Dubbo框架內部就必須要組建一個維護團隊，先不論你要準備要集成多少功能做多少改造，作為一個支撐所有工程正常運轉的基礎組件，問題的及時響應與解答、重大缺陷的及時修復能力就已足夠重要。
鑒于服務發(fā)現(xiàn)對服務化架構的重要性，再補充一點：Dubbo 實踐通常以ZooKeeper?為注冊中心（Dubbo 原生支持的Redis 方案需要服務器時間同步，且性能消耗過大）。
針對分布式領域著名的CAP理論（C——數(shù)據(jù)一致性，A——服務可用性，P——服務對網(wǎng)絡分區(qū)故障的容錯性），Zookeeper 保證的是CP ，但對于服務發(fā)現(xiàn)而言，可用性比數(shù)據(jù)一致性更加重要 ，而 Eureka 設計則遵循AP原則 。
為什么選擇使用Spring Cloud而放棄了Dubbo？
可能大家會問，為什么選擇了使用Dubbo之后，而又選擇全面使用Spring Cloud呢？其中有幾個原因：
1）從兩個公司的背景來談：Dubbo，是阿里巴巴服務化治理的核心框架，并被廣泛應用于中國各互聯(lián)網(wǎng)公司；Spring Cloud是大名鼎鼎的Spring家族的產(chǎn)品。
阿里巴巴是一個商業(yè)公司，雖然也開源了很多的頂級的項目，但從整體戰(zhàn)略上來講，仍然是服務于自身的業(yè)務為主。Spring專注于企業(yè)級開源框架的研發(fā)，不論是在中國還是在世界上使用都非常廣泛，開發(fā)出通用、開源、穩(wěn)健的開源框架就是他們的主業(yè)。
2）從社區(qū)活躍度這個角度來對比，Dubbo雖然也是一個非常優(yōu)秀的服務治理框架，并且在服務治理、灰度發(fā)布、流量分發(fā)這方面做的比Spring Cloud還好，除過當當網(wǎng)在基礎上增加了rest支持外，已有兩年多的時間幾乎都沒有任何更新了。在使用過程中出現(xiàn)問題，提交到github的Issue也少有回復。
相反Spring Cloud自從發(fā)展到現(xiàn)在，仍然在不斷的高速發(fā)展，從github上提交代碼的頻度和發(fā)布版本的時間間隔就可以看出，現(xiàn)在Spring Cloud即將發(fā)布2.0版本，到了后期會更加完善和穩(wěn)定。
3) 從整個大的平臺架構來講，dubbo框架只是專注于服務之間的治理，如果我們需要使用配置中心、分布式跟蹤這些內容都需要自己去集成，這樣無形中使用dubbo的難度就會增加。Spring Cloud幾乎考慮了服務治理的方方面面，更有Spring Boot這個大將的支持，開發(fā)起來非常的便利和簡單。
4）從技術發(fā)展的角度來講，Dubbo剛出來的那會技術理念還是非常先進，解決了各大互聯(lián)網(wǎng)公司服務治理的問題，中國的各中小公司也從中受益不少。
經(jīng)過了這么多年的發(fā)展，互聯(lián)網(wǎng)行業(yè)也是涌現(xiàn)了更多先進的技術和理念，Dubbo一直停滯不前，自然有些掉隊，有時候我個人也會感到有點可惜，如果Dubbo一直沿著當初的那個路線發(fā)展，并且延伸到周邊，今天可能又是另一番景象了。
Spring推出Spring Boot/Cloud也是因為自身的很多原因。Spring最初推崇的輕量級框架，隨著不斷的發(fā)展也越來越龐大，隨著集成項目越來越多，配置文件也越來越混亂，慢慢的背離最初的理念。
隨著這么多年的發(fā)展，微服務、分布式鏈路跟蹤等更多新的技術理念的出現(xiàn)，Spring急需一款框架來改善以前的開發(fā)模式，因此才會出現(xiàn)Spring Boot/Cloud項目，我們現(xiàn)在訪問Spring官網(wǎng)，會發(fā)現(xiàn)Spring Boot和Spring Cloud已經(jīng)放到首頁最重點突出的三個項目中的前兩個，可見Spring對這兩個框架的重視程度。
總結一下，dubbo曾經(jīng)確實很牛逼，但是Spring Cloud是站在近些年技術發(fā)展之上進行開發(fā)，因此更具技術代表性。
spring
cloud整機，dubbo需要自己組裝；整機的性能有保證，組裝的機子更自由。
小編分類整理了許多java進階學習材料和BAT面試題，需要資料的請加QQ群：731611386就能領取2019年java進階學習資料和BAT面試題以及《Effective Java》（第3版）電子版書籍。
