spring cloud和dubbo的優(yōu)缺點(diǎn)以及不同之處

SpringCloud簡(jiǎn)介

SpringCloud是一系列框架的有序集合。它利用Spring Boot的開發(fā)便利性巧妙地簡(jiǎn)化了分布式系統(tǒng)基礎(chǔ)設(shè)施的開發(fā)，如服務(wù)發(fā)現(xiàn)注冊(cè)、配置中心、消息總線、負(fù)載均衡、斷路器、數(shù)據(jù)監(jiān)控等，都可以用Spring Boot的開發(fā)風(fēng)格做到一鍵啟動(dòng)和部署。Spring Cloud并沒有重復(fù)制造輪子，它只是將各家公司開發(fā)的比較成熟、經(jīng)得起實(shí)際考驗(yàn)的服務(wù)框架組合起來，通過Spring Boot風(fēng)格進(jìn)行再封裝屏蔽掉了復(fù)雜的配置和實(shí)現(xiàn)原理，最終給開發(fā)者留出了一套簡(jiǎn)單易懂、易部署和易維護(hù)的分布式系統(tǒng)開發(fā)工具包。

Dubbo簡(jiǎn)介

Dubbo是阿里巴巴公司開源的一個(gè)高性能優(yōu)秀的 服務(wù)框架，使得應(yīng)用可通過高性能的 RPC 實(shí)現(xiàn)服務(wù)的輸 出和輸入功能，可以和 Spring框架無縫集成。

Remoting: 網(wǎng)絡(luò)通信框架，實(shí)現(xiàn)了 sync-over-async 和 request-response 消息機(jī)制.

RPC: 一個(gè) 遠(yuǎn)程過程調(diào)用的抽象，支持 負(fù)載均衡、 容災(zāi)和 集群功能

Registry: 服務(wù)目錄框架用于服務(wù)的注冊(cè)和服務(wù)事件發(fā)布和訂閱

傳輸：
Dubbo由于是二進(jìn)制的傳輸，占用帶寬會(huì)更少；
Spring Cloud是http協(xié)議傳輸，帶寬會(huì)比較多，同時(shí)使用http協(xié)議一般會(huì)使用JSON報(bào)文，消耗會(huì)更大。但是在國內(nèi)95%的公司內(nèi)，網(wǎng)絡(luò)消耗不是什么太大問題，如果真的成了問題，通過壓縮、二進(jìn)制、高速緩存、分段降級(jí)等方法，很容易解。

開發(fā)難度：
Dubbo的開發(fā)難度較大，原因是dubbo的jar包依賴問題很多大型工程無法解決；
Spring Cloud的接口協(xié)議約定比較自由且松散，需要有強(qiáng)有力的行政措施來限制接口無序升級(jí)

后續(xù)改進(jìn)：
Dubbo通過dubbofilter，很多東西沒有，需要自己繼承，如監(jiān)控，如日志，如限流，如追蹤
Spring Cloud自己帶了很多監(jiān)控、限流措施，但是功能可能和歐美習(xí)慣相同，國內(nèi)需要進(jìn)行適當(dāng)改造，但更簡(jiǎn)單，就是ServletFilter而已，但是總歸比dubbo多一些東西是好的；

注冊(cè)中心：
Dubbo的注冊(cè)中心可以選擇zk,redis等多種；
Spring Cloud:的注冊(cè)中心只能用eureka或者自研；

配置中心：
dubbo：如果我們使用配置中心、分布式跟蹤這些內(nèi)容都需要自己去集成，無形中增加了使用難度。
Spring Cloud：提供了微服務(wù)的一整套解決方案：服務(wù)發(fā)現(xiàn)注冊(cè)、配置中心、消息總線、負(fù)載均衡、斷路器、數(shù)據(jù)監(jiān)控等

核心部件的比較：
Dubbo：
Provider：暴露服務(wù)的提供方，可以通過 jar 或者容器的方式啟動(dòng)服務(wù)。
Consumer：調(diào)用遠(yuǎn)程服務(wù)的服務(wù)消費(fèi)方。
Registry：服務(wù)注冊(cè)中心和發(fā)現(xiàn)中心。
Monitor：統(tǒng)計(jì)服務(wù)和調(diào)用次數(shù)，調(diào)用時(shí)間監(jiān)控中心。（Dubbo 的控制臺(tái)頁面中可以顯示，目前只有一個(gè)簡(jiǎn)單版本。）
Container：服務(wù)運(yùn)行的容器。
Spring Cloud：
Service Provider： 暴露服務(wù)的提供方。
Service Consumer：調(diào)用遠(yuǎn)程服務(wù)的服務(wù)消費(fèi)方。
EureKa Server： 服務(wù)注冊(cè)中心和服務(wù)發(fā)現(xiàn)中心。

架構(gòu)的完整度：
Dubbo只是實(shí)現(xiàn)了服務(wù)治理；
Spring Cloud下面有17個(gè)子項(xiàng)目（可能還會(huì)新增）分別覆蓋了微服務(wù)架構(gòu)下的方方面面，服務(wù)治理只是其中的一個(gè)方面；
一定程度來說，Dubbo只是Spring Cloud Netflix中的一個(gè)子集。

服務(wù)依賴方式：
Dubbo：服務(wù)提供方與消費(fèi)方通過接口的方式依賴，服務(wù)調(diào)用設(shè)計(jì)如下：
Interface 層：服務(wù)接口層，定義了服務(wù)對(duì)外提供的所有接口。
Molel 層：服務(wù)的 DTO 對(duì)象層。
Business層：業(yè)務(wù)實(shí)現(xiàn)層，實(shí)現(xiàn) Interface 接口并且和 DB 交互。
因此需要為每個(gè)微服務(wù)定義各自的 Interface 接口，并通過持續(xù)集成發(fā)布到私有倉庫中。調(diào)用方應(yīng)用對(duì)微服務(wù)提供的抽象接口存在強(qiáng)依賴關(guān)系，開發(fā)、測(cè)試、集成環(huán)境都需要嚴(yán)格的管理版本依賴。

通過 maven 的 install & deploy 命令把 Interface 和 Model 層發(fā)布到倉庫中，服務(wù)調(diào)用方只需要依賴 Interface 和 Model 層即可。在開發(fā)調(diào)試階段只發(fā)布 Snapshot 版本，等到服務(wù)調(diào)試完成再發(fā)布；Release 版本，通過版本號(hào)來區(qū)分每次迭代的版本。通過 xml 配置方式即可接入 Dubbo，對(duì)程序無***。
總之：服務(wù)提供方與消費(fèi)方通過接口的方式依賴，Dubbo 服務(wù)依賴略重，需要有完善的版本管理機(jī)制，但是程序***少。

Spring Cloud：
服務(wù)提供方和服務(wù)消費(fèi)方通過 Json 方式交互，因此只需要定義好相關(guān) Json 字段即可，消費(fèi)方和提供方無接口依賴。通過注解方式來實(shí)現(xiàn)服務(wù)配置，對(duì)于程序有一定***。
通過 Json 交互，省略了版本管理的問題，但是具體字段含義需要統(tǒng)一管理，自身 Rest API 方式交互，為跨平臺(tái)調(diào)用奠定了基礎(chǔ)。

總體：
Dubbo：使用Dubbo構(gòu)建的微服務(wù)架構(gòu)就像組裝電腦，各環(huán)節(jié)我們的選擇自由度很高，但是最終結(jié)果很有可能因?yàn)橐粭l內(nèi)存質(zhì)量不行就點(diǎn)不亮了，總是讓人不怎么放心，但是如果你是一名高手，那這些都不是問題；
Spring Cloud就像品牌機(jī)，在Spring Source的整合下，做了大量的兼容性測(cè)試，保證了機(jī)器擁有更高的穩(wěn)定性，但是如果要在使用非原裝組件外的東西，就需要對(duì)其基礎(chǔ)有足夠的了解。

Dubbo
優(yōu)點(diǎn)：
1.支持各種通信協(xié)議，而且消費(fèi)方和服務(wù)方使用長鏈接方式交互，通信速度上略勝 ；
2.采用rpc方式，性能上比Spring Cloud的rpc更好；
3.dubbo的網(wǎng)絡(luò)消耗小于springcloud
缺點(diǎn)：
1.如果我們使用配置中心、分布式跟蹤這些內(nèi)容都需要自己去集成;
2.開發(fā)難度較大，原因是dubbo的jar包依賴問題很多大型工程無法解決；
3.

Spring Cloud 案例 www.1b23.com：
優(yōu)點(diǎn)：
1、產(chǎn)出于Spring大家族，Spring在企業(yè)級(jí)開發(fā)框架中來頭很大，可以保證后續(xù)的更新、完善。
2、spring cloud社區(qū)活躍，教程豐富，遇到問題很容易找到解決方案；
3、spring cloud功能比dubbo更加完善；
5、spring cloud采用rest訪問方式，rest的技術(shù)無關(guān)性使用效果更棒；
6、spring cloud輕輕松松幾行代碼就完成了熔斷、均衡負(fù)責(zé)、服務(wù)中心的各種平臺(tái)功能；
7、從公司招聘工程師方面，spring cloud更有優(yōu)勢(shì)，因?yàn)槠浼夹g(shù)更新更炫；
8、提供了微服務(wù)的一整套解決方案：服務(wù)發(fā)現(xiàn)注冊(cè)、配置中心、消息總線、負(fù)載均衡、斷路器、數(shù)據(jù)監(jiān)控等；作為一個(gè)微服務(wù)治理的大家伙，考慮的很全面，幾乎服務(wù)治理的方方面面都考慮到了，方便開發(fā)開箱即用；

缺點(diǎn)：
1.如果對(duì)于系統(tǒng)的響應(yīng)時(shí)間有嚴(yán)格要求，長鏈接更合適。
2.接口協(xié)議約定比較自由且松散，需要有強(qiáng)有力的行政措施來限制接口無序升級(jí)