1、SpringCloud與Dubbo的區(qū)別

兩者都是現(xiàn)在主流的微服務(wù)框架，但卻存在不少差異：

初始定位不同：?SpringCloud定位為微服務(wù)架構(gòu)下的一站式解決方案；Dubbo 是 SOA 時代的產(chǎn)物，它的關(guān)注點主要在于服務(wù)的調(diào)用和治理

?生態(tài)環(huán)境不同：?SpringCloud依托于Spring平臺，具備更加完善的生態(tài)體系；而Dubbo一開始只是做RPC遠程調(diào)用，生態(tài)相對匱乏，現(xiàn)在逐漸豐富起來。

調(diào)用方式：?SpringCloud是采用Http協(xié)議做遠程調(diào)用，接口一般是Rest風(fēng)格，比較靈活；Dubbo是采用Dubbo協(xié)議，接口一般是Java的Service接口，格式固定。但調(diào)用時采用Netty的NIO方式，性能較好。

組件差異比較多，例如SpringCloud注冊中心一般用Eureka，而Dubbo用的是Zookeeper

SpringCloud生態(tài)豐富，功能完善，更像是品牌機，Dubbo則相對靈活，可定制性強，更像是組裝機。

SpringCloud：Spring公司開源的微服務(wù)框架，SpirngCloud 定位為微服務(wù)架構(gòu)下的一站式解決方案。

Dubbo：阿里巴巴開源的RPC框架，Dubbo 是 SOA 時代的產(chǎn)物，它的關(guān)注點主要在于服務(wù)的調(diào)用，流量分發(fā)、流量監(jiān)控和熔斷

兩者的生態(tài)對比：

????Spring Cloud 的功能很明顯比 Dubbo 更加強大，涵蓋面更廣，而且作為 Spring 的旗艦項目，它也能夠與 Spring Framework、Spring Boot、Spring Data、Spring Batch 等其他 Spring 項目完美融合，這些對于微服務(wù)而言是至關(guān)重要的。

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

2、dubbo和Feign遠程調(diào)用的差異

????Feign是SpringCloud中的遠程調(diào)用方式，基于成熟Http協(xié)議，所有接口都采用Rest風(fēng)格。因此接口規(guī)范更統(tǒng)一，而且只要符合規(guī)范，實現(xiàn)接口的微服務(wù)可以采用任意語言或技術(shù)開發(fā)。但受限于http協(xié)議本身的特點，請求和響應(yīng)格式臃腫，其通信效率相對會差一些。

????Dubbo框架默認采用Dubbo自定義通信協(xié)議，與Http協(xié)議一樣底層都是TCP通信。但是Dubbo協(xié)議自定義了Java數(shù)據(jù)序列化和反序列化方式、數(shù)據(jù)傳輸格式，因此Dubbo在數(shù)據(jù)傳輸性能上會比Http協(xié)議要好一些。

????不過這種性能差異除非是達極高的并發(fā)量級，否則無需過多考慮。

????Dubbo采用自定義的Dubbo協(xié)議實現(xiàn)遠程通信，是一種典型的RPC調(diào)用方案，而SpringCloud中使用的Feign是基于Rest風(fēng)格的調(diào)用方式。

????REST是一種架構(gòu)風(fēng)格，指的是一組架構(gòu)約束條件和原則。滿足這些約束條件和原則的應(yīng)用程序或設(shè)計就是 RESTful。Rest的風(fēng)格可以完全通過HTTP協(xié)議實現(xiàn)，使用 HTTP 協(xié)議處理數(shù)據(jù)通信。REST架構(gòu)對資源的操作包括獲取、創(chuàng)建、修改和刪除資源的操作正好對應(yīng)HTTP協(xié)議提供的GET、POST、PUT和DELETE方法。因此請求和想要過程只要遵循h(huán)ttp協(xié)議即可，更加靈活。SpringCloud中的Feign就是Rest風(fēng)格的調(diào)用方式。

????RPC【Remote Procedure Call】,遠程過程調(diào)用，就是像調(diào)用本地方法一樣調(diào)用遠程方法。

RPC一般要確定下面幾件事情：

數(shù)據(jù)傳輸方式：?多數(shù)RPC框架選擇TCP作為傳輸協(xié)議，性能比較好。

數(shù)據(jù)傳輸內(nèi)容：?請求方需要告知需要調(diào)用的函數(shù)的名稱、參數(shù)、等信息。

序列化方式：?客戶端和服務(wù)端交互時將參數(shù)或結(jié)果轉(zhuǎn)化為字節(jié)流在網(wǎng)絡(luò)中傳輸，那么數(shù)據(jù)轉(zhuǎn)化為字節(jié)流的或者將字節(jié)流轉(zhuǎn)換成能讀取的固定格式時就需要進行序列化和反序列化。因為有序列化和反序列化的需求，因此對數(shù)據(jù)傳輸格式有嚴格要求，不如Http靈活

Dubbo協(xié)議就是RPC的典型代表。

我們看看Dubbo協(xié)議和Feign的調(diào)用區(qū)別：

3、Eureka和Zookeeper注冊中心的區(qū)別

SpringCloud和Dubbo都支持多種注冊中心，不過目前主流來看SpringCloud用Eureka較多，Dubbo則以Zookeeper為主。兩者存在較大的差異：

從集群設(shè)計來看：?Eureka集群各節(jié)點平等，沒有主從關(guān)系，因此可能出現(xiàn)數(shù)據(jù)不一致情況；ZK為了滿足一致性，必須包含主從關(guān)系，一主多從。集群無主時，不對外提供服務(wù)

CAP原則來看：?Eureka滿足AP原則，為了保證整個服務(wù)可用性，犧牲了集群數(shù)據(jù)的一致性；而Zookeeper滿足CP原則，為了保證各節(jié)點數(shù)據(jù)一致性，犧牲了整個服務(wù)的可用性。

服務(wù)拉取方式來看：?Eureka采用的是服務(wù)主動拉取策略，消費者按照固定頻率（默認30秒）去Eureka拉取服務(wù)并緩存在本地；ZK中的消費者首次啟動到ZK訂閱自己需要的服務(wù)信息，并緩存在本地。然后監(jiān)聽服務(wù)列表變化，以后服務(wù)變更ZK會推送給消費者。