做商城網(wǎng)站那個(gè)好上海網(wǎng)站制作推廣
文章目錄
- 參考資料
- 一. 微服務(wù)概述
- 1. CAP理論
- 2. BASE理論
- 3. SpringBoot 與 SpringCloud對(duì)比
- 二. 服務(wù)注冊(cè):Zookeeper,Eureka,Nacos,Consul
- 1. Nacos兩種健康檢查方式?
- 2. nacos中負(fù)責(zé)負(fù)載均衡底層是如何實(shí)現(xiàn)的
- 3. Nacos原理
- 4. 臨時(shí)實(shí)例和持久化(非臨時(shí))實(shí)例
- 三. 服務(wù)調(diào)用:Feign
- 1. Feign的底層原理
- 2. Feign與OpenFeign的區(qū)別
- 四. 負(fù)載均衡:Ribbon
- 1. Ribbon支持哪幾種負(fù)載均衡策略
- 五. 網(wǎng)關(guān):Gateway,Zuul
- 1. Gateway工作流程
- 2. Spring Cloud Gateway 的路由和斷言是什么關(guān)系?
- 3. Spring Cloud Gateway 如何實(shí)現(xiàn)動(dòng)態(tài)路由?
- 4. Spring Cloud Gateway 支持限流嗎?
- 六. 限流/熔斷/服務(wù)降級(jí):Hystrix,Sentinel
- 1. 什么是熔斷和降級(jí)?
- 2. 限流
- 2.1 常見算法
- 2.2 單機(jī)限流
- 2.3 分布式限流
- 3. Hystrix和Sentinel簡(jiǎn)單介紹
參考資料
概述,總結(jié)的很好
一. 微服務(wù)概述
添加鏈接描述
1. CAP理論
- 一致性(Consistency)
所有節(jié)點(diǎn)訪問(wèn)同一份最新的數(shù)據(jù)副本 - 可用性(Availability)
非故障的節(jié)點(diǎn)在合理的時(shí)間內(nèi)返回合理的響應(yīng)(不是錯(cuò)誤或者超時(shí)的響應(yīng))。 - 分區(qū)容錯(cuò)性(Partition Tolerance)
分布式系統(tǒng)出現(xiàn)網(wǎng)絡(luò)分區(qū)的時(shí)候,仍然能夠?qū)ν馓峁┓?wù)。 - 網(wǎng)絡(luò)分區(qū)
分布式系統(tǒng)中,多個(gè)節(jié)點(diǎn)之間的網(wǎng)絡(luò)本來(lái)是連通的,但是因?yàn)槟承┕收?#xff08;比如部分節(jié)點(diǎn)網(wǎng)絡(luò)出了問(wèn)題)某些節(jié)點(diǎn)之間不連通了,整個(gè)網(wǎng)絡(luò)就分成了幾塊區(qū)域,這就叫 網(wǎng)絡(luò)分區(qū)。
- 3選2
分布式系統(tǒng)理論上不可能選擇 CA 架構(gòu),只能選擇 CP 或者 AP 架構(gòu)。 比如 ZooKeeper、HBase 就是 CP 架構(gòu),Cassandra、Eureka 就是 AP 架構(gòu),Nacos 不僅支持 CP 架構(gòu)也支持 AP 架構(gòu)。 - 為什么不支持CA
若系統(tǒng)出現(xiàn)“分區(qū)”,系統(tǒng)中的某個(gè)節(jié)點(diǎn)在進(jìn)行寫操作。為了保證 C, 必須要禁止其他節(jié)點(diǎn)的讀寫操作,這就和 A 發(fā)生沖突了。如果為了保證 A,其他節(jié)點(diǎn)的讀寫操作正常的話,那就和 C 發(fā)生沖突了。
選擇 CP 還是 AP 的關(guān)鍵在于當(dāng)前的業(yè)務(wù)場(chǎng)景,沒(méi)有定論,比如對(duì)于需要確保強(qiáng)一致性的場(chǎng)景如銀行一般會(huì)選擇保證 CP 。
另外,需要補(bǔ)充說(shuō)明的一點(diǎn)是:如果網(wǎng)絡(luò)分區(qū)正常的話(系統(tǒng)在絕大部分時(shí)候所處的狀態(tài)),也就說(shuō)不需要保證 P 的時(shí)候,C 和 A 能夠同時(shí)保證。
2. BASE理論
- 概述
即使無(wú)法做到強(qiáng)一致性,但每個(gè)應(yīng)用都可以根據(jù)自身業(yè)務(wù)特點(diǎn),采用適當(dāng)?shù)姆绞絹?lái)使系統(tǒng)達(dá)到最終一致性。BASE 理論本質(zhì)上是對(duì) CAP 的延伸和補(bǔ)充,更具體地說(shuō),是對(duì) CAP 中 AP 方案的一個(gè)補(bǔ)充。
如果系統(tǒng)沒(méi)有發(fā)生“分區(qū)”的話,節(jié)點(diǎn)間的網(wǎng)絡(luò)連接通信正常的話,也就不存在 P 了。這個(gè)時(shí)候,我們就可以同時(shí)保證 C 和 A 了。因此,如果系統(tǒng)發(fā)生“分區(qū)”,我們要考慮選擇 CP 還是 AP。如果系統(tǒng)沒(méi)有發(fā)生“分區(qū)”的話,我們要思考如何保證 CA。
因此,AP 方案只是在系統(tǒng)發(fā)生分區(qū)的時(shí)候放棄一致性,而不是永遠(yuǎn)放棄一致性。在分區(qū)故障恢復(fù)后,系統(tǒng)應(yīng)該達(dá)到最終一致性。這一點(diǎn)其實(shí)就是 BASE 理論延伸的地方。 - 基本可用BA
基本可用是指分布式系統(tǒng)在出現(xiàn)不可預(yù)知故障的時(shí)候,允許損失部分可用性(響應(yīng)時(shí)間上的損失/系統(tǒng)功能上的損失)。但是,這絕不等價(jià)于系統(tǒng)不可用。 - 軟狀態(tài)S
軟狀態(tài)指允許系統(tǒng)中的數(shù)據(jù)存在中間狀態(tài)(CAP 理論中的數(shù)據(jù)不一致),并認(rèn)為該中間狀態(tài)的存在不會(huì)影響系統(tǒng)的整體可用性,即允許系統(tǒng)在不同節(jié)點(diǎn)的數(shù)據(jù)副本之間進(jìn)行數(shù)據(jù)同步的過(guò)程存在延時(shí)。 - 最終一致性E
最終一致性強(qiáng)調(diào)的是系統(tǒng)中所有的數(shù)據(jù)副本,在經(jīng)過(guò)一段時(shí)間的同步后,最終能夠達(dá)到一個(gè)一致的狀態(tài)。因此,最終一致性的本質(zhì)是需要系統(tǒng)保證最終數(shù)據(jù)能夠達(dá)到一致,而不需要實(shí)時(shí)保證系統(tǒng)數(shù)據(jù)的強(qiáng)一致性。
3. SpringBoot 與 SpringCloud對(duì)比
- SpringBoot專注于快速方便得開發(fā)單個(gè)個(gè)體微服務(wù)。
- SpringCloud是關(guān)注全局的微服務(wù)協(xié)調(diào)整理治理框架,它將SpringBoot開發(fā)的一個(gè)個(gè)單體微服務(wù)整合并管理起來(lái),為各個(gè)微服務(wù)之間提供,配置管理、服務(wù)發(fā)現(xiàn)、斷路器、路由、微代理、事件總線、全局鎖、決策競(jìng)選、分布式會(huì)話等等集成服務(wù)
- SpringBoot可以離開SpringCloud獨(dú)立使用開發(fā)項(xiàng)目, 但是SpringCloud離不開SpringBoot,屬于依賴的關(guān)系.
- SpringBoot專注于快速、方便得開發(fā)單個(gè)微服務(wù)個(gè)體,SpringCloud關(guān)注全局的服務(wù)治理框架。
二. 服務(wù)注冊(cè):Zookeeper,Eureka,Nacos,Consul
1. Nacos兩種健康檢查方式?
(在nacos中服務(wù)提供者是如何向nacos注冊(cè)中心續(xù)約的)
(對(duì)于nacos服務(wù)來(lái)講它是如何判斷服務(wù)實(shí)例的狀態(tài)的)
- agent上報(bào)模式 (心跳模式,臨時(shí)實(shí)例)
客戶端(注冊(cè)在nacos上的其它微服務(wù)實(shí)例)健康檢查。
客戶端通過(guò)心跳上報(bào)方式告知服務(wù)端(nacos注冊(cè)中心)健康狀態(tài);默認(rèn)心跳間隔5秒;
nacos會(huì)在超過(guò)15秒未收到心跳后將實(shí)例設(shè)置為不健康狀態(tài);超過(guò)30秒將實(shí)例刪除; - 服務(wù)端主動(dòng)檢測(cè)(非臨時(shí)實(shí)例)
服務(wù)端健康檢查。
nacos主動(dòng)探知客戶端健康狀態(tài),默認(rèn)間隔為20秒;健康檢查失敗后實(shí)例會(huì)被標(biāo)記為不健康,不會(huì)被立即刪除。
2. nacos中負(fù)責(zé)負(fù)載均衡底層是如何實(shí)現(xiàn)的
通過(guò)Ribbon實(shí)現(xiàn),Ribbon中定義了負(fù)載均衡算法,然后基于這些算法從服務(wù)實(shí)例中獲取一個(gè)實(shí)例為想要服務(wù)方提供服務(wù)
3. Nacos原理
Nacos的實(shí)現(xiàn)原理
1.客戶端provider向nacos server的open api發(fā)起調(diào)用,把自己的服務(wù)地址鏈接,服務(wù)名稱注冊(cè)上去
2.nacos server與服務(wù)提供者provider建立心跳機(jī)制,用來(lái)檢測(cè)服務(wù)狀態(tài)
3.服務(wù)消費(fèi)者consumer查詢出提供服務(wù)實(shí)例列表
4.并且默認(rèn)10s去nacos server拉取服務(wù)實(shí)例列表
5.當(dāng)服務(wù)消費(fèi)者檢測(cè)到服務(wù)異常,基于UDP協(xié)議推送更新
6.服務(wù)消費(fèi)者即可調(diào)用了
4. 臨時(shí)實(shí)例和持久化(非臨時(shí))實(shí)例
臨時(shí)和持久化的區(qū)別主要在健康檢查失敗后的表現(xiàn),持久化實(shí)例健康檢查失敗后會(huì)被標(biāo)記成不健康,而臨時(shí)實(shí)例會(huì)直接從列表中被刪除。
三. 服務(wù)調(diào)用:Feign
1. Feign的底層原理
首先,如果你對(duì)某個(gè)接口定義了**@FeignClient注解**,Feign就會(huì)針對(duì)這個(gè)接口創(chuàng)建一個(gè)動(dòng)態(tài)代理
接著你要是調(diào)用那個(gè)接口,本質(zhì)就是會(huì)調(diào)用 Feign創(chuàng)建的動(dòng)態(tài)代理,這是核心中的核心
Feign的動(dòng)態(tài)代理會(huì)根據(jù)你在接口上的@RequestMapping等注解,來(lái)動(dòng)態(tài)構(gòu)造出你要請(qǐng)求的服務(wù)的地址
最后針對(duì)這個(gè)地址,發(fā)起請(qǐng)求、解析響應(yīng)
2. Feign與OpenFeign的區(qū)別
- 他們底層都是內(nèi)置了Ribbon,去調(diào)用注冊(cè)中心的服務(wù)。
- Feign是Netflix公司寫的,是SpringCloud組件中的一個(gè)輕量級(jí)RESTful的HTTP服務(wù)客戶端,是SpringCloud中的第一代負(fù)載均衡客戶端。
- OpenFeign是SpringCloud自己研發(fā)的,在Feign的基礎(chǔ)上支持了Spring
MVC的注解,如@RequesMapping等等。是SpringCloud中的第二代負(fù)載均衡客戶端。 - Feign本身不支持Spring MVC的注解,使用Feign的注解定義接口,調(diào)用這個(gè)接口,就可以調(diào)用服務(wù)注冊(cè)中心的服務(wù)
- OpenFeign的@FeignClient可以解析SpringMVC的@RequestMapping注解下的接口,并通過(guò)動(dòng)態(tài)代理的方式產(chǎn)生實(shí)現(xiàn)類,實(shí)現(xiàn)類中做負(fù)載均衡并調(diào)用其他服務(wù)。
四. 負(fù)載均衡:Ribbon
1. Ribbon支持哪幾種負(fù)載均衡策略
五. 網(wǎng)關(guān):Gateway,Zuul
1. Gateway工作流程
路由判斷:客戶端的請(qǐng)求到達(dá)網(wǎng)關(guān)后,先經(jīng)過(guò) Gateway Handler Mapping 處理,這里面會(huì)做斷言(Predicate)判斷,看下符合哪個(gè)路由規(guī)則,這個(gè)路由映射后端的某個(gè)服務(wù)。
請(qǐng)求過(guò)濾:然后請(qǐng)求到達(dá) Gateway Web Handler,這里面有很多過(guò)濾器,組成過(guò)濾器鏈(Filter Chain),這些過(guò)濾器可以對(duì)請(qǐng)求進(jìn)行攔截和修改,比如添加請(qǐng)求頭、參數(shù)校驗(yàn)等等,有點(diǎn)像凈化污水。然后將請(qǐng)求轉(zhuǎn)發(fā)到實(shí)際的后端服務(wù)。這些過(guò)濾器邏輯上可以稱作 Pre-Filters,Pre 可以理解為“在…之前”。
服務(wù)處理:后端服務(wù)會(huì)對(duì)請(qǐng)求進(jìn)行處理。
響應(yīng)過(guò)濾:后端處理完結(jié)果后,返回給 Gateway 的過(guò)濾器再次做處理,邏輯上可以稱作 Post-Filters,Post 可以理解為“在…之后”。
響應(yīng)返回:響應(yīng)經(jīng)過(guò)過(guò)濾處理后,返回給客戶端。
2. Spring Cloud Gateway 的路由和斷言是什么關(guān)系?
一對(duì)多:一個(gè)路由規(guī)則可以包含多個(gè)斷言。如上圖中路由 Route1 配置了三個(gè)斷言 Predicate。
同時(shí)滿足:如果一個(gè)路由規(guī)則中有多個(gè)斷言,則需要同時(shí)滿足才能匹配。如上圖中路由 Route2 配置了兩個(gè)斷言,客戶端發(fā)送的請(qǐng)求必須同時(shí)滿足這兩個(gè)斷言,才能匹配路由 Route2。
第一個(gè)匹配成功:如果一個(gè)請(qǐng)求可以匹配多個(gè)路由,則映射第一個(gè)匹配成功的路由。如上圖所示,客戶端發(fā)送的請(qǐng)求滿足 Route3 和 Route4 的斷言,但是 Route3 的配置在配置文件中靠前,所以只會(huì)匹配 Route3。
3. Spring Cloud Gateway 如何實(shí)現(xiàn)動(dòng)態(tài)路由?
Spring Cloud Gateway 作為微服務(wù)的入口,需要盡量避免重啟,而現(xiàn)在配置更改需要重啟服務(wù)不能滿足實(shí)際生產(chǎn)過(guò)程中的動(dòng)態(tài)刷新、實(shí)時(shí)變更的業(yè)務(wù)需求,所以我們需要在 Spring Cloud Gateway 運(yùn)行時(shí)動(dòng)態(tài)配置網(wǎng)關(guān)。
實(shí)現(xiàn)動(dòng)態(tài)路由的方式有很多種,其中一種推薦的方式是基于 Nacos 配置中心來(lái)做。簡(jiǎn)單來(lái)說(shuō),我們將將路由配置放在 Nacos 中存儲(chǔ),然后寫個(gè)監(jiān)聽器監(jiān)聽 Nacos 上配置的變化,將變化后的配置更新到 GateWay 應(yīng)用的進(jìn)程內(nèi)。
其實(shí)這些復(fù)雜的步驟并不需要我們手動(dòng)實(shí)現(xiàn),通過(guò) Nacos Server 和 Spring Cloud Alibaba Nacos Config 即可實(shí)現(xiàn)配置的動(dòng)態(tài)變更。
4. Spring Cloud Gateway 支持限流嗎?
Spring Cloud Gateway 自帶了限流過(guò)濾器,對(duì)應(yīng)的接口是 RateLimiter,RateLimiter 接口只有一個(gè)實(shí)現(xiàn)類 RedisRateLimiter (基于 Redis + Lua 實(shí)現(xiàn)的限流),提供的限流功能比較簡(jiǎn)易且不易使用。
從 Sentinel 1.6.0 版本開始,Sentinel 引入了 Spring Cloud Gateway 的適配模塊,可以提供兩種資源維度的限流:route 維度和自定義 API 維度。也就是說(shuō),Spring Cloud Gateway 可以結(jié)合 Sentinel 實(shí)現(xiàn)更強(qiáng)大的網(wǎng)關(guān)流量控制。
六. 限流/熔斷/服務(wù)降級(jí):Hystrix,Sentinel
1. 什么是熔斷和降級(jí)?
- 熔斷機(jī)制
服務(wù)熔斷的作用類似于我們家用的保險(xiǎn)絲,當(dāng)某服務(wù)出現(xiàn)不可用或響應(yīng)超時(shí)的情況時(shí),為了防止整個(gè)系統(tǒng)出現(xiàn)雪崩,暫時(shí)停止對(duì)該服務(wù)的調(diào)用。 - 服務(wù)降級(jí)
服務(wù)降級(jí)是從整個(gè)系統(tǒng)的負(fù)荷情況出發(fā)和考慮的,對(duì)某些負(fù)荷會(huì)比較高的情況,為了預(yù)防某些功能(業(yè)務(wù)場(chǎng)景)出現(xiàn)負(fù)荷過(guò)載或者響應(yīng)慢的情況,在其內(nèi)部暫時(shí)舍棄對(duì)一些非核心的接口和數(shù)據(jù)的請(qǐng)求,而直接返回一個(gè)提前準(zhǔn)備好的fallback(退路)錯(cuò)誤處理信息。這樣,雖然提供的是一個(gè)有損的服務(wù),但卻保證了整個(gè)系統(tǒng)的穩(wěn)定性和可用性。 - 相同點(diǎn)
目標(biāo)一致 都是從可用性和可靠性出發(fā),為了防止系統(tǒng)崩潰;
用戶體驗(yàn)類似 最終都讓用戶體驗(yàn)到的是某些功能暫時(shí)不可用; - 不同點(diǎn)
觸發(fā)原因不同:服務(wù)熔斷一般是某個(gè)服務(wù)(下游服務(wù))故障引起,而服務(wù)降級(jí)一般是從整體負(fù)荷考慮
2. 限流
2.1 常見算法
- 固定窗口計(jì)數(shù)器算法
- 滑動(dòng)窗口計(jì)數(shù)器算法
- 漏桶算法
- 令牌桶算法
2.2 單機(jī)限流
單機(jī)限流可以直接使用 Google Guava 自帶的限流工具類 RateLimiter 。 RateLimiter 基于令牌桶算法,可以應(yīng)對(duì)突發(fā)流量。
2.3 分布式限流
(1) 借助中間件架限流:可以借助 Sentinel 或者使用 Redis 來(lái)自己實(shí)現(xiàn)對(duì)應(yīng)的限流邏輯。
(2)網(wǎng)關(guān)層限流:比較常用的一種方案,直接在網(wǎng)關(guān)層把限流給安排上了。不過(guò),通常網(wǎng)關(guān)層限流通常也需要借助到中間件/框架。就比如 Spring Cloud Gateway 的分布式限流實(shí)現(xiàn)RedisRateLimiter就是基于 Redis+Lua 來(lái)實(shí)現(xiàn)的,再比如 Spring Cloud Gateway 還可以整合 Sentinel 來(lái)做限流。
3. Hystrix和Sentinel簡(jiǎn)單介紹
- Hystrix:發(fā)起請(qǐng)求是通過(guò)Hystrix的線程池來(lái)走的,不同的服務(wù)走不同的線程池,實(shí)現(xiàn)了不同服務(wù)調(diào)用的隔離,避免了服務(wù)雪崩的問(wèn)題
- Sentinel是阿里中間件團(tuán)隊(duì)開源的,面向分布式服務(wù)架構(gòu)的輕量級(jí)高可用流量控制組件,主要以流量為切入點(diǎn),從流量控制、熔斷降級(jí)、系統(tǒng)負(fù)載保護(hù)等多個(gè)維度來(lái)幫助用戶保護(hù)服務(wù)的穩(wěn)定性。