Spring Cloud架構(gòu)的各個(gè)組件的原理分析

時(shí)間：2020-10-28 09:10:02

關(guān)鍵字： C語(yǔ)言嵌入式

手機(jī)看文章

掃描二維碼
隨時(shí)隨地手機(jī)看文章

[導(dǎo)讀]本文詳細(xì)介紹了SpringCloud的各個(gè)組件以及原理。

我們先認(rèn)識(shí)一下SpringCloud的各個(gè)組件，然后知其所以然。

Spring Cloud架構(gòu)的各個(gè)組件的原理分析

原理講解前，先看一個(gè)最經(jīng)典的業(yè)務(wù)場(chǎng)景，如開(kāi)發(fā)一個(gè)電商網(wǎng)站，要實(shí)現(xiàn)支付訂單的功能，流程如下：

創(chuàng)建一個(gè)訂單之后，如果用戶立刻支付了這個(gè)訂單，我們需要將訂單狀態(tài)更新為“已支付”
扣減相應(yīng)的商品庫(kù)存
通知倉(cāng)儲(chǔ)中心，進(jìn)行發(fā)貨
給用戶的這次購(gòu)物增加相應(yīng)的積分

Spring Cloud架構(gòu)的各個(gè)組件的原理分析

如上，微服務(wù)的應(yīng)用場(chǎng)景和核心競(jìng)爭(zhēng)力：

降低耦合：每一個(gè)微服務(wù)專注于單一功能，并通過(guò)定義良好的接口清晰表述服務(wù)邊界。由于體積小、復(fù)雜度低，每個(gè)微服務(wù)可由一個(gè)小規(guī)模開(kāi)發(fā)團(tuán)隊(duì)完全掌控，易于保持高可維護(hù)性和開(kāi)發(fā)效率。
獨(dú)立部署：由于微服務(wù)具備獨(dú)立的運(yùn)行進(jìn)程，所以每個(gè)微服務(wù)也可以獨(dú)立部署。當(dāng)某個(gè)微服務(wù)發(fā)生變更時(shí)無(wú)需編譯、部署整個(gè)應(yīng)用。由微服務(wù)組成的應(yīng)用相當(dāng)于具備一系列可并行的發(fā)布流程，使得發(fā)布更加高效，同時(shí)降低對(duì)生產(chǎn)環(huán)境所造成的風(fēng)險(xiǎn)，最終縮短應(yīng)用交付周期。
選型靈活：微服務(wù)架構(gòu)下，技術(shù)選型是去中心化的。每個(gè)團(tuán)隊(duì)可以根據(jù)自身服務(wù)的需求和行業(yè)發(fā)展的現(xiàn)狀，自由選擇最適合的技術(shù)棧。由于每個(gè)微服務(wù)相對(duì)簡(jiǎn)單，故需要對(duì)技術(shù)棧進(jìn)行升級(jí)時(shí)所面臨的風(fēng)險(xiǎn)就較低，甚至完全重構(gòu)一個(gè)微服務(wù)也是可行的。
容錯(cuò)機(jī)制：當(dāng)某一組建發(fā)生故障時(shí)，在單一進(jìn)程的傳統(tǒng)架構(gòu)下，故障很有可能在進(jìn)程內(nèi)擴(kuò)散，形成應(yīng)用全局性的不可用。在微服務(wù)架構(gòu)下，故障會(huì)被隔離在單個(gè)服務(wù)中。若設(shè)計(jì)良好，其他服務(wù)可通過(guò)重試、平穩(wěn)退化等機(jī)制實(shí)現(xiàn)應(yīng)用層面的容錯(cuò)。
靈活擴(kuò)展：?jiǎn)螇K架構(gòu)應(yīng)用也可以實(shí)現(xiàn)橫向擴(kuò)展，就是將整個(gè)應(yīng)用完整的復(fù)制到不同的節(jié)點(diǎn)。當(dāng)應(yīng)用的不同組件在擴(kuò)展需求上存在差異時(shí)，微服務(wù)架構(gòu)便體現(xiàn)出其靈活性，因?yàn)槊總€(gè)服務(wù)可以根據(jù)實(shí)際需求獨(dú)立進(jìn)行擴(kuò)展。

Spring Cloud架構(gòu)的各個(gè)組件的原理分析

Dubbo對(duì)標(biāo)Spring Cloud微服務(wù)：

背景分析：Dubbo，是阿里巴巴服務(wù)化治理的核心框架，并被廣泛應(yīng)用于中國(guó)各互聯(lián)網(wǎng)公司；Spring Cloud是知名的Spring家族的產(chǎn)品。阿里巴巴是一個(gè)商業(yè)公司，雖然也開(kāi)源了很多的頂級(jí)的項(xiàng)目，但從整體戰(zhàn)略上來(lái)講，仍然是服務(wù)于自身的業(yè)務(wù)為主。Spring專注于企業(yè)級(jí)開(kāi)源框架的研發(fā)，不論是在中國(guó)還是在世界上使用都非常廣泛，開(kāi)發(fā)出通用、開(kāi)源、穩(wěn)健的開(kāi)源框架就是他們的主業(yè)。
活躍度對(duì)比：Dubbo是一個(gè)非常優(yōu)秀的服務(wù)治理框架，并且在服務(wù)治理、灰度發(fā)布、流量分發(fā)這方面做的比Spring Cloud還好，除過(guò)當(dāng)當(dāng)網(wǎng)在基礎(chǔ)上增加了rest支持外，已有兩年多的時(shí)間幾乎都沒(méi)有任何更新了。在使用過(guò)程中出現(xiàn)問(wèn)題，提交到GitHub的Issue也少有回復(fù)。相反Spring Cloud自從發(fā)展到現(xiàn)在，仍然在不斷的高速發(fā)展，從GitHub上提交代碼的頻度和發(fā)布版本的時(shí)間間隔就可以看出，現(xiàn)在Spring Cloud即將發(fā)布2.0版本，到了后期會(huì)更加完善和穩(wěn)定。
平臺(tái)架構(gòu)：Dubbo框架只是專注于服務(wù)之間的治理，如果我們需要使用配置中心、分布式跟蹤這些內(nèi)容都需要自己去集成，這樣無(wú)形中使用Dubbo的難度就會(huì)增加。Spring Cloud幾乎考慮了服務(wù)治理的方方面面，更有Spring Boot這個(gè)大將的支持，開(kāi)發(fā)起來(lái)非常的便利和簡(jiǎn)單。
技術(shù)前景：Dubbo在各中小公司也從中受益不少。經(jīng)過(guò)了這么多年的發(fā)展，互聯(lián)網(wǎng)行業(yè)也是涌現(xiàn)了更多先進(jìn)的技術(shù)和理念，Dubbo有點(diǎn)可惜。Spring 推出Spring Boot/Cloud也是因?yàn)樽陨淼暮芏嘣颉?/span>Spring最初推崇的輕量級(jí)框架，隨著不斷的發(fā)展也越來(lái)越龐大，隨著集成項(xiàng)目越來(lái)越多，配置文件也越來(lái)越混亂，慢慢的背離最初的理念。隨著這么多年的發(fā)展，微服務(wù)、分布式鏈路跟蹤等更多新的技術(shù)理念的出現(xiàn)，Spring急需一款框架來(lái)改善以前的開(kāi)發(fā)模式，因此才會(huì)出現(xiàn)Spring Boot/Cloud項(xiàng)目，我們現(xiàn)在訪問(wèn)Spring官網(wǎng)，會(huì)發(fā)現(xiàn)Spring Boot和Spring Cloud已經(jīng)放到首頁(yè)最重點(diǎn)突出的三個(gè)項(xiàng)目中的前兩個(gè)，可見(jiàn)Spring對(duì)這兩個(gè)框架的重視程度。Dubbo實(shí)現(xiàn)如下：

Spring Cloud實(shí)現(xiàn)思路：

Spring Cloud架構(gòu)的各個(gè)組件的原理分析

Eureka

Spring Cloud架構(gòu)的各個(gè)組件的原理分析

原理：主管服務(wù)注冊(cè)與發(fā)現(xiàn)，也就是微服務(wù)的名稱注冊(cè)到Eureka，就可以通過(guò)Eureka找到微服務(wù)，而不需要修改服務(wù)調(diào)用的配置文件。

分析：Spring Cloud封裝了Netflix公司開(kāi)發(fā)的Eureka模塊來(lái)實(shí)現(xiàn)服務(wù)的注冊(cè)與發(fā)現(xiàn)，采用的c-s的設(shè)計(jì)架構(gòu)，Eureka Server作為服務(wù)注冊(cè)功能的服務(wù)器，他是服務(wù)注冊(cè)中心。而系統(tǒng)的其他微服務(wù)，使用Eureka的客戶端連接到Eureka Server并維持心跳。這樣系統(tǒng)的維護(hù)人員可以通過(guò)Eureka Server來(lái)監(jiān)控系統(tǒng)中的各個(gè)微服務(wù)是否正常運(yùn)行。Spring Cloud的一些其他模塊（比如Zuul）就可以通過(guò)Eureka Server來(lái)發(fā)現(xiàn)系統(tǒng)其他的微服務(wù)，并執(zhí)行相關(guān)邏輯。

Eureka Server

Eureka Server提供服務(wù)注冊(cè)服務(wù)，各個(gè)節(jié)點(diǎn)啟動(dòng)后，會(huì)在Eureka Server中進(jìn)行注冊(cè)，這樣Eureka Server中的服務(wù)注冊(cè)表中將會(huì)存儲(chǔ)所有可用服務(wù)節(jié)點(diǎn)的信息，服務(wù)節(jié)點(diǎn)的信息可以在界面中直觀的看到。

Eureka Client

Eureka Client是一個(gè)Java客戶端，用于簡(jiǎn)化Eureka Server的交互，客戶端同時(shí)也具備一個(gè)內(nèi)置的、使用輪詢（round-robin）負(fù)載算法的負(fù)載均衡器。在應(yīng)用啟動(dòng)后，將會(huì)向Eureka Server發(fā)送心跳（默認(rèn)周期為30秒），以證明當(dāng)前服務(wù)是可用狀態(tài)。如果Eureka Server在一定的時(shí)間（默認(rèn)90秒）未收到客戶端的心跳，Eureka Server將會(huì)從服務(wù)注冊(cè)表中把這個(gè)服務(wù)節(jié)點(diǎn)移除。

Eureka Server的自我保護(hù)機(jī)制

如果在15分鐘內(nèi)超過(guò)85%的節(jié)點(diǎn)都沒(méi)有正常的心跳，那么Eureka就認(rèn)為客戶端與注冊(cè)中心出現(xiàn)了網(wǎng)絡(luò)故障，此時(shí)會(huì)出現(xiàn)以下幾種情況：

Eureka不再?gòu)淖?cè)列表中移除因?yàn)殚L(zhǎng)時(shí)間沒(méi)收到心跳而應(yīng)該過(guò)期的服務(wù)
Eureka仍然能夠接受新服務(wù)的注冊(cè)和查詢請(qǐng)求，但是不會(huì)被同步到其它節(jié)點(diǎn)上（即保證當(dāng)前節(jié)點(diǎn)依然可用）
當(dāng)網(wǎng)絡(luò)穩(wěn)定時(shí)，當(dāng)前實(shí)例新的注冊(cè)信息會(huì)被同步到其它節(jié)點(diǎn)中

因此， Eureka可以很好的應(yīng)對(duì)因網(wǎng)絡(luò)故障導(dǎo)致部分節(jié)點(diǎn)失去聯(lián)系的情況，而不會(huì)像ZooKeeper那樣使整個(gè)注冊(cè)服務(wù)癱瘓。

Eureka和ZooKeeper

著名的CAP理論指出，一個(gè)分布式系統(tǒng)不可能同時(shí)滿足C（一致性）、A（可用性）和P（分區(qū)容錯(cuò)性）。由于分區(qū)容錯(cuò)性在是分布式系統(tǒng)中必須要保證的，因此我們只能在A和C之間進(jìn)行權(quán)衡。

ZooKeeper保證CP

當(dāng)向注冊(cè)中心查詢服務(wù)列表時(shí)，我們可以容忍注冊(cè)中心返回的是幾分鐘以前的注冊(cè)信息，但不能接受服務(wù)直接down掉不可用。也就是說(shuō)，服務(wù)注冊(cè)功能對(duì)可用性的要求要高于一致性。但是ZooKeeper會(huì)出現(xiàn)這樣一種情況，當(dāng)Master節(jié)點(diǎn)因?yàn)榫W(wǎng)絡(luò)故障與其他節(jié)點(diǎn)失去聯(lián)系時(shí)，剩余節(jié)點(diǎn)會(huì)重新進(jìn)行l(wèi)eader選舉。問(wèn)題在于，選舉leader的時(shí)間太長(zhǎng)，30 ~ 120s，且選舉期間整個(gè)ZooKeeper集群都是不可用的，這就導(dǎo)致在選舉期間注冊(cè)服務(wù)癱瘓。在云部署的環(huán)境下，因網(wǎng)絡(luò)問(wèn)題使得ZooKeeper集群失去Master節(jié)點(diǎn)是較大概率會(huì)發(fā)生的事，雖然服務(wù)能夠最終恢復(fù)，但是漫長(zhǎng)的選舉時(shí)間導(dǎo)致的注冊(cè)長(zhǎng)期不可用是不能容忍的。

Eureka保證AP

Eurek在設(shè)計(jì)時(shí)就優(yōu)先保證可用性。Eureka各個(gè)節(jié)點(diǎn)都是平等的，幾個(gè)節(jié)點(diǎn)掛掉不會(huì)影響正常節(jié)點(diǎn)的工作，剩余的節(jié)點(diǎn)依然可以提供注冊(cè)和查詢服務(wù)。而Eureka的客戶端在向某個(gè)Eureka注冊(cè)或時(shí)如果發(fā)現(xiàn)連接失敗，則會(huì)自動(dòng)切換至其它節(jié)點(diǎn)，只要有一臺(tái)Eureka還在，就能保證注冊(cè)服務(wù)可用（保證可用性），只不過(guò)查到的信息可能不是最新的（不保證強(qiáng)一致性）。

除此之外，Eureka還有一種自我保護(hù)機(jī)制，見(jiàn)上。

總結(jié)

Eureka可以很好的應(yīng)對(duì)因網(wǎng)絡(luò)故障導(dǎo)致部分節(jié)點(diǎn)失去聯(lián)系的情況，而不會(huì)像ZooKeeper那樣使整個(gè)注冊(cè)服務(wù)癱瘓。

Eureka作為單純的服務(wù)注冊(cè)中心來(lái)說(shuō)要比ZooKeeper更加“專業(yè)”，因?yàn)樽?cè)服務(wù)更重要的是可用性，我們可以接受短期內(nèi)達(dá)不到一致性的狀況。

Spring Cloud架構(gòu)的各個(gè)組件的原理分析

Ribbon和Feign

Spring Cloud架構(gòu)的各個(gè)組件的原理分析

在微服務(wù)架構(gòu)中，業(yè)務(wù)都會(huì)被拆分成一個(gè)獨(dú)立的服務(wù)，服務(wù)與服務(wù)的通訊是基于HTTP RESTful的。Spring Cloud有兩種服務(wù)調(diào)用方式，一種是Ribbon+RestTemplate，另一種是Feign。

概念

基于Netflix Ribbon用過(guò)輪詢策略實(shí)現(xiàn)的一套客戶端負(fù)載均衡的工具。

客戶端負(fù)載均衡：負(fù)載均衡Zuul網(wǎng)關(guān)將一個(gè)請(qǐng)求發(fā)送給某一個(gè)服務(wù)的應(yīng)用的時(shí)候，如果一個(gè)服務(wù)啟動(dòng)了多個(gè)實(shí)例，就會(huì)通過(guò)Ribbon來(lái)通過(guò)一定的負(fù)載均衡策略來(lái)發(fā)送給某一一個(gè)服務(wù)實(shí)例。Spring Cloud中的Ribbon，客戶端會(huì)有一個(gè)服務(wù)器地址列表，在發(fā)送請(qǐng)求前通過(guò)負(fù)載均衡算法（如簡(jiǎn)單輪詢，隨機(jī)連接等）選擇一個(gè)服務(wù)器，然后進(jìn)行訪問(wèn)。

負(fù)載均衡

負(fù)載均衡：用于將工作負(fù)載分布到多個(gè)服務(wù)器來(lái)提高網(wǎng)站、應(yīng)用、數(shù)據(jù)庫(kù)或其他服務(wù)的性能和可靠性。
使用負(fù)載均衡帶來(lái)的好處很明顯：當(dāng)集群里的1臺(tái)或者多臺(tái)服務(wù)器down的時(shí)候，剩余的沒(méi)有down的服務(wù)器可以保證服務(wù)的繼續(xù)使用；將訪問(wèn)壓力分配到各個(gè)服務(wù)器，不會(huì)由于某一高峰時(shí)刻導(dǎo)致系統(tǒng)cpu急劇上升。
負(fù)載均衡有好幾種實(shí)現(xiàn)策略，常見(jiàn)的有：隨機(jī)（Random），輪詢（RoundRobin），一致性哈希（ConsistentHash），哈希（Hash），加權(quán)（Weighted）
Ribbon的默認(rèn)策略是輪詢

RestTemplate

傳統(tǒng)情況下在Java代碼里訪問(wèn)RESTful服務(wù)，一般使用Apache的HttpClient，不過(guò)此種方法使用起來(lái)太過(guò)繁瑣。Spring提供了一種簡(jiǎn)單便捷的模板類來(lái)進(jìn)行操作，這就是RestTemplate。

Feign是一個(gè)聲明式http客戶端。使用Feign能讓編寫http客戶端更加簡(jiǎn)單，它的使用方法是定義一個(gè)接口，然后在上面添加注解，避免了調(diào)用目標(biāo)微服務(wù)時(shí)，需要不斷的解析/封裝json數(shù)據(jù)的繁瑣。Spring Cloud中Feign默認(rèn)集成了Ribbon，并和Eureka結(jié)合，默認(rèn)實(shí)現(xiàn)了負(fù)載均衡的效果。

Ribbon和Feign的區(qū)別

Feign目標(biāo)使編寫Java Http客戶端變得更容易

在使用Ribbon+ RestTemplate時(shí)，Ribbon需要自己構(gòu)建http請(qǐng)求，模擬http請(qǐng)求然后使用RestTemplate發(fā)送給其他服務(wù)，步驟相當(dāng)繁瑣。利用RestTemplate對(duì)http請(qǐng)求的封裝處理，形成了-套模版化的調(diào)用方法。但是在實(shí)際開(kāi)發(fā)中，由于對(duì)服務(wù)依賴的調(diào)用可能不止一處,往往一個(gè)接口會(huì)被多處調(diào)用，所以通常都會(huì)針對(duì)每個(gè)微服務(wù)自行封裝一些客戶端類來(lái)包裝這些依賴服務(wù)的調(diào)用。所以，F(xiàn)eign在此基礎(chǔ)上做了進(jìn)一步封裝，由他來(lái)幫助我們定義和實(shí)現(xiàn)依賴服務(wù)接口的定義。

在Feign的實(shí)現(xiàn)下，我們只需創(chuàng)建一個(gè)接口并使用注解的方式來(lái)配置它（以前是Dao接口上面標(biāo)注Mapper注解，現(xiàn)在是一個(gè)微服務(wù)接口上面標(biāo)注一個(gè)Feign注解即可），即可完成對(duì)服務(wù)提供方的接口綁定，簡(jiǎn)化了使用Spring Cloud Ribbon時(shí)，自動(dòng)封裝服務(wù)調(diào)用客戶端的開(kāi)發(fā)量。

Feign集成了Ribbon

Ribbon通過(guò)輪詢實(shí)現(xiàn)了客戶端的負(fù)載均衡，而與Ribbon不同的是，F(xiàn)eign是一個(gè)聲明式的Web服務(wù)客戶端，使得編寫Web服務(wù)客戶端變得非常容易，只需要?jiǎng)?chuàng)建一個(gè)接口，然后在上面添加注解，像調(diào)用本地方法一樣調(diào)用它就可以，而感覺(jué)不到是調(diào)用遠(yuǎn)程方法。SpringCloud中Feign默認(rèn)集成了Ribbon，并和Eureka結(jié)合，默認(rèn)實(shí)現(xiàn)了負(fù)載均衡的效果。

Ribbon和Nginx的區(qū)別

服務(wù)器端負(fù)載均衡Nginx

Nginx是客戶端所有請(qǐng)求統(tǒng)一交給Nginx，由Nginx進(jìn)行實(shí)現(xiàn)負(fù)載均衡請(qǐng)求轉(zhuǎn)發(fā)，屬于服務(wù)器端負(fù)載均衡。既請(qǐng)求由Nginx服務(wù)器端進(jìn)行轉(zhuǎn)發(fā)?？蛻舳素?fù)載均衡Ribbon，Ribbon是從Eureka注冊(cè)中心服務(wù)器端上獲取服務(wù)注冊(cè)信息列表，緩存到本地，然后在本地實(shí)現(xiàn)輪詢負(fù)載均衡策略。既在客戶端實(shí)現(xiàn)負(fù)載均衡。

應(yīng)用場(chǎng)景的區(qū)別

Nginx適合于服務(wù)器端實(shí)現(xiàn)負(fù)載均衡，比如：Tomcat，Ribbon適合與在微服務(wù)中RPC遠(yuǎn)程調(diào)用實(shí)現(xiàn)本地服務(wù)負(fù)載均衡，比如：Dubbo、Spring Cloud中都是采用本地負(fù)載均衡。

Spring Cloud架構(gòu)的各個(gè)組件的原理分析

Zuul

Spring Cloud架構(gòu)的各個(gè)組件的原理分析

應(yīng)用場(chǎng)景

假如當(dāng)前有十幾個(gè)微服務(wù)服務(wù)，訂單，商品，用戶等等，顯然是客戶端不需要和每個(gè)服務(wù)逐一打交道，這就需要有一個(gè)統(tǒng)一入口，它就是服務(wù)網(wǎng)關(guān)。API網(wǎng)關(guān)所有的客戶端請(qǐng)求通過(guò)這個(gè)網(wǎng)關(guān)訪問(wèn)后臺(tái)的服務(wù)。他可以使用一定的路由配置來(lái)判斷某一個(gè)URL由哪個(gè)服務(wù)來(lái)處理。并從Eureka獲取注冊(cè)的服務(wù)來(lái)轉(zhuǎn)發(fā)請(qǐng)求。

核心功能

Zuul包含了對(duì)請(qǐng)求的路由和過(guò)濾兩個(gè)最主要的功能，是各種服務(wù)的統(tǒng)一入口，同時(shí)還會(huì)用來(lái)提供監(jiān)控、授權(quán)、安全、調(diào)度等等。

路由功能：負(fù)責(zé)將外部請(qǐng)求轉(zhuǎn)發(fā)到具體的微服務(wù)實(shí)例上，是實(shí)現(xiàn)外部訪問(wèn)統(tǒng)一入口的基礎(chǔ)。

過(guò)濾器功能：則負(fù)責(zé)對(duì)請(qǐng)求的處理過(guò)程進(jìn)行干預(yù)，是實(shí)現(xiàn)請(qǐng)求校驗(yàn)、服務(wù)聚合等功能的基礎(chǔ)。

Zuul和Eureka進(jìn)行整合：將Zuul自身注冊(cè)為Eureka服務(wù)治理下的應(yīng)用，同時(shí)從Eureka中獲得其他微服務(wù)的消息,也即以后的訪問(wèn)微服務(wù)都是通過(guò)Zuul跳轉(zhuǎn)后獲得。

注意：Zuul服務(wù)最終還是會(huì)注冊(cè)進(jìn)Eureka，提供代理+路由+過(guò)濾三大功能。

核心原理

Zuul的核心是一系列的filters，其作用可以類比Servlet框架的Filter，或者AOP。

過(guò)濾器之間沒(méi)有直接進(jìn)行通信,而是通過(guò)Request Context（上下文）進(jìn)行數(shù)據(jù)傳遞。

Zuul的過(guò)濾器是由Groovy寫成，這些過(guò)濾器文件被放在Zuul Server上的特定目錄下面，Zuul會(huì)定期輪詢這些目錄，修改過(guò)的過(guò)濾器會(huì)動(dòng)態(tài)的加載到Zuul Server中以便過(guò)濾請(qǐng)求使用。

Zuul負(fù)載均衡：Zuul攔截對(duì)應(yīng)的API前綴請(qǐng)求做轉(zhuǎn)發(fā)，轉(zhuǎn)發(fā)到對(duì)應(yīng)的serverId上，在Eureka服務(wù)上同一個(gè)serverId可以對(duì)應(yīng)多個(gè)服務(wù)，也就是說(shuō)用同一個(gè)服務(wù)節(jié)點(diǎn)不同的端口注冊(cè)兩個(gè)實(shí)例，但是serverId是一樣Zuul做轉(zhuǎn)發(fā)的時(shí)候會(huì)結(jié)合eureka-server起到負(fù)載均衡的效果。

過(guò)濾器的種類：

PRE（前置）：這種過(guò)濾器在請(qǐng)求被路由之前調(diào)用。我們可利用這種過(guò)濾器實(shí)現(xiàn)鑒權(quán)、限流、參數(shù)校驗(yàn)調(diào)整等。
ROUTING（路由）：這種過(guò)濾器將請(qǐng)求路由到微服務(wù)。這種過(guò)濾器用于構(gòu)建發(fā)送給微服務(wù)的請(qǐng)求，并使用Apache HttpClient或Netfilx Ribbon請(qǐng)求微服務(wù)。
POST（后置）：這種過(guò)濾器在路由到微服務(wù)以后執(zhí)行。這種過(guò)濾器可用來(lái)為響應(yīng)添加標(biāo)準(zhǔn)的HTTP Header、收集統(tǒng)計(jì)信息和指標(biāo)、將響應(yīng)從微服務(wù)發(fā)送給客戶端、日志等。
ERROR（錯(cuò)誤）：在其他階段發(fā)生錯(cuò)誤時(shí)執(zhí)行該過(guò)濾器。

Zuul和Nginx

Zuul雖然在性能上和Nginx沒(méi)法比，但它也有它的優(yōu)點(diǎn)。Zuul提供了認(rèn)證鑒權(quán)，動(dòng)態(tài)路由，監(jiān)控，彈性，安全，負(fù)載均衡等邊緣服務(wù)，在團(tuán)隊(duì)規(guī)模不大的情況下，沒(méi)有專門負(fù)責(zé)路由開(kāi)發(fā)時(shí)，使用Zuul當(dāng)網(wǎng)關(guān)是一個(gè)快速上手的好方案。

Nginx和Zuul是可以配合使用的，發(fā)揮各自的優(yōu)點(diǎn)，使用Nginx作為負(fù)載均衡實(shí)現(xiàn)高并發(fā)的請(qǐng)求轉(zhuǎn)發(fā)，Zuul用作網(wǎng)關(guān)。

Zuul和Ribbon實(shí)現(xiàn)負(fù)載均衡

Zuul支持Ribbon和Hystrix，也能夠?qū)崿F(xiàn)客戶端的負(fù)載均衡。我們的Feign不也是實(shí)現(xiàn)客戶端的負(fù)載均衡和Hystrix的嗎？既然Zuul已經(jīng)能夠?qū)崿F(xiàn)了，那我們的Feign還有必要嗎？

可以這樣理解：

Zuul是對(duì)外暴露的唯一接口相當(dāng)于路由的是controller的請(qǐng)求，而Ribbonhe和Fegin路由了service的請(qǐng)求。

Zuul做最外層請(qǐng)求的負(fù)載均衡，而Ribbon和Fegin做的是系統(tǒng)內(nèi)部各個(gè)微服務(wù)的service的調(diào)用的負(fù)載均衡。

Hystrix

Spring Cloud架構(gòu)的各個(gè)組件的原理分析

介紹

Hystrix是一個(gè)用于處理分布式系統(tǒng)的延遲和容錯(cuò)的開(kāi)源庫(kù),在分布式系統(tǒng)里,許多依賴不可避兔的會(huì)調(diào)用失敗，比如超時(shí)、異常等，Hystrix能夠保證在一個(gè)依賴出問(wèn)題的情況下，不會(huì)導(dǎo)致整體服務(wù)失敗，避免級(jí)聯(lián)故障，以提高分布式系統(tǒng)的彈性。Hystrix的出現(xiàn)就是為了解決雪崩效應(yīng)。

服務(wù)雪崩

多個(gè)微服務(wù)之間調(diào)用的時(shí)候，假設(shè)微服務(wù)A調(diào)用微服務(wù)B和微服務(wù)C,微服務(wù)B和微服務(wù)C又調(diào)用其它的微服務(wù)，這就是所謂的“扇出”。如果扇出的鏈路上某個(gè)微服務(wù)的調(diào)用響應(yīng)時(shí)間過(guò)長(zhǎng)或者不可用，對(duì)微服務(wù)A的調(diào)用就會(huì)占用越來(lái)越多的系統(tǒng)資源，進(jìn)而引起系統(tǒng)崩潰，所謂的”雪崩效應(yīng)”。

服務(wù)熔斷

熔斷機(jī)制是應(yīng)對(duì)雪崩效應(yīng)的一種微服務(wù)鏈路保護(hù)機(jī)制。

當(dāng)刪除鏈路的某個(gè)微服務(wù)不可用或者響應(yīng)時(shí)間太長(zhǎng)時(shí)，會(huì)進(jìn)行服務(wù)的降級(jí)，進(jìn)而熔斷該節(jié)點(diǎn)微服務(wù)的調(diào)用，快速返回”錯(cuò)誤的響應(yīng)信息。當(dāng)檢測(cè)到該節(jié)點(diǎn)微服務(wù)調(diào)用響應(yīng)正常后恢復(fù)調(diào)用鏈路。在SpringCloud框架里熔斷機(jī)制通過(guò)Hystrix實(shí)現(xiàn)。Hystrix會(huì)監(jiān)控微服務(wù)間調(diào)用的狀況，當(dāng)失敗的調(diào)用到一定閾值,缺省是5秒內(nèi)20次調(diào)用失敗就會(huì)啟動(dòng)熔斷機(jī)制。熔斷機(jī)制的注解是@HystrixCommand。

服務(wù)降級(jí)

整體資源快不夠了，忍痛將某些服務(wù)先關(guān)掉，待渡過(guò)難關(guān)，再開(kāi)啟回來(lái)。

Hystrix監(jiān)控和斷路器

我們只需要在服務(wù)接口上添加Hystrix標(biāo)簽，就可以實(shí)現(xiàn)對(duì)這個(gè)接口的監(jiān)控和斷路器功能。

Hystrix Dashboard監(jiān)控面板，提供了一個(gè)界面，可以監(jiān)控各個(gè)服務(wù)上的服務(wù)調(diào)用所消耗的時(shí)間等。

Hystrix Turbine監(jiān)控聚合

使用Hystrix監(jiān)控，我們需要打開(kāi)每一個(gè)服務(wù)實(shí)例的監(jiān)控信息來(lái)查看。而Turbine可以幫助我們把所有的服務(wù)實(shí)例的監(jiān)控信息聚合到一個(gè)地方統(tǒng)查看。這樣就不需要挨個(gè)打開(kāi)一個(gè)個(gè)的頁(yè)面一個(gè)個(gè)查看。

Zuul的安全機(jī)制

簽名機(jī)制，為防止接口數(shù)據(jù)篡改和重復(fù)調(diào)用，增加接口參數(shù)校驗(yàn)機(jī)制，sig簽名算法為MD5（appKey+appSecret+timestamp），appKey是分配給客戶端的ID，appSecret是分配給客戶端的密鑰，timestamp為unix時(shí)間戳，請(qǐng)求的URL有效時(shí)間為15分鐘。

Token機(jī)制，用戶在登錄之后會(huì)返回一個(gè)access_ token，客戶端在訪問(wèn)需要登錄之后才能訪問(wèn)的資源，需要在在Authorization頭部使用Bearer模式新增token，如head(“Authorization”,” Bearer token”)。

Hystrix的設(shè)計(jì)原則

資源隔離（線程池隔離和信號(hào)量隔離）機(jī)制：限制調(diào)用分布式服務(wù)的資源使用，某一個(gè)調(diào)用的服務(wù)出現(xiàn)問(wèn)題不會(huì)影響其它服務(wù)調(diào)用。
限流機(jī)制：限流機(jī)制主要是提前對(duì)各個(gè)類型的請(qǐng)求設(shè)置最高的QPS閾值，若高于設(shè)置的閾值則對(duì)該請(qǐng)求直接返回，不再調(diào)用后續(xù)資源。
熔斷機(jī)制：當(dāng)失敗率達(dá)到閥值自動(dòng)觸發(fā)降級(jí)（如因網(wǎng)絡(luò)故障、超時(shí)造成的失敗率真高），熔斷器觸發(fā)的快速失敗會(huì)進(jìn)行快速恢復(fù)。
降級(jí)機(jī)制：超時(shí)降級(jí)、資源不足時(shí)（線程或信號(hào)量）降級(jí)、運(yùn)行異常降級(jí)等，降級(jí)后可以配合降級(jí)接口返回托底數(shù)據(jù)。
緩存支持：提供了請(qǐng)求緩存、請(qǐng)求合并實(shí)現(xiàn)。
通過(guò)近實(shí)時(shí)的統(tǒng)計(jì)/監(jiān)控/報(bào)警功能，來(lái)提高故障發(fā)現(xiàn)的速度。
通過(guò)近實(shí)時(shí)的屬性和配置熱修改功能，來(lái)提高故障處理和恢復(fù)的速度。

Config

Spring Cloud架構(gòu)的各個(gè)組件的原理分析

介紹

Spring Cloud Config是一個(gè)解決分布式系統(tǒng)的配置管理方案。微服務(wù)意味著要將單體應(yīng)用中的業(yè)務(wù)拆分成一個(gè)個(gè)子服務(wù)，每個(gè)服務(wù)的粒度相對(duì)較小，因此系統(tǒng) 中會(huì)出現(xiàn)大量的服務(wù)。由于每個(gè)服務(wù)都需要必要的配置信息才能運(yùn)行，所以一套集中式的、動(dòng)態(tài)的配置管理設(shè)施是必不可少的。Spring Cloud提供了ConfigServer來(lái)解決這個(gè)問(wèn)題,我們每一個(gè)微服務(wù)自己帶著一個(gè)application.yml 上百個(gè)配置文件的管理。

應(yīng)用場(chǎng)景

不方便維護(hù)，多人同時(shí)對(duì)配置文件進(jìn)行修改，沖突不斷，很難維護(hù)
配置內(nèi)容安全和權(quán)限，主要是針對(duì)線上的配置來(lái)說(shuō)，一般不對(duì)開(kāi)發(fā)公開(kāi)，只有運(yùn)維有權(quán)限所以需要將配置文件隔離，不放到項(xiàng)目代碼里
更新配置項(xiàng)目需要重啟，每次更新配置文件都需要重啟項(xiàng)目，很耗時(shí)。使用了配置中心后，即可實(shí)現(xiàn)配置實(shí)時(shí)更新congfig Server和Config Client結(jié)合Spring Cloud Bus實(shí)現(xiàn)配置自動(dòng)刷新。

原理

配置文件存儲(chǔ)在遠(yuǎn)端Git（比如GitHub，Gitee等倉(cāng)庫(kù)），config-server從遠(yuǎn)端Git拉取配置文件，并保存到本地Git。
本地Git和config-server的交互是雙向的，因?yàn)楫?dāng)遠(yuǎn)端Git無(wú)法訪問(wèn)時(shí)，會(huì)從本地Git獲取配置文件。
config-client（即各個(gè)微服務(wù)），從config-server拉取配置文件。

角色

Config Server：提供配置文件的存儲(chǔ)、以接口的形式將配置文件的內(nèi)容提供出去。
Config Client：通過(guò)接口獲取數(shù)據(jù)、并依據(jù)此數(shù)據(jù)初始化自己的應(yīng)用。

總結(jié)如下：

Spring Cloud架構(gòu)的各個(gè)組件的原理分析

編輯：分布式實(shí)驗(yàn)室

原文鏈接：https://blog.csdn.net/Peter_Changyb/article/details/108448431

特別推薦一個(gè)分享架構(gòu)+算法的優(yōu)質(zhì)內(nèi)容，還沒(méi)關(guān)注的小伙伴，可以長(zhǎng)按關(guān)注一下：

Spring Cloud架構(gòu)的各個(gè)組件的原理分析

長(zhǎng)按訂閱更多精彩▼
如有收獲，點(diǎn)個(gè)在看，誠(chéng)摯感謝

免責(zé)聲明：本文內(nèi)容由21ic獲得授權(quán)后發(fā)布，版權(quán)歸原作者所有，本平臺(tái)僅提供信息存儲(chǔ)服務(wù)。文章僅代表作者個(gè)人觀點(diǎn)，不代表本平臺(tái)立場(chǎng)，如有問(wèn)題，請(qǐng)聯(lián)系我們，謝謝！