springcloud組件有哪些？

eureka、ribbon負載均衡、feign、hystrix、zuul/gateway網關

nacos、ribbon、feign、sentinel、gateway

服務注冊和發現是什么意思？springcloud如何實現服務注冊發現？

微服務中必須要使用的組件，考察我們使用微服務的程度

注冊中心的核心作用是：服務注冊和發現

常見的注冊中心：eureka、nacos、zookeeper

參考回答：

我們當時項目采用的eureka作為注冊中心，這個是Spring cloud體系中的一個核心組件。

服務注冊：服務提供者需要把自己的信息注冊到eureka，由eureka來保存這些信息，比如服務名稱、IP、端口等等

服務發現：消費者向eureka拉取服務列表信息，如果服務提供者有集群，則消費者會利用負載均衡算法，選擇一個發起調用

服務監控：服務提供者會每隔30秒向eureka發送心跳，報告健康狀態，如果eureka服務90秒沒接收到心跳，從eureka中剔除

nacos和eureka區別

Nacos與eureka的共同點（注冊中心）

1. 都支持服務注冊和服務拉取
2. 都支持服務提供者心跳方式做健康檢測

Nacos與Eureka的區別（注冊中心）

1. Nacos支持服務端主動檢測提供者狀態：臨時實例采用心跳模式，非臨時實例采用主動檢測模式
2. 臨時實例心跳不正常會被剔除，非臨時實例則不會被剔除
3. Nacos支持服務列表變更的消息推送模式，服務列表更新更及時
4. Nacos集群默認采用AP方式，當集群中存在非臨時實例時，采用CP模式；Eureka采用AP方式

Nacos還支持了配置中心，eureka則只有注冊中心，也是選擇使用nacos的一個重要原因

你們項目負載均衡如何實現的？

負載均衡ribbon，發起遠程調用feign就會使用ribbon

回答：微服務的負載均衡主要使用了一個組件ribbon，比如，我們在使用feign遠程調用的過程中，底層的負載均衡就是使用了ribbon

ribbon負載均衡策略有哪些？

1.roundRobinRule：簡單輪詢服務列表來選擇服務器

2.weightedResponseTimeRule：按照權重來選擇服務器，響應時間越長，權重越小

3. RandomRule：隨機選擇一個可用的服務器

4.BestAvailableRule：忽略那些短路的服務器，并選擇并發數較低的服務器

5.RetryRule：重試機制的選擇邏輯

6.AvailabilityFilteringRule：可用性敏感策略，先過濾非健康的，再選擇連接數較小的實例

7.ZoneAvoidanceRule：以區域可用的服務器為基礎進行服務器的選擇。使用Zone對服務器進行分類，這個Zone可以理解為一個機房、一個機架等。而后再對Zone內的多個服務做輪詢（默認）

如果想自定義負載均衡策略如何實現？

可以自己創建類實現IRule接口 , 然后再通過配置類或者配置文件配置即可 ，通過定義IRule實現可以修改負載均衡規則，提供了兩種方式：

1. 創建類實現rule接口，可以指定負載均衡策略（全局）
2. 在客戶端的配置文件中，可以配置某一個服務調用的負載均衡策略（局部）

解決過哪些復雜的問題？什么是服務雪崩？怎么解決這個問題的？

什么是服務雪崩？熔斷降級（解決）限流（預防）

服務雪崩：一個服務失敗，導致整條鏈路的服務都失敗的情況

服務降級：服務自我保護的一種方式，或者保護下游服務的一種方式，用于確保服務不會受請求突增影響變得不可用，確保服務不會崩潰。

服務熔斷：hystrix熔斷機制，用于監控微服務調用情況，默認是關閉的，如果需要開啟需要在引導類上添加注解@EnableCircuitBreaker

如果檢測到 10 秒內請求的失敗率超過 50%，就觸發熔斷機制。之后每隔 5 秒重新嘗試請求微服務，如果微服務不能響應，繼續走熔斷機制。如果微服務可達，則關閉熔斷機制，恢復正常請求

參考回答：

服務雪崩：一個服務失敗，導致整條鏈路的服務都失敗的情形

服務降級：服務自我保護的一種方式，或者保護下游服務的一種方式，用于確保服務不會受請求突增影響變得不可用，確保服務不會崩潰，一般在實際開發中與feign接口整合，編寫降級邏輯

服務熔斷：默認關閉，需要手動打開，如果檢測到 10 秒內請求的失敗率超過 50%，就觸發熔斷機制。之后每隔 5 秒重新嘗試請求微服務，如果微服務不能響應，繼續走熔斷機制。如果微服務可達，則關閉熔斷機制，恢復正常請求

你們微服務是怎么監控的？

你們項目中有沒有做過限流？怎么做的？

為什么要限流？

并發量大（突發流量）

防止用戶惡意刷接口

限流的實現方式：

tomcat：可以設置最大連接數

nginx：漏桶算法

網關：令牌桶算法

自定義攔截器

nginx限流

控制速率（突發流量）

語法：limit_req_zone key zone rate

key:定義限流對象，binary_remote_addr就是一種key，基于客戶端ip限流

Zone：定義共享存儲區來存儲訪問信息，10m可以存儲16wip地址訪問信息

Rate：最大訪問速率，rate=10r/s? 表示每秒最多請求10個請求

burst=20：相當于桶的大小

Nodelay：快速處理

控制并發連接數

limit_conn perip 20：對應的key是 $binary_remote_addr，表示限制單個IP同時最多能持有20個連接。

limit_conn perserver 100：對應的key是 $server_name，表示虛擬主機(server) 同時能處理并發連接的總數。

網關限流

yml配置文件中，微服務路由設置添加局部過濾器RequestRateLimiter

key-resolver ：定義限流對象（ ip 、路徑、參數），需代碼實現，使用spel表達式獲取

replenishRate ：令牌桶每秒填充平均速率。

urstCapacity ：令牌桶總容量。

參考回答：

1，先來介紹業務，什么情況下去做限流，需要說明QPS具體多少

我們當時有一個活動，到了假期就會搶購優惠券，QPS最高可以達到2000，平時10-50之間，為了應對突發流量，需要做限流

常規限流，為了防止惡意攻擊，保護系統正常運行，我們當時系統能夠承受最大的QPS是多少（壓測結果）

2，nginx限流

控制速率（突發流量），使用的漏桶算法來實現過濾，讓請求以固定的速率處理請求，可以應對突發流量

控制并發數，限制單個ip的鏈接數和并發鏈接的總數

3，網關限流

在spring cloud gateway中支持局部過濾器RequestRateLimiter來做限流，使用的是令牌桶算法

可以根據ip或路徑進行限流，可以設置每秒填充平均速率，和令牌桶總容量

限流常見的算法有哪些？

解釋一下CAP和BASE

CAP定理

1998年，加州大學的計算機科學家 Eric Brewer 提出，分布式系統有三個指標：

Consistency（一致性）

Availability（可用性）

Partition tolerance （分區容錯性）

Eric Brewer 說，分布式系統無法同時滿足這三個指標。

這個結論就叫做 CAP 定理。

Consistency（一致性）：用戶訪問分布式系統中的任意節點，得到的數據必須一致

Availability（可用性）：用戶訪問集群中的任意健康節點，得到的數據必須一致

Partition（分區）：因為網絡故障或其它原因導致分布式系統中的部分節點與其它節點失去連接，形成獨立分區。

Tolerance（容錯）：在集群出現分區時，整個系統也要持續對外提供服務

結論：

• 分布式系統節點之間肯定是需要網絡連接的，分區（P）是必然存在的
• 如果保證訪問的高可用性（A）,可以持續對外提供服務，但不能保證數據的強一致性-->? AP
• 如果保證訪問的數據強一致性（C）,就要放棄高可用性?? --> CP

BASE理論

BASE理論是對CAP的一種解決思路，包含三個思想：

Basically Available （基本可用）：分布式系統在出現故障時，允許損失部分可用性，即保證核心可用。

Soft State（軟狀態）：在一定時間內，允許出現中間狀態，比如臨時的不一致狀態。

Eventually Consistent（最終一致性）：雖然無法保證強一致性，但是在軟狀態結束后，最終達到數據一致。

參考回答：

CAP定理（一致性、可用性、分區容錯性）

1、分布式系統節點通過網絡連接，一定會出現分區問題（P）

2、當分區出現時，系統的一致性（C）和可用性（A）就無法同時滿足

BASE理論

1、基本可用

2、軟狀態

3、最終一致

解決分布式事務的思想和模型：

1、最終一致思想：各分支事務分別執行并提交，如果有不一致的情況，再想辦法恢復數據（AP）

2、強一致思想：各分支事務執行完業務不要提交，等待彼此結果。而后統一提交或回滾（CP）

你們采用哪種分布式事務解決方案？

Seata事務管理中有三個重要的角色：

• TC (Transaction Coordinator) - 事務協調者：維護全局和分支事務的狀態，協調全局事務提交或回滾。
• TM (Transaction Manager) - 事務管理器：定義全局事務的范圍、開始全局事務、提交或回滾全局事務。
• RM (Resource Manager) - 資源管理器：管理分支事務處理的資源，與TC交談以注冊分支事務和報告分支事務的狀態，并驅動分支事務提交或回滾。

分布式服務的接口冪等性如何設計？

冪等: 多次調用方法或者接口不會改變業務狀態，可以保證重復調用的結果和單次調用的結果一致。

需要冪等場景

用戶重復點擊（網絡波動）

mq消息重復

應用使用失敗或超時重試機制

接口冪等

基于RESTful API的角度對部分常見類型請求的冪等性特點進行分析

解決冪等：數據庫唯一索引（新增）、token+redis（新增、修改）、分布式鎖（新增、修改）

Token+redis方式

創建商品、提交訂單、轉賬、支付等操作

分布式鎖

參考回答：

1. 冪等: 多次調用方法或者接口不會改變業務狀態，可以保證重復調用的結果和單次調用的結果一致
2. 如果是新增數據，可以使用數據庫的唯一索引
3. 如果是新增或修改數據
   • 分布式鎖，性能較低
   • 使用token+redis來實現，性能較好

第一次請求，生成一個唯一token存入redis，返回給前端

第二次請求，業務處理，攜帶之前的token，到redis進行驗證，如果存在，可以執行業務，刪除token；如果不存在，則直接返回，不處理業務

你們項目中使用了什么分布式任務調度

Xxl-job解決的問題

解決集群任務的重復執行問題

cron表達式定義靈活

定時任務失敗了，重試和統計

任務重大，分片執行

Xxl-job路由策略有哪些？

FIRST（第一個）：固定選擇第一個機器；

LAST（最后一個）：固定選擇最后一個機器；

ROUND（輪詢）

RANDOM（隨機）：隨機選擇在線的機器；

CONSISTENT_HASH（一致性HASH）：每個任務按照Hash算法固定選擇某一臺機器，且所有任務均勻散列在不同機器上。

LEAST_FREQUENTLY_USED（最不經常使用）：使用頻率最低的機器優先被選舉；

LEAST_RECENTLY_USED（最近最久未使用）：最久未使用的機器優先被選舉；

FAILOVER（故障轉移）：按照順序依次進行心跳檢測，第一個心跳檢測成功的機器選定為目標執行器并發起調度；

BUSYOVER（忙碌轉移）：按照順序依次進行空閑檢測，第一個空閑檢測成功的機器選定為目標執行器并發起調度；

SHARDING_BROADCAST(分片廣播)：廣播觸發對應集群中所有機器執行一次任務，同時系統自動傳遞分片參數；可根據分片參數開發分片任務；

回答：xxl-job提供了很多的路由策略，我們平時用的較多就是：輪詢、故障轉移、分片廣播…

Xxl-job任務執行失敗怎么解決？

故障轉移+失敗重試次數，查看日志分析---->郵件告警

回答：

路由策略選擇故障轉移，使用健康的實例來執行任務

設置重試次數

查看日志+郵件告警來通知相關負責人解決

如果有大數據量的任務同時都需要執行，怎么解決？

執行器集群部署時，任務路由策略選擇分片廣播情況下，一次任務調度將會廣播觸發對應集群中所有執行器執行一次任務

分片參數

index：當前分片序號(從0開始)，執行器集群列表中當前執行器的序號；

total：總分片數，執行器集群的總機器數量；

回答：

讓多個實例一塊去執行（部署集群），路由策略分片廣播

在任務執行的代碼中可以獲取分片總數和當前分片，按照取模的方式分攤到各個實例執行