參考資料

概述,總結(jié)的很好

一. 微服務(wù)概述

添加鏈接描述

1. CAP理論

• 一致性(Consistency)
  所有節(jié)點訪問同一份最新的數(shù)據(jù)副本
• 可用性(Availability)
  非故障的節(jié)點在合理的時間內(nèi)返回合理的響應(yīng)（不是錯誤或者超時的響應(yīng)）。
• 分區(qū)容錯性(Partition Tolerance)
  分布式系統(tǒng)出現(xiàn)網(wǎng)絡(luò)分區(qū)的時候，仍然能夠?qū)ν馓峁┓?wù)。
• 網(wǎng)絡(luò)分區(qū)
  分布式系統(tǒng)中，多個節(jié)點之間的網(wǎng)絡(luò)本來是連通的，但是因為某些故障（比如部分節(jié)點網(wǎng)絡(luò)出了問題）某些節(jié)點之間不連通了，整個網(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)中的某個節(jié)點在進行寫操作。為了保證 C， 必須要禁止其他節(jié)點的讀寫操作，這就和 A 發(fā)生沖突了。如果為了保證 A，其他節(jié)點的讀寫操作正常的話，那就和 C 發(fā)生沖突了。
  選擇 CP 還是 AP 的關(guān)鍵在于當前的業(yè)務(wù)場景，沒有定論，比如對于需要確保強一致性的場景如銀行一般會選擇保證 CP 。
  另外，需要補充說明的一點是：如果網(wǎng)絡(luò)分區(qū)正常的話（系統(tǒng)在絕大部分時候所處的狀態(tài)），也就說不需要保證 P 的時候，C 和 A 能夠同時保證。

2. BASE理論

• 概述
  即使無法做到強一致性，但每個應(yīng)用都可以根據(jù)自身業(yè)務(wù)特點，采用適當?shù)姆绞絹硎瓜到y(tǒng)達到最終一致性。BASE 理論本質(zhì)上是對 CAP 的延伸和補充，更具體地說，是對 CAP 中 AP 方案的一個補充。
  如果系統(tǒng)沒有發(fā)生“分區(qū)”的話，節(jié)點間的網(wǎng)絡(luò)連接通信正常的話，也就不存在 P 了。這個時候，我們就可以同時保證 C 和 A 了。因此，如果系統(tǒng)發(fā)生“分區(qū)”，我們要考慮選擇 CP 還是 AP。如果系統(tǒng)沒有發(fā)生“分區(qū)”的話，我們要思考如何保證 CA。
  因此，AP 方案只是在系統(tǒng)發(fā)生分區(qū)的時候放棄一致性，而不是永遠放棄一致性。在分區(qū)故障恢復(fù)后，系統(tǒng)應(yīng)該達到最終一致性。這一點其實就是 BASE 理論延伸的地方。
• 基本可用BA
  基本可用是指分布式系統(tǒng)在出現(xiàn)不可預(yù)知故障的時候，允許損失部分可用性（響應(yīng)時間上的損失/系統(tǒng)功能上的損失)。但是，這絕不等價于系統(tǒng)不可用。
• 軟狀態(tài)S
  軟狀態(tài)指允許系統(tǒng)中的數(shù)據(jù)存在中間狀態(tài)（CAP 理論中的數(shù)據(jù)不一致），并認為該中間狀態(tài)的存在不會影響系統(tǒng)的整體可用性，即允許系統(tǒng)在不同節(jié)點的數(shù)據(jù)副本之間進行數(shù)據(jù)同步的過程存在延時。
• 最終一致性E
  最終一致性強調(diào)的是系統(tǒng)中所有的數(shù)據(jù)副本，在經(jīng)過一段時間的同步后，最終能夠達到一個一致的狀態(tài)。因此，最終一致性的本質(zhì)是需要系統(tǒng)保證最終數(shù)據(jù)能夠達到一致，而不需要實時保證系統(tǒng)數(shù)據(jù)的強一致性。

3. SpringBoot 與 SpringCloud對比

• SpringBoot專注于快速方便得開發(fā)單個個體微服務(wù)。
• SpringCloud是關(guān)注全局的微服務(wù)協(xié)調(diào)整理治理框架，它將SpringBoot開發(fā)的一個個單體微服務(wù)整合并管理起來，為各個微服務(wù)之間提供，配置管理、服務(wù)發(fā)現(xiàn)、斷路器、路由、微代理、事件總線、全局鎖、決策競選、分布式會話等等集成服務(wù)
• SpringBoot可以離開SpringCloud獨立使用開發(fā)項目， 但是SpringCloud離不開SpringBoot，屬于依賴的關(guān)系.
• SpringBoot專注于快速、方便得開發(fā)單個微服務(wù)個體，SpringCloud關(guān)注全局的服務(wù)治理框架。

二. 服務(wù)注冊：Zookeeper,Eureka,Nacos,Consul

1. Nacos兩種健康檢查方式？

(在nacos中服務(wù)提供者是如何向nacos注冊中心續(xù)約的)
(對于nacos服務(wù)來講它是如何判斷服務(wù)實例的狀態(tài)的)

• agent上報模式 （心跳模式，臨時實例）
  客戶端（注冊在nacos上的其它微服務(wù)實例）健康檢查。
  客戶端通過心跳上報方式告知服務(wù)端(nacos注冊中心)健康狀態(tài)；默認心跳間隔5秒；
  nacos會在超過15秒未收到心跳后將實例設(shè)置為不健康狀態(tài)；超過30秒將實例刪除；
• 服務(wù)端主動檢測（非臨時實例）
  服務(wù)端健康檢查。
  nacos主動探知客戶端健康狀態(tài)，默認間隔為20秒；健康檢查失敗后實例會被標記為不健康，不會被立即刪除。

2. nacos中負責負載均衡底層是如何實現(xiàn)的

通過Ribbon實現(xiàn)，Ribbon中定義了負載均衡算法，然后基于這些算法從服務(wù)實例中獲取一個實例為想要服務(wù)方提供服務(wù)

3. Nacos原理

Nacos的實現(xiàn)原理
1.客戶端provider向nacos server的open api發(fā)起調(diào)用,把自己的服務(wù)地址鏈接,服務(wù)名稱注冊上去
2.nacos server與服務(wù)提供者provider建立心跳機制,用來檢測服務(wù)狀態(tài)
3.服務(wù)消費者consumer查詢出提供服務(wù)實例列表
4.并且默認10s去nacos server拉取服務(wù)實例列表
5.當服務(wù)消費者檢測到服務(wù)異常,基于UDP協(xié)議推送更新
6.服務(wù)消費者即可調(diào)用了

4. 臨時實例和持久化(非臨時)實例

臨時和持久化的區(qū)別主要在健康檢查失敗后的表現(xiàn)，持久化實例健康檢查失敗后會被標記成不健康，而臨時實例會直接從列表中被刪除。

三. 服務(wù)調(diào)用：Feign

1. Feign的底層原理

首先，如果你對某個接口定義了**@FeignClient注解**，Feign就會針對這個接口創(chuàng)建一個動態(tài)代理
接著你要是調(diào)用那個接口，本質(zhì)就是會調(diào)用 Feign創(chuàng)建的動態(tài)代理，這是核心中的核心
Feign的動態(tài)代理會根據(jù)你在接口上的@RequestMapping等注解，來動態(tài)構(gòu)造出你要請求的服務(wù)的地址
最后針對這個地址，發(fā)起請求、解析響應(yīng)

2. Feign與OpenFeign的區(qū)別

• 他們底層都是內(nèi)置了Ribbon，去調(diào)用注冊中心的服務(wù)。
• Feign是Netflix公司寫的，是SpringCloud組件中的一個輕量級RESTful的HTTP服務(wù)客戶端，是SpringCloud中的第一代負載均衡客戶端。
• OpenFeign是SpringCloud自己研發(fā)的，在Feign的基礎(chǔ)上支持了Spring
  MVC的注解，如@RequesMapping等等。是SpringCloud中的第二代負載均衡客戶端。
• Feign本身不支持Spring MVC的注解，使用Feign的注解定義接口，調(diào)用這個接口，就可以調(diào)用服務(wù)注冊中心的服務(wù)
• OpenFeign的@FeignClient可以解析SpringMVC的@RequestMapping注解下的接口，并通過動態(tài)代理的方式產(chǎn)生實現(xiàn)類，實現(xiàn)類中做負載均衡并調(diào)用其他服務(wù)。

四. 負載均衡:Ribbon

1. Ribbon支持哪幾種負載均衡策略

五. 網(wǎng)關(guān):Gateway,Zuul

1. Gateway工作流程

路由判斷：客戶端的請求到達網(wǎng)關(guān)后，先經(jīng)過 Gateway Handler Mapping 處理，這里面會做斷言（Predicate）判斷，看下符合哪個路由規(guī)則，這個路由映射后端的某個服務(wù)。
請求過濾：然后請求到達 Gateway Web Handler，這里面有很多過濾器，組成過濾器鏈（Filter Chain），這些過濾器可以對請求進行攔截和修改，比如添加請求頭、參數(shù)校驗等等，有點像凈化污水。然后將請求轉(zhuǎn)發(fā)到實際的后端服務(wù)。這些過濾器邏輯上可以稱作 Pre-Filters，Pre 可以理解為“在…之前”。
服務(wù)處理：后端服務(wù)會對請求進行處理。
響應(yīng)過濾：后端處理完結(jié)果后，返回給 Gateway 的過濾器再次做處理，邏輯上可以稱作 Post-Filters，Post 可以理解為“在…之后”。
響應(yīng)返回：響應(yīng)經(jīng)過過濾處理后，返回給客戶端。

2. Spring Cloud Gateway 的路由和斷言是什么關(guān)系？

一對多：一個路由規(guī)則可以包含多個斷言。如上圖中路由 Route1 配置了三個斷言 Predicate。
同時滿足：如果一個路由規(guī)則中有多個斷言，則需要同時滿足才能匹配。如上圖中路由 Route2 配置了兩個斷言，客戶端發(fā)送的請求必須同時滿足這兩個斷言，才能匹配路由 Route2。
第一個匹配成功：如果一個請求可以匹配多個路由，則映射第一個匹配成功的路由。如上圖所示，客戶端發(fā)送的請求滿足 Route3 和 Route4 的斷言，但是 Route3 的配置在配置文件中靠前，所以只會匹配 Route3。

3. Spring Cloud Gateway 如何實現(xiàn)動態(tài)路由？

Spring Cloud Gateway 作為微服務(wù)的入口，需要盡量避免重啟，而現(xiàn)在配置更改需要重啟服務(wù)不能滿足實際生產(chǎn)過程中的動態(tài)刷新、實時變更的業(yè)務(wù)需求，所以我們需要在 Spring Cloud Gateway 運行時動態(tài)配置網(wǎng)關(guān)。
實現(xiàn)動態(tài)路由的方式有很多種，其中一種推薦的方式是基于 Nacos 配置中心來做。簡單來說，我們將將路由配置放在 Nacos 中存儲，然后寫個監(jiān)聽器監(jiān)聽 Nacos 上配置的變化，將變化后的配置更新到 GateWay 應(yīng)用的進程內(nèi)。
其實這些復(fù)雜的步驟并不需要我們手動實現(xiàn)，通過 Nacos Server 和 Spring Cloud Alibaba Nacos Config 即可實現(xiàn)配置的動態(tài)變更。

4. Spring Cloud Gateway 支持限流嗎？

Spring Cloud Gateway 自帶了限流過濾器，對應(yīng)的接口是 RateLimiter，RateLimiter 接口只有一個實現(xiàn)類 RedisRateLimiter （基于 Redis + Lua 實現(xiàn)的限流），提供的限流功能比較簡易且不易使用。
從 Sentinel 1.6.0 版本開始，Sentinel 引入了 Spring Cloud Gateway 的適配模塊，可以提供兩種資源維度的限流：route 維度和自定義 API 維度。也就是說，Spring Cloud Gateway 可以結(jié)合 Sentinel 實現(xiàn)更強大的網(wǎng)關(guān)流量控制。

六. 限流/熔斷/服務(wù)降級:Hystrix,Sentinel

1. 什么是熔斷和降級？

• 熔斷機制
  服務(wù)熔斷的作用類似于我們家用的保險絲，當某服務(wù)出現(xiàn)不可用或響應(yīng)超時的情況時，為了防止整個系統(tǒng)出現(xiàn)雪崩，暫時停止對該服務(wù)的調(diào)用。
• 服務(wù)降級
  服務(wù)降級是從整個系統(tǒng)的負荷情況出發(fā)和考慮的，對某些負荷會比較高的情況，為了預(yù)防某些功能（業(yè)務(wù)場景）出現(xiàn)負荷過載或者響應(yīng)慢的情況，在其內(nèi)部暫時舍棄對一些非核心的接口和數(shù)據(jù)的請求，而直接返回一個提前準備好的fallback（退路）錯誤處理信息。這樣，雖然提供的是一個有損的服務(wù)，但卻保證了整個系統(tǒng)的穩(wěn)定性和可用性。
• 相同點
  目標一致 都是從可用性和可靠性出發(fā)，為了防止系統(tǒng)崩潰；
  用戶體驗類似 最終都讓用戶體驗到的是某些功能暫時不可用；
• 不同點
  觸發(fā)原因不同：服務(wù)熔斷一般是某個服務(wù)（下游服務(wù)）故障引起，而服務(wù)降級一般是從整體負荷考慮

2. 限流

2.1 常見算法

• 固定窗口計數(shù)器算法
  
• 滑動窗口計數(shù)器算法
  
• 漏桶算法
  
• 令牌桶算法
  

2.2 單機限流

單機限流可以直接使用 Google Guava 自帶的限流工具類 RateLimiter 。 RateLimiter 基于令牌桶算法，可以應(yīng)對突發(fā)流量。

2.3 分布式限流

(1) 借助中間件架限流：可以借助 Sentinel 或者使用 Redis 來自己實現(xiàn)對應(yīng)的限流邏輯。
(2)網(wǎng)關(guān)層限流：比較常用的一種方案，直接在網(wǎng)關(guān)層把限流給安排上了。不過，通常網(wǎng)關(guān)層限流通常也需要借助到中間件/框架。就比如 Spring Cloud Gateway 的分布式限流實現(xiàn)RedisRateLimiter就是基于 Redis+Lua 來實現(xiàn)的，再比如 Spring Cloud Gateway 還可以整合 Sentinel 來做限流。

3. Hystrix和Sentinel簡單介紹

• Hystrix：發(fā)起請求是通過Hystrix的線程池來走的，不同的服務(wù)走不同的線程池，實現(xiàn)了不同服務(wù)調(diào)用的隔離，避免了服務(wù)雪崩的問題
• Sentinel是阿里中間件團隊開源的，面向分布式服務(wù)架構(gòu)的輕量級高可用流量控制組件，主要以流量為切入點，從流量控制、熔斷降級、系統(tǒng)負載保護等多個維度來幫助用戶保護服務(wù)的穩(wěn)定性。