javascript
《SpringCloud超级入门》使用Eureka编写服务消费者《十一》
我們先從 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)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: HTML+CSS+JS实现 ❤️3D奥运
- 下一篇: 《springcloud超级入门》Spr