我們先從 Nginx 說起，了解為什么需要微服務(wù)。最初的服務(wù)化解決方案是給相同服務(wù)提供一個(gè)統(tǒng)一的域名，然后服務(wù)調(diào)用者向這個(gè)域發(fā)送 HTTP 請(qǐng)求，由 Nginx 負(fù)責(zé)請(qǐng)求的分發(fā)和跳轉(zhuǎn)。

這種架構(gòu)存在很多問題：Nginx 作為中間層，在配置文件中耦合了服務(wù)調(diào)用的邏輯，這削弱了微服務(wù)的完整性，也使得 Nginx 在一定程度上變成了一個(gè)重量級(jí)的 ESB。圖 1 標(biāo)識(shí)出了 Nginx 的轉(zhuǎn)發(fā)信息流走向。

圖 1??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)成的中心組件對(duì)服務(wù)進(jìn)行整合，將每個(gè)服務(wù)的信息匯總，包括服務(wù)的組件名稱、地址、數(shù)量等。

服務(wù)的調(diào)用方在請(qǐng)求某項(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??Dubbo 的基本架構(gòu)圖

從圖 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ù)降級(jí)的選擇。

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

• Registry 嚴(yán)重依賴第三方組件（ZooKeeper 或者 Redis），當(dāng)這些組件出現(xiàn)問題時(shí)，服務(wù)調(diào)用很快就會(huì)中斷。
• Dubbo 只支持 RPC 調(diào)用。這使得服務(wù)提供方與調(diào)用方在代碼上產(chǎn)生了強(qiáng)依賴，服務(wù)提供方需要不斷將包含公共代碼的 Jar 包打包出來供消費(fèi)方使用。一旦打包出現(xiàn)問題，就會(huì)導(dǎo)致服務(wù)調(diào)用出錯(cuò)。

我認(rèn)為，Dubbo 和 Spring cloud 并不是完全的競(jìng)爭(zhēng)關(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é)議、注冊(cè)中心元數(shù)據(jù)不匹配等問題，在面臨微服務(wù)基礎(chǔ)框架選型時(shí) Dubbo 與 Spring Cloud 只能二選一，這也是大家總是拿 Dubbo 和 Spring Cloud 做對(duì)比的原因之一。

Dubbo 已經(jīng)適配到 Spring Cloud 生態(tài)，比如作為 Spring Cloud 的二進(jìn)制通信方案來發(fā)揮 Dubbo 的性能優(yōu)勢(shì)，Dubbo 通過模塊化以及對(duì) HTTP 的支持適配到 Spring Cloud。

Spring Cloud 好在哪里

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

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 表 1 Spring Cloud與Dubbo功能對(duì)比

Spring Cloud 拋棄了 Dubbo 的 RPC 通信，采用的是基于 HTTP 的 REST 方式。嚴(yán)格來說，這兩種方式各有優(yōu)劣。雖然從一定程度上來說，后者犧牲了服務(wù)調(diào)用的性能，但也避免了上面提到的原生 RPC 帶來的問題。而且 REST 相比 RPC 更為靈活，服務(wù)提供方和調(diào)用方，不存在代碼級(jí)別的強(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)目完美融合，這些對(duì)于微服務(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)勢(shì)。

• 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ù)的框架。

上一篇 使用Eureka編寫服務(wù)提供者?

下一篇介紹 Eureka注冊(cè)中心開啟密碼認(rèn)證

總結(jié)

以上是生活随笔為你收集整理的《SpringCloud超级入门》使用Eureka编写服务消费者《十一》的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。