javascript
把 Spring Cloud 给拆了!详解每个组件的作用
我們先認(rèn)識(shí)一下SpringCloud的各個(gè)組件,然后知其所以然。
Spring Cloud架構(gòu)的各個(gè)組件的原理分析原理講解前,先看一個(gè)最經(jīng)典的業(yè)務(wù)場(chǎng)景,如開發(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)的積分
如上,微服務(wù)的應(yīng)用場(chǎng)景和核心競(jìng)爭(zhēng)力:
降低耦合:每一個(gè)微服務(wù)專注于單一功能,并通過定義良好的接口清晰表述服務(wù)邊界。由于體積小、復(fù)雜度低,每個(gè)微服務(wù)可由一個(gè)小規(guī)模開發(fā)團(tuán)隊(duì)完全掌控,易于保持高可維護(hù)性和開發(fā)效率。
獨(dú)立部署:由于微服務(wù)具備獨(dú)立的運(yùn)行進(jìn)程,所以每個(gè)微服務(wù)也可以獨(dú)立部署。當(dāng)某個(gè)微服務(wù)發(fā)生變更時(shí)無需編譯、部署整個(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ù)可通過重試、平穩(wěn)退化等機(jī)制實(shí)現(xiàn)應(yīng)用層面的容錯(cuò)。
靈活擴(kuò)展:單塊架構(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ò)展。
Dubbo對(duì)標(biāo)Spring Cloud微服務(wù):
背景分析:Dubbo,是阿里巴巴服務(wù)化治理的核心框架,并被廣泛應(yīng)用于中國(guó)各互聯(lián)網(wǎng)公司;Spring Cloud是知名的Spring家族的產(chǎn)品。阿里巴巴是一個(gè)商業(yè)公司,雖然也開源了很多的頂級(jí)的項(xiàng)目,但從整體戰(zhàn)略上來講,仍然是服務(wù)于自身的業(yè)務(wù)為主。Spring專注于企業(yè)級(jí)開源框架的研發(fā),不論是在中國(guó)還是在世界上使用都非常廣泛,開發(fā)出通用、開源、穩(wěn)健的開源框架就是他們的主業(yè)。
活躍度對(duì)比:Dubbo是一個(gè)非常優(yōu)秀的服務(wù)治理框架,并且在服務(wù)治理、灰度發(fā)布、流量分發(fā)這方面做的比Spring Cloud還好,除過當(dāng)當(dāng)網(wǎng)在基礎(chǔ)上增加了rest支持外,已有兩年多的時(shí)間幾乎都沒有任何更新了。在使用過程中出現(xià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)容都需要自己去集成,這樣無形中使用Dubbo的難度就會(huì)增加。Spring Cloud幾乎考慮了服務(wù)治理的方方面面,更有Spring Boot這個(gè)大將的支持,開發(fā)起來非常的便利和簡(jiǎn)單。
技術(shù)前景:Dubbo在各中小公司也從中受益不少。經(jīng)過了這么多年的發(fā)展,互聯(lián)網(wǎng)行業(yè)也是涌現(xiàn)了更多先進(jìn)的技術(shù)和理念,Dubbo有點(diǎn)可惜。Spring 推出Spring Boot/Cloud也是因?yàn)樽陨淼暮芏嘣颉pring最初推崇的輕量級(jí)框架,隨著不斷的發(fā)展也越來越龐大,隨著集成項(xiàng)目越來越多,配置文件也越來越混亂,慢慢的背離最初的理念。隨著這么多年的發(fā)展,微服務(wù)、分布式鏈路跟蹤等更多新的技術(shù)理念的出現(xiàn),Spring急需一款框架來改善以前的開發(fā)模式,因此才會(huì)出現(xiàn)Spring Boot/Cloud項(xiàng)目,我們現(xiàn)在訪問Spring官網(wǎng),會(huì)發(fā)現(xiàn)Spring Boot和Spring Cloud已經(jīng)放到首頁(yè)最重點(diǎn)突出的三個(gè)項(xiàng)目中的前兩個(gè),可見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,就可以通過Eureka找到微服務(wù),而不需要修改服務(wù)調(diào)用的配置文件。
分析:Spring Cloud封裝了Netflix公司開發(fā)的Eureka模塊來實(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ù)人員可以通過Eureka Server來監(jiān)控系統(tǒng)中的各個(gè)微服務(wù)是否正常運(yùn)行。Spring Cloud的一些其他模塊(比如Zuul)就可以通過Eureka Server來發(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)超過85%的節(jié)點(diǎn)都沒有正常的心跳,那么Eureka就認(rèn)為客戶端與注冊(cè)中心出現(xiàn)了網(wǎng)絡(luò)故障,此時(shí)會(huì)出現(xiàn)以下幾種情況:
Eureka不再?gòu)淖?cè)列表中移除因?yàn)殚L(zhǎng)時(shí)間沒收到心跳而應(yīng)該過期的服務(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)衡。
搜索公眾號(hào)?Java筆記蝦,回復(fù)“后端面試”,送你一份面試題大全.pdf
ZooKeeper保證CP
當(dāng)向注冊(cè)中心查詢服務(wù)列表時(shí),我們可以容忍注冊(cè)中心返回的是幾分鐘以前的注冊(cè)信息,但不能接受服務(wù)直接down掉不可用。也就是說,服務(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選舉。
問題在于,選舉leader的時(shí)間太長(zhǎng),30 ~ 120s,且選舉期間整個(gè)ZooKeeper集群都是不可用的,這就導(dǎo)致在選舉期間注冊(cè)服務(wù)癱瘓。在云部署的環(huán)境下,因網(wǎng)絡(luò)問題使得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ù)可用(保證可用性),只不過查到的信息可能不是最新的(不保證強(qiáng)一致性)。
除此之外,Eureka還有一種自我保護(hù)機(jī)制,見上。
總結(jié)
Eureka可以很好的應(yīng)對(duì)因網(wǎng)絡(luò)故障導(dǎo)致部分節(jié)點(diǎn)失去聯(lián)系的情況,而不會(huì)像ZooKeeper那樣使整個(gè)注冊(cè)服務(wù)癱瘓。
Eureka作為單純的服務(wù)注冊(cè)中心來說要比ZooKeeper更加“專業(yè)”,因?yàn)樽?cè)服務(wù)更重要的是可用性,我們可以接受短期內(nèi)達(dá)不到一致性的狀況。
Spring Cloud架構(gòu)的各個(gè)組件的原理分析Ribbon和Feign
在微服務(wù)架構(gòu)中,業(yè)務(wù)都會(huì)被拆分成一個(gè)獨(dú)立的服務(wù),服務(wù)與服務(wù)的通訊是基于HTTP RESTful的。Spring Cloud有兩種服務(wù)調(diào)用方式,一種是Ribbon+RestTemplate,另一種是Feign。
概念
基于Netflix Ribbon用過輪詢策略實(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ì)通過Ribbon來通過一定的負(fù)載均衡策略來發(fā)送給某一一個(gè)服務(wù)實(shí)例。Spring Cloud中的Ribbon,客戶端會(huì)有一個(gè)服務(wù)器地址列表,在發(fā)送請(qǐng)求前通過負(fù)載均衡算法(如簡(jiǎn)單輪詢,隨機(jī)連接等)選擇一個(gè)服務(wù)器,然后進(jìn)行訪問。
負(fù)載均衡
負(fù)載均衡:用于將工作負(fù)載分布到多個(gè)服務(wù)器來提高網(wǎng)站、應(yīng)用、數(shù)據(jù)庫(kù)或其他服務(wù)的性能和可靠性。
使用負(fù)載均衡帶來的好處很明顯:當(dāng)集群里的1臺(tái)或者多臺(tái)服務(wù)器down的時(shí)候,剩余的沒有down的服務(wù)器可以保證服務(wù)的繼續(xù)使用;將訪問壓力分配到各個(gè)服務(wù)器,不會(huì)由于某一高峰時(shí)刻導(dǎo)致系統(tǒng)cpu急劇上升。
負(fù)載均衡有好幾種實(shí)現(xiàn)策略,常見的有:隨機(jī)(Random),輪詢(RoundRobin),一致性哈希(ConsistentHash),哈希(Hash),加權(quán)(Weighted)
Ribbon的默認(rèn)策略是輪詢
RestTemplate
傳統(tǒng)情況下在Java代碼里訪問RESTful服務(wù),一般使用Apache的HttpClient,不過此種方法使用起來太過繁瑣。Spring提供了一種簡(jiǎn)單便捷的模板類來進(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í)際開發(fā)中,由于對(duì)服務(wù)依賴的調(diào)用可能不止一處,往往一個(gè)接口會(huì)被多處調(diào)用,所以通常都會(huì)針對(duì)每個(gè)微服務(wù)自行封裝一些客戶端類來包裝這些依賴服務(wù)的調(diào)用。所以,Feign在此基礎(chǔ)上做了進(jìn)一步封裝,由他來幫助我們定義和實(shí)現(xiàn)依賴服務(wù)接口的定義。
在Feign的實(shí)現(xiàn)下,我們只需創(chuàng)建一個(gè)接口并使用注解的方式來配置它(以前是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)用客戶端的開發(fā)量。
搜索公眾號(hào)?Java筆記蝦,回復(fù)“后端面試”,送你一份面試題大全.pdf
Feign集成了Ribbon
Ribbon通過輪詢實(shí)現(xiàn)了客戶端的負(fù)載均衡,而與Ribbon不同的是,Feign是一個(gè)聲明式的Web服務(wù)客戶端, 使得編寫Web服務(wù)客戶端變得非常容易,只需要?jiǎng)?chuàng)建一個(gè)接口, 然后在上面添加注解,像調(diào)用本地方法一樣調(diào)用它就可以,而感覺不到是調(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
應(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)求通過這個(gè)網(wǎng)關(guān)訪問后臺(tái)的服務(wù)。他可以使用一定的路由配置來判斷某一個(gè)URL由哪個(gè)服務(wù)來處理。并從Eureka獲取注冊(cè)的服務(wù)來轉(zhuǎn)發(fā)請(qǐng)求。
核心功能
Zuul包含了對(duì)請(qǐng)求的路由和過濾兩個(gè)最主要的功能,是各種服務(wù)的統(tǒng)一入口,同時(shí)還會(huì)用來提供監(jiān)控、授權(quán)、安全、調(diào)度等等。
路由功能:負(fù)責(zé)將外部請(qǐng)求轉(zhuǎn)發(fā)到具體的微服務(wù)實(shí)例上,是實(shí)現(xiàn)外部訪問統(tǒng)一入口的基礎(chǔ)。
過濾器功能:則負(fù)責(zé)對(duì)請(qǐng)求的處理過程進(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ù)都是通過Zuul跳轉(zhuǎn)后獲得。
注意:Zuul服務(wù)最終還是會(huì)注冊(cè)進(jìn)Eureka,提供代理+路由+過濾三大功能。
核心原理
Zuul的核心是一系列的filters,其作用可以類比Servlet框架的Filter,或者AOP。
過濾器之間沒有直接進(jìn)行通信,而是通過Request Context(上下文)進(jìn)行數(shù)據(jù)傳遞。
Zuul的過濾器是由Groovy寫成,這些過濾器文件被放在Zuul Server上的特定目錄下面,Zuul會(huì)定期輪詢這些目錄,修改過的過濾器會(huì)動(dòng)態(tài)的加載到Zuul Server中以便過濾請(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ù),也就是說用同一個(gè)服務(wù)節(jié)點(diǎn)不同的端口注冊(cè)兩個(gè)實(shí)例,但是serverId是一樣Zuul做轉(zhuǎn)發(fā)的時(shí)候會(huì)結(jié)合eureka-server起到負(fù)載均衡的效果。
過濾器的種類:
PRE(前置):這種過濾器在請(qǐng)求被路由之前調(diào)用。我們可利用這種過濾器實(shí)現(xiàn)鑒權(quán)、限流、參數(shù)校驗(yàn)調(diào)整等。
ROUTING(路由):這種過濾器將請(qǐng)求路由到微服務(wù)。這種過濾器用于構(gòu)建發(fā)送給微服務(wù)的請(qǐng)求,并使用Apache HttpClient或Netfilx Ribbon請(qǐng)求微服務(wù)。
POST(后置):這種過濾器在路由到微服務(wù)以后執(zhí)行。這種過濾器可用來為響應(yīng)添加標(biāo)準(zhǔn)的HTTP Header、收集統(tǒng)計(jì)信息和指標(biāo)、將響應(yīng)從微服務(wù)發(fā)送給客戶端、日志等。
ERROR(錯(cuò)誤):在其他階段發(fā)生錯(cuò)誤時(shí)執(zhí)行該過濾器。
Zuul和Nginx
Zuul雖然在性能上和Nginx沒法比,但它也有它的優(yōu)點(diǎn)。Zuul提供了認(rèn)證鑒權(quán),動(dòng)態(tài)路由,監(jiān)控,彈性,安全,負(fù)載均衡等邊緣服務(wù),在團(tuán)隊(duì)規(guī)模不大的情況下,沒有專門負(fù)責(zé)路由開發(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
介紹
Hystrix是一個(gè)用于處理分布式系統(tǒng)的延遲和容錯(cuò)的開源庫(kù),在分布式系統(tǒng)里,許多依賴不可避兔的會(huì)調(diào)用失敗,比如超時(shí)、異常等,Hystrix能夠保證在一個(gè)依賴出問題的情況下,不會(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í)間過長(zhǎng)或者不可用,對(duì)微服務(wù)A的調(diào)用就會(huì)占用越來越多的系統(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ī)制通過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ān),再開啟回來。
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)控,我們需要打開每一個(gè)服務(wù)實(shí)例的監(jiān)控信息來查看。而Turbine可以幫助我們把所有的服務(wù)實(shí)例的監(jiān)控信息聚合到一個(gè)地方統(tǒng)查看。這樣就不需要挨個(gè)打開一個(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,客戶端在訪問需要登錄之后才能訪問的資源,需要在在Authorization頭部使用Bearer模式新增token,如head(“Authorization”,” Bearer token”)。
Hystrix的設(shè)計(jì)原則
資源隔離(線程池隔離和信號(hào)量隔離)機(jī)制:限制調(diào)用分布式服務(wù)的資源使用,某一個(gè)調(diào)用的服務(wù)出現(xià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)。
通過近實(shí)時(shí)的統(tǒng)計(jì)/監(jiān)控/報(bào)警功能,來提高故障發(fā)現(xiàn)的速度。
通過近實(shí)時(shí)的屬性和配置熱修改功能,來提高故障處理和恢復(fù)的速度。
Config
介紹
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來解決這個(gè)問題,我們每一個(gè)微服務(wù)自 己帶著一個(gè)application.yml 上百個(gè)配置文件的管理。
應(yīng)用場(chǎng)景
不方便維護(hù),多人同時(shí)對(duì)配置文件進(jìn)行修改,沖突不斷,很難維護(hù)
配置內(nèi)容安全和權(quán)限,主要是針對(duì)線上的配置來說,一般不對(duì)開發(fā)公開,只有運(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無法訪問時(shí),會(huì)從本地Git獲取配置文件。
config-client(即各個(gè)微服務(wù)),從config-server拉取配置文件。
角色
Config Server:提供配置文件的存儲(chǔ)、以接口的形式將配置文件的內(nèi)容提供出去。
Config Client:通過接口獲取數(shù)據(jù)、并依據(jù)此數(shù)據(jù)初始化自己的應(yīng)用。
總結(jié)如下:
Spring Cloud架構(gòu)的各個(gè)組件的原理分析來源:www.toutiao.com/i6888099913867985422/
推薦文章基于SpringBoot的ERP系統(tǒng),自帶進(jìn)銷存+財(cái)務(wù)+生產(chǎn)功能
2020年國(guó)內(nèi)互聯(lián)網(wǎng)公司的薪酬排名!
不要再封裝各種Util工具類了,這個(gè)神級(jí)框架值得擁有!
寫博客能月入10K?
一款基于 Spring Boot 的現(xiàn)代化社區(qū)(論壇/問答/社交網(wǎng)絡(luò)/博客)
這或許是最美的Vue+Element開源后臺(tái)管理UI
推薦一款高顏值的 Spring Boot 快速開發(fā)框架
一款基于 Spring Boot 的現(xiàn)代化社區(qū)(論壇/問答/社交網(wǎng)絡(luò)/博客)
13K點(diǎn)贊都基于 Vue+Spring 前后端分離管理系統(tǒng)ELAdmin,大愛
想接私活時(shí)薪再翻一倍,建議根據(jù)這幾個(gè)開源的SpringBoot項(xiàng)目
總結(jié)
以上是生活随笔為你收集整理的把 Spring Cloud 给拆了!详解每个组件的作用的全部?jī)?nèi)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 搞 java7 年,我有点想法想和大家聊
- 下一篇: 第一次听人用男女关系讲 N(Non-Bl