:-: **Dubbo與SpringCloud對比** | |Dubbo| SpringCloud| | --- | --- | --- | |服務注冊中心| Zookeeper| Spring Cloud Netflix Eureka| |服務調用方式| RPC| REST API| |服務監控| Dubbo-monitor| Spring Boot Admin| |斷路器| 不完善| Spring Cloud Netflix Hystrix| |服務網關| 無| Spring Cloud Netflix Zuul| |分布式配置| 無| Spring Cloud Config| |服務跟蹤| 無| Spring Cloud Sleuth| |消息總線| 無| Spring Cloud Bus| |數據流 | 無| Spring Cloud Stream| |批量任務| 無| Spring Cloud Task| <mark>最大區別: SpringCloud拋棄了Dubbo的RPC通信，采用的是基于HTTP的REST方式。</mark> <br/> 嚴格來說，這兩種方式各有優劣。雖然從一定程度上來說，后者犧牲了服務調用的性能，但也避免了上面提到的原生RPC帶來的問題。而且REST相比RPC更為靈活，服務提供方和調用方的依賴只依靠一紙契約，不存在代碼級別的強依賴，這在強調快速演化的微服務環境下，顯得更加合適。 <br/> 品牌機與組裝機的區別： 很明顯，Spring Cloud的功能比DUBBO更加強大，涵蓋面更廣，而且作為Spring的拳頭項目，它也能夠與Spring Framework，Spring Boot、Spring Data、Spring Batch等其他Spring項目完美融合，這些對于微服務而言是至關重要的。使用Dubbo構建的微服務架構就像組裝電腦，各環節我們的選擇自由度很高，但是最終結果很有可能因為一條內存質量不行就點不亮了，總是讓人不怎么放心，但是如果你是一名高手，那這些都不是問題;而Spring Cloud就像品牌機，在Spring Source的整合下，做了大量的兼容性測試，保證了機器擁有更高的穩定性，但是如果要在使用非原裝組件外的東西，就需要對其基礎有足夠的了解。 <br/> 社區支持與更新力度： 最為重要的是，DUBBO停止了5年左右的更新，雖然2017.7重啟了。對于技術發展的新需求，需要由開發者自行拓展升級(比如當當網弄出了DubboX)，這對于很多想要采用微服務架構的中小軟件組織，顯然是不太合適的，中小公司沒有這么強大的技術能力去修改Dubbo源碼+周邊的一整套解決方案，并不是每一個公司都有阿里的大牛+真實的線上生產環境測試過。 <br/> Dubbo與SpringCloud總結如下（阿里中間件高級研發工程師劉軍的原話）： 關于Dubbo和 Spring Cloud 間的關系，我們在開源中國年終盛典的Dubbo分享中也作了簡單闡述，首先要明確的一點是Dubbo和Springcloud并不是完全的競爭關系，兩者所解決的問題域并不—樣: <mark>Dubbo的定位始終是—款RPC框架，Spring Cloud的目標是微服務架構下的—站式解決方案。如果非要比較的話，我覺得Dubbo 可以類比到Netflix oSS技術棧，而Spring Cloud集成了Netflix OSS作為分布式服務治理解決方案</mark>，但除此之外SpringCloud還提供了包括config、stream、security、sleuth 等等分布式問題解決方案。 <br/> 當前由于RPC協議、注冊中心元數據不匹配等問題，<mark>在面臨微服務基礎框架選型時Dubbo與Spring Cloud是只能二選一</mark>，這也是為什么大家總是拿Dubbo和Spring Cloud 做對比的原因之一。Dubbo 之后會積極錄求適配到SpringCloud 生態，比如作為Spring cloud的二進制通信方案來發揮Dubbo的性能優勢，或者Dubbo 通過模塊化以及對http的支持適配到Spring cloud 。