今天就跟大家聊聊有關(guān)springboot中SpringCloud和Dubbo的區(qū)別及各自的優(yōu)缺點(diǎn)是什么，可能很多人都不太了解，為了讓大家更加了解，小編給大家總結(jié)了以下內(nèi)容，希望大家根據(jù)這篇文章可以有所收獲。

創(chuàng)新互聯(lián)公司專業(yè)IDC數(shù)據(jù)服務(wù)器托管提供商，專業(yè)提供成都服務(wù)器托管，服務(wù)器租用，雅安機(jī)房托管，雅安機(jī)房托管，成都多線服務(wù)器托管等服務(wù)器托管服務(wù)。

我們先從 Nginx 說起，了解為什么需要微服務(wù)。最初的服務(wù)化解決方案是給相同服務(wù)提供一個(gè)統(tǒng)一的域名，然后服務(wù)調(diào)用者向這個(gè)域發(fā)送 HTTP 請求，由 Nginx 負(fù)責(zé)請求的分發(fā)和跳轉(zhuǎn)。
這種架構(gòu)存在很多問題：Nginx 作為中間層，在配置文件中耦合了服務(wù)調(diào)用的邏輯，這削弱了微服務(wù)的完整性，也使得 Nginx 在一定程度上變成了一個(gè)重量級的 ESB。圖中標(biāo)識出了 Nginx 的轉(zhuǎn)發(fā)信息流走向。

服務(wù)的信息分散在各個(gè)系統(tǒng)，無法統(tǒng)一管理和維護(hù)。每一次的服務(wù)調(diào)用都是一次嘗試，服務(wù)消費(fèi)方并不知道有哪些實(shí)例在給他們提供服務(wù)。這帶來了一些問題：

• 無法直觀地看到服務(wù)提供方和服務(wù)消費(fèi)方當(dāng)前的運(yùn)行狀況與通信頻率；

• 消費(fèi)方的失敗重發(fā)、負(fù)載均衡等都沒有統(tǒng)一策略，這加大了開發(fā)每個(gè)服務(wù)的難度，不利于快速演化。

為了解決上面的問題，我們需要一個(gè)現(xiàn)成的中心組件對服務(wù)進(jìn)行整合，將每個(gè)服務(wù)的信息匯總，包括服務(wù)的組件名稱、地址、數(shù)量等。
服務(wù)的調(diào)用方在請求某項(xiàng)服務(wù)時(shí)首先通過中心組件獲取提供服務(wù)的實(shí)例信息（IP、端口等），再通過默認(rèn)或自定義的策略選擇該服務(wù)的某一提供方直接進(jìn)行訪問，所以考慮引入 Dubbo。
Dubbo 是阿里開源的一個(gè) SOA 服務(wù)治理解決方案，文檔豐富，在國內(nèi)的使用度非常高。圖 2 為 Dubbo 的基本架構(gòu)圖，使用 Dubbo 構(gòu)建的微服務(wù)已經(jīng)可以較好地解決上面提到的問題。

從圖 2 中，可以看出以下幾點(diǎn)：

• 調(diào)用中間層變成了可選組件，消費(fèi)方可以直接訪問服務(wù)提供方；

• 服務(wù)信息被集中到 Registry 中，形成了服務(wù)治理的中心組件；

• 通過 Monitor 監(jiān)控系統(tǒng)，可以直觀地展示服務(wù)調(diào)用的統(tǒng)計(jì)信息；

• 服務(wù)消費(fèi)者可以進(jìn)行負(fù)載均衡、服務(wù)降級的選擇。

但是對于微服務(wù)架構(gòu)而言，Dubbo 并不是十全十美的，也有一些缺陷，比如：

• Registry 嚴(yán)重依賴第三方組件（ZooKeeper 或者 redis），當(dāng)這些組件出現(xiàn)問題時(shí)，服務(wù)調(diào)用很快就會中斷。

• Dubbo 只支持 RPC 調(diào)用。這使得服務(wù)提供方與調(diào)用方在代碼上產(chǎn)生了強(qiáng)依賴，服務(wù)提供方需要不斷將包含公共代碼的 Jar 包打包出來供消費(fèi)方使用。一旦打包出現(xiàn)問題，就會導(dǎo)致服務(wù)調(diào)用出錯(cuò)。

筆者認(rèn)為，Dubbo 和 Spring Cloud 并不是完全的競爭關(guān)系，兩者所解決的問題域并不一樣。
Dubbo 的定位始終是一款 RPC 框架，而 Spring Cloud 的目標(biāo)是微服務(wù)架構(gòu)下的一站式解決方案。如果非要比較的話，Dubbo 可以類比到 Netflix OSS 技術(shù)棧，而 Spring Cloud 集成了 Netflix OSS 作為分布式服務(wù)治理解決方案，但除此之外 Spring Cloud 還提供了配置、消息、安全、調(diào)用鏈跟蹤等分布式問題解決方案。
當(dāng)前由于 RPC 協(xié)議、注冊中心元數(shù)據(jù)不匹配等問題，在面臨微服務(wù)基礎(chǔ)框架選型時(shí) Dubbo 與 Spring Cloud 只能二選一，這也是大家總是拿 Dubbo 和 Spring Cloud 做對比的原因之一。
Dubbo 已經(jīng)適配到 Spring Cloud 生態(tài)，比如作為 Spring Cloud 的二進(jìn)制通信方案來發(fā)揮 Dubbo 的性能優(yōu)勢，Dubbo 通過模塊化以及對 HTTP 的支持適配到 Spring Cloud。

Spring Cloud 好在哪里

作為新一代的服務(wù)框架，Spring Cloud 提出的口號是開發(fā)“面向云的應(yīng)用程序”，它為微服務(wù)架構(gòu)提供了更加全面的技術(shù)支持。結(jié)合我們一開始提到的微服務(wù)的訴求，參見表 1，把Spring Cloud 與 Dubbo 進(jìn)行一番對比。

表 1 Spring Cloud與Dubbo功能對比

Spring Cloud 拋棄了 Dubbo 的 RPC 通信，采用的是基于 HTTP 的 REST 方式。嚴(yán)格來說，這兩種方式各有優(yōu)劣。雖然從一定程度上來說，后者犧牲了服務(wù)調(diào)用的性能，但也避免了上面提到的原生 RPC 帶來的問題。而且 REST 相比 RPC 更為靈活，服務(wù)提供方和調(diào)用方，不存在代碼級別的強(qiáng)依賴，這在強(qiáng)調(diào)快速演化的微服務(wù)環(huán)境下顯得更加合適。

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

前面提到，微服務(wù)背后一個(gè)重要的理念就是持續(xù)集成、快速交付，而在服務(wù)內(nèi)部使用一個(gè)統(tǒng)一的技術(shù)框架，顯然比將分散的技術(shù)組合到一起更有效率。
更重要的是，相比于 Dubbo，它是一個(gè)正在持續(xù)維護(hù)的、社區(qū)更加火熱的開源項(xiàng)目，這就可以保證使用它構(gòu)建的系統(tǒng)持續(xù)地得到開源力量的支持。

下面列舉 Spring Cloud 的幾個(gè)優(yōu)勢。

• Spring Cloud 來源于 Spring，質(zhì)量、穩(wěn)定性、持續(xù)性都可以得到保證。

• Spirng Cloud 天然支持 Spring Boot，更加便于業(yè)務(wù)落地。

• Spring Cloud 發(fā)展得非?？?，從開始接觸時(shí)的相關(guān)組件版本為 1.x，到現(xiàn)在將要發(fā)布 2.x 系列。

• Spring Cloud 是 Java 領(lǐng)域最適合做微服務(wù)的框架。

相比于其他框架，Spring Cloud 對微服務(wù)周邊環(huán)境的支持力度最大。對于中小企業(yè)來講，使用門檻較低。

推薦分布式微服務(wù)商城

看完上述內(nèi)容，你們對springboot中SpringCloud和Dubbo的區(qū)別及各自的優(yōu)缺點(diǎn)是什么有進(jìn)一步的了解嗎？如果還想了解更多知識或者相關(guān)內(nèi)容，請關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道，感謝大家的支持。