一.Nacos

1.什么是 nacos?

Nacos 的全稱是 Dynamic Naming and Configuration Service,Na 為 naming/nameServer 即注冊中心,co 為 configuration 即注冊中心,service 是指該注冊/配置中心都是以服務(wù)為核心。nacos 默認(rèn)端口 8848

服務(wù)發(fā)現(xiàn)與健康監(jiān)測

動態(tài)配置服務(wù)

動態(tài) DNS 服務(wù)

服務(wù)及其元數(shù)據(jù)管理

Nacos 采用了單一數(shù)據(jù)源，直接解決了分布式和集群部署中的一致性問題。Nacos 使用的 raft 協(xié)議,一致性相對 eureka 較高.

2.nacos 架構(gòu)圖

3.配置中心架構(gòu)圖

4.開源配置中心

微服務(wù)配置文件問題:

• 配置文件相對分散。在一個微服務(wù)架構(gòu)下，配置文件會隨著微服務(wù)的增多變的越來越多，而且分散在各個微服務(wù)中，不好統(tǒng)一配置和管理。

• 配置文件無法區(qū)分環(huán)境。微服務(wù)項(xiàng)目可能會有多個環(huán)境，例如：測試環(huán)境、預(yù)發(fā)布環(huán)境、生產(chǎn)環(huán)境。每一個環(huán)境所使用的配置理論上都是不同的，一旦需要修改，就需要我們?nèi)ジ鱾€微服務(wù)下手動維護(hù)，這比較困難。

• 配置文件無法實(shí)時更新。我們修改了配置文件之后，必須重新啟動微服務(wù)才能使配置生效，這對一個正在運(yùn)行的項(xiàng)目來說是非常不友好的。

配置中心解決思路:

• 首先把項(xiàng)目中各種配置全部都放到一個集中的地方進(jìn)行統(tǒng)一管理，并提供一套標(biāo)準(zhǔn)的接口。

• 當(dāng)各個服務(wù)需要獲取配置的時候，就來配置中心的接口拉取自己的配置。

• 當(dāng)配置中心中的各種參數(shù)有更新的時候，也能通知到各個服務(wù)實(shí)時的過來同步最新的信息，使之動態(tài)更新。

Apollo:Apollo 是由攜程開源的分布式配置中心。特點(diǎn)有很多，比如：配置更新之后可以實(shí)時生效，支持灰度發(fā)布功能，并且能對所有的配置進(jìn)行版本管理、操作審計等功能，提供開放平臺 API。并且資料也寫的很詳細(xì)。

Disconf:Disconf 是由百度開源的分布式配置中心。它是基于 Zookeeper 來實(shí)現(xiàn)配置變更后實(shí)時通知和生效的。

SpringCloud Confifig:這是 Spring Cloud 中帶的配置中心組件。它和 Spring 是無縫集成，使用起來非常方便，并且它的配置存儲支持 Git。不過它沒有可視化的操作界面，配置的生效也不是實(shí)時的，需要重啟或去刷新。

Nacos:這是 SpingCloud alibaba 技術(shù)棧中的一個組件，前面我們已經(jīng)使用它做過服務(wù)注冊中心。其實(shí)它也集成了服務(wù)配置的功能，我們可以直接使用它作為服務(wù)配置中心。

5.Config 配置中心

Nacos Config 主要通過命名空間和 dataId 和 group 來唯一確定一條配置.

Nacos Client 從 Nacos Server 端獲取數(shù)據(jù)時，調(diào)用的是此接口 ConfigService.getConfig(String dataId, String group, long timeoutMs)。

6.配置與控制臺

客戶端配置

#端口號 server:port: 18082#斷電打開 management:endpoint:health:show-details: alwaysendpoints:jmx:exposure:include: "*"web:exposure:include: "*" #spring配置 spring:application:name: nacos-producerprofiles:active: devcloud:nacos:discovery:server-addr: http://120.79.36.53:8848 #服務(wù)注冊地址config:server-addr: http://120.79.36.53:8848 #配置中心地址file-extension: yaml #文件類型group: DEV_GROUP #組別namespace: 64d48a25-ed26-4931-ac47-e9b85ab57e48 #命名空間

7.nacos 三要素

• 命名空間: 命名空間之間是隔離的,可以用來區(qū)分不同的環(huán)境,默認(rèn)是 public
• 組別: 命名空間相同,也可以用組別來區(qū)分環(huán)境,默認(rèn)是 DEFAULT_GROUP
• Data Id: 是微服務(wù)名稱和環(huán)境的結(jié)合體

spring:application:name: nacos-server-consumerprofiles:active: dev #Data Id的取值 Data Id:nacos-server-consumer-dev

Data ID: Data ID 區(qū)分環(huán)境，雖然簡單，但是每個項(xiàng)目要創(chuàng)建多個配置文件，隨著項(xiàng)目的增多，都在一個命名空間下回顯得很混亂，查找起來也不是很方便，而且不利于做權(quán)限控制,不方便管理.

當(dāng)使用 Nacos Config 后，Profile 的配置就存儲到 Data ID 下，即一個 Profile 對應(yīng)一個 Data ID

Data ID 的拼接格式:

${prefix}-${spring.profiles.active}.${file-extension}

• prefix 默認(rèn)為 spring.application.name 的值，也可以通過配置項(xiàng) spring.cloud.nacos.config.prefix 來配置
• spring.profiles.active 取 spring.profiles.active 的值，即為當(dāng)前環(huán)境對應(yīng)的 profile
• file-extension 為配置內(nèi)容的數(shù)據(jù)格式，可以通過配置項(xiàng) spring.cloud.nacos.config.file-extension 來配置

Group:用 Group 區(qū)分，問題也是一樣的,出現(xiàn)很多的配置文件,不方便管理,Group 默認(rèn)是 DEFAULT_GROUP,可以自定義組別,這個屬性主要區(qū)分業(yè)務(wù),比如說訂單微服務(wù)一個組,用戶微服務(wù)一個組,便于區(qū)分和數(shù)據(jù)管理.

Namespace:Namespace 區(qū)分環(huán)境，清晰明了，而且有利于做權(quán)限控制,方便管理配置文件

nacos 命名空間默認(rèn)是 public,可以自定義新建命名空間,主要用在區(qū)分環(huán)境,不同的環(huán)境下面使用不同的命名空間,不同命名空間的服務(wù)不能相互調(diào)用.

配置的時候不是配置命名空間名稱,應(yīng)該配置命名空間的 id

8.配置動態(tài)刷新

nacos config 使用長連接更新配置, 一旦配置有變動后，通知 Provider 的過程非常的迅速, 從速度上秒殺 springcloud 原來的 config 幾條街.

@RestController public class NacosConfigController {@Value( "${config.appName}" )private String appName;@GetMapping("/nacos-config-test2")public String nacosConfingTest2(){return(appName);} }

共享配置:

• 同一微服務(wù)，不同場景（namespace）下共享配置
• 不同微服務(wù)之間共享共享配置

高可用:在 nacos 服務(wù)宕機(jī)時,暫時使用本地的文件,從 CAP 架構(gòu)上來說,實(shí)現(xiàn)了 AP,高可用架構(gòu).在 nacos 服務(wù)宕機(jī)了后,客戶端還能繼續(xù)訪問服務(wù)端,保證業(yè)務(wù)流程不因 nacos 宕機(jī)變成完全不可用.

9.nacos 持久化

1.默認(rèn)數(shù)據(jù)庫

默認(rèn)持久化方式,是使用 derby 數(shù)據(jù)庫.在 0.7 版本之前，在單機(jī)模式時 nacos 使用嵌入式數(shù)據(jù)庫實(shí)現(xiàn)數(shù)據(jù)的存儲，不方便觀察數(shù)據(jù)存儲的基本情況。0.7 版本增加了支持 mysql 數(shù)據(jù)源能力,Derby 是 Java 編寫的數(shù)據(jù)庫，屬于 Apache 的一個開源項(xiàng)目

2.修改配置

修改腳本 application.properties

### If use MySQL as datasource: spring.datasource.platform=mysql### Count of DB: db.num=1### Connect URL of DB: db.url.0=jdbc:mysql://120.79.36.53:3306/nacos_config?characterEncoding=utf8&connectTimeout=1000&socketTimeout=3000&autoReconnect=true&useUnicode=true&useSSL=false&serverTimezone=UTC db.user.0=root db.password.0=xxxxxxx

3.執(zhí)行腳本

mysql-schema.sql

4.新增配置

10.集群部署

Nacos Server 有兩種運(yùn)行模式：

• standalone
• cluster

使用集群的模式部署 nacos,cluster 模式啟動,

在客戶端配置多個節(jié)點(diǎn)信息,也可以用 nginx 做多個節(jié)點(diǎn)的負(fù)載均衡,在客戶端配置 nginx 的訪問節(jié)點(diǎn)也是可以的

#使用單機(jī)部署 sh bin/startup.sh -m standalone#訪問 默認(rèn)賬號和密碼為：nacos nacos http://xxxx:8848/nacos

nginx 代理 nacos 集群

upstream nacos_server {server 127.0.0.1:8848;server 127.0.0.1:8847;server 127.0.0.1:8846; }server { listen 8648;server_name localhost;#charset koi8-r;#access_log logs/host.access.log main;location / {proxy_pass http://nacos_server;index index.html index.htm;} }

nacos 的集群選舉算法是自己實(shí)現(xiàn)的Raft 算法，主要是對于naming 服務(wù)，動態(tài)配置服務(wù)是沒有用到這個 raft 集群心跳和數(shù)據(jù)更新的功能的；

功能點(diǎn)主要有三點(diǎn)：

• leader 選舉：使用 Raft 的 leaderdue 時間，到期后發(fā)起選舉，投票過半為 leader
• 心跳：leader 定時發(fā)送心跳給 follower，心跳還可能打包 datum(可以關(guān)閉)信息給 follower 節(jié)點(diǎn)；follower 節(jié)點(diǎn)收到心跳重置選舉 leaderdue 避免發(fā)生選舉，并且如果發(fā)現(xiàn) datum 數(shù)據(jù)有變化會更新內(nèi)存和本地文件緩存，數(shù)據(jù)變化 term 會增加 100，會刪除 dead 的 datum
• 數(shù)據(jù)更新：每次數(shù)據(jù)更新的時候，如果請求發(fā)送到 follower 節(jié)點(diǎn)會轉(zhuǎn)發(fā)給 leader 處理數(shù)據(jù)，由 leader 先更新本地數(shù)據(jù)，然后分別異步發(fā)送給其他 follower，如果超過半數(shù)的 follower 更新成功那么數(shù)據(jù)就更新成功了。

注意：

datum 指的的對于注冊的服務(wù)和實(shí)例抽象包裝

term 類似于 zookeeper 的 zxid；term 投票時會添加 1，數(shù)據(jù)更新會增加 100；zk 的是分為前 32 位和后 32 位分別累計選舉年代和數(shù)據(jù)更新遞增

11.Nacos 2.X 的優(yōu)點(diǎn)

Nacos 1.X 的痛點(diǎn):Nacos 1.X 心跳多，無效查詢多，心跳續(xù)約感知變化慢，連接消耗大，資源空耗嚴(yán)重。

• 心跳數(shù)量多，導(dǎo)致 TPS 居高不下
• 通過心跳續(xù)約感知服務(wù)變化，時延長
• UDP 推送不可靠，導(dǎo)致 QPS 居高不下
• 基于 HTTP 短連接模型，TIME_WAIT 狀態(tài)連接過多
• 配置模塊的 30 秒長輪詢引起的頻繁 GC

HTTP 短連接模型，每次客戶端請求都會創(chuàng)建和銷毀 TCP 鏈接，TCP 協(xié)議銷毀的鏈接狀態(tài)是 WAIT_TIME，完全釋放還需要一定時間，當(dāng) TPS 和 QPS 較高時，服務(wù)端和客戶端可能有大量的 WAIT_TIME 狀態(tài)鏈接，從而會導(dǎo)致 connect time out 錯誤或者 Cannot assign requested address 的問題。

Nacos 2.X 的優(yōu)點(diǎn):

• 客戶端不再需要定時發(fā)送實(shí)例心跳，只需要有一個維持連接可用 keepalive 消息即可。重復(fù) TPS 可以大幅降低。
• TCP 連接斷開可以被快速感知到，提升反應(yīng)速度。
• 長連接的流式推送，比 UDP 更加可靠；nio 的機(jī)制具有更高的吞吐量，而且由于可靠推送，可以加長客戶端用于對賬服務(wù)列表的時間，甚至刪除相關(guān)的請求。重復(fù)的無效 QPS 可以大幅降低。
• 長連接避免頻繁連接開銷，可以大幅緩解 TIME_ WAIT 問題。
• 真實(shí)的長連接，解決配置模塊 GC 問題。
• 更細(xì)粒度的同步內(nèi)容，減少服務(wù)節(jié)點(diǎn)間的通信壓力。

12.注冊中心對比

Spring Cloud Eureka :

• AP 模型，數(shù)據(jù)最終一致性
• 客戶端注冊服務(wù)上報所有信息，節(jié)點(diǎn)多的情況下，網(wǎng)絡(luò)，服務(wù)端壓力過大，且浪費(fèi)內(nèi)存
• 客戶端更新服務(wù)信息通過簡單的輪詢機(jī)制，當(dāng)服務(wù)數(shù)量巨大時，服務(wù)器壓力過大。
• 集群伸縮性不強(qiáng)，服務(wù)端集群通過廣播式的復(fù)制，增加服務(wù)器壓力
• Eureka2.0 閉源（Spring Cloud 最新版本還是使用的 1.X 版本的 Eureka）

Spring Cloud Zookeeper ：

• CP 模型，ZAB 算法，數(shù)據(jù)強(qiáng)一致性
• 維護(hù)成本較高，客戶端，session 狀態(tài)，網(wǎng)絡(luò)故障等問題，會導(dǎo)致服務(wù)異常
• 集群伸縮性限制，內(nèi)存，GC 和連接
• 無控制臺管理

Spring cloud Consul：

• 適用于 Service Mesh 架構(gòu)，使用于 JAVA 生態(tài)
• AP 模型，Raft+Gossip 算法，數(shù)據(jù)最終一致性
• 未經(jīng)大規(guī)模市場驗(yàn)證，無法保證可靠性
• Go 語言編寫，內(nèi)部異常排查困難

Spring Cloud Nacos ：

• 開箱即用，適用于 dubbo，spring cloud
• AP 模型，數(shù)據(jù)最終一致性
• 注冊中心，配置中心二合一，提供控制臺管理
• 純國產(chǎn)，久經(jīng)雙十一考驗(yàn)

13.注冊中心原理

服務(wù)注冊的策略的是每 5 秒向 nacos server 發(fā)送一次心跳，心跳帶上了服務(wù)名，服務(wù) ip，服務(wù)端口等信息。同時 nacos server 也會向 client 主動發(fā)起健康檢查，支持 tcp/http 檢查。如果 15 秒內(nèi)無心跳且健康檢查失敗則認(rèn)為實(shí)例不健康，如果 30 秒內(nèi)健康檢查失敗則剔除實(shí)例。

14.配置自動刷新的原理?

LongPollingRunnable:如果 md5 值不一樣，則發(fā)送數(shù)據(jù)變更通知，調(diào)用 safeNotifyListener 方法_

所以我們知道了這個 run 方法里面創(chuàng)建了一個 Runnable 方法，并放入線程池中，每隔 29.5s 執(zhí)行一次，如果無變更，就正常返回，如果有變更（md5 比較不相同），則調(diào)用 sendResponse(changedGroups);方法響應(yīng)客戶端

15.注冊的原理?

注冊的邏輯主要在 NacosNamingService 實(shí)現(xiàn)類,registerInstance 是注冊實(shí)例.具體實(shí)現(xiàn)在 NamingHttpClientProxy

public class NacosNamingService implements NamingService {@Overridepublic void registerInstance(String serviceName, String groupName, String ip, int port, String clusterName)throws NacosException {Instance instance = new Instance();instance.setIp(ip);instance.setPort(port);instance.setWeight(1.0);instance.setClusterName(clusterName);registerInstance(serviceName, groupName, instance);} } //NamingHttpClientProxy#deregisterService,里面有對實(shí)例的增刪改查@Override public void deregisterService(String serviceName, String groupName, Instance instance) throws NacosException {NAMING_LOGGER.info("[DEREGISTER-SERVICE] {} deregistering service {} with instance: {}", namespaceId, serviceName,instance);if (instance.isEphemeral()) {return;}final Map<String, String> params = new HashMap<>(16);params.put(CommonParams.NAMESPACE_ID, namespaceId);params.put(CommonParams.SERVICE_NAME, NamingUtils.getGroupedName(serviceName, groupName));params.put(CommonParams.CLUSTER_NAME, instance.getClusterName());params.put(IP_PARAM, instance.getIp());params.put(PORT_PARAM, String.valueOf(instance.getPort()));params.put(EPHEMERAL_PARAM, String.valueOf(instance.isEphemeral()));reqApi(UtilAndComs.nacosUrlInstance, params, HttpMethod.DELETE); } public class ServiceManager {private static final ServiceManager INSTANCE = new ServiceManager();private final ConcurrentHashMap<Service, Service> singletonRepository;private final ConcurrentHashMap<String, Set<Service>> namespaceSingletonMaps; }

16.防止讀寫沖突?

在更新實(shí)例列表時，會采用 CopyOnWrite 技術(shù)，首先將舊的實(shí)例列表拷貝一份，然后更新拷貝的實(shí)例列表，再用更新后的實(shí)例列表來覆蓋舊的實(shí)例列表。這樣在更新的過程中，就不會對讀實(shí)例列表的請求產(chǎn)生影響，也不會出現(xiàn)臟讀問題了。

使用 CopyOnWrite 技術(shù),主要是因?yàn)樵讷@取實(shí)例列表的場景下,屬于讀多寫少的場景,在讀的時候不加鎖,寫的時候加鎖,消耗一點(diǎn)性能,但是最大限度的提高了讀的效率,也就是常說的空間換時間,這個時間指的是讀取實(shí)例的時間.

17.Alibaba 和 Netflix 套件

仔細(xì)看看各組件的功能描述，Spring Cloud Alibaba 套件和 Spring Cloud Netflix 套件大致的對應(yīng)關(guān)系：

• Nacos = Eureka/Consule + Config + Admin
• Sentinel = Hystrix + Dashboard + Turbine
• Dubbo = Ribbon + Feign
• RocketMQ = RabbitMQ
• SchedulerX = Quartz
• Seata=AT+TCC 分布式事務(wù)解決組件
• AliCloud OSS、AliCloud SLS、Alibaba Cloud SMS 這三個應(yīng)該是獨(dú)有的

二.Sentinel

1.基本概念

響應(yīng)時間(RT) :響應(yīng)時間是指系統(tǒng)對請求作出響應(yīng)的時間。往往也需要對每個或每組功能討論其平均響應(yīng)時間和最大響應(yīng)時間。響應(yīng)時間是一個合理且準(zhǔn)確的性能指標(biāo)。響應(yīng)時間的絕對值并不能直接反映軟件的性能的高低，軟件性能的高低實(shí)際上取決于用戶對該響應(yīng)時間的接受程度。
吞吐量(Throughput) :吞吐量是指系統(tǒng)在單位時間內(nèi)處理請求的數(shù)量。對于無并發(fā)的應(yīng)用系統(tǒng)而言，吞吐量與響應(yīng)時間成嚴(yán)格的反比關(guān)系，實(shí)際上此時吞吐量就是響應(yīng)時間的倒數(shù)。
并發(fā)用戶數(shù) :并發(fā)用戶數(shù)是指系統(tǒng)可以同時承載的正常使用系統(tǒng)功能的用戶的數(shù)量。與吞吐量相比，并發(fā)用戶數(shù)是一個更直觀但也更籠統(tǒng)的性能指標(biāo)。
QPS每秒查詢率(Query Per Second) :每秒查詢率 QPS 是對一個特定的查詢服務(wù)器在規(guī)定時間內(nèi)所處理流量多少的衡量標(biāo)準(zhǔn)，在因特網(wǎng)上，作為域名系統(tǒng)服務(wù)器的機(jī)器的性能經(jīng)常用每秒查詢率來衡量。對應(yīng) fetches/sec，即每秒的響應(yīng)請求數(shù)，也即是最大吞吐能力。

2.容錯設(shè)計?

• 流控：即流量控制，根據(jù)流量、并發(fā)線程數(shù)、響應(yīng)時間等指標(biāo)，把隨機(jī)到來的流量調(diào)整成合適的形狀，即流量塑性，保證系統(tǒng)在流量突增情況下的可用性，避免系統(tǒng)被瞬時的流量高峰沖垮，一旦達(dá)到閾值則進(jìn)行拒絕服務(wù)、排隊等降級操作。

• 熔斷：當(dāng)下游服務(wù)發(fā)生一定數(shù)量的失敗后，打開熔斷器，后續(xù)請求就快速失敗。一段時間過后再判斷下游服務(wù)是否已恢復(fù)正常，從而決定是否重置熔斷器。

• 降級：當(dāng)訪問量劇增、服務(wù)出現(xiàn)異常或者非核心服務(wù)影響到核心流程時，暫時犧牲掉一些東西，以保障整個系統(tǒng)的平穩(wěn)運(yùn)行。

• 隔離：將系統(tǒng)或資源分隔開，保證系統(tǒng)故障時，能限定傳播范圍和影響范圍，防止?jié)L雪球效應(yīng)，保證只有出問題的服務(wù)不可用，服務(wù)間的相互不影響。常見的隔離手段：資源隔離、線程隔離、進(jìn)程隔離、集群隔離、機(jī)房隔離、讀寫隔離、快慢隔離、動靜隔離等。

• 超時：相當(dāng)多的服務(wù)不可用問題，都是客戶端超時機(jī)制不合理導(dǎo)致的，當(dāng)服務(wù)端發(fā)生抖動時，如果超時時間過長，客戶端一直處于占用連接等待響應(yīng)的階段，耗盡服務(wù)端資源，最終導(dǎo)致服務(wù)端集群雪崩；如果超時時間設(shè)置過短又會造成調(diào)用服務(wù)未完成而返回，所以一個健康的服務(wù)，一定要有超時機(jī)制，根據(jù)業(yè)務(wù)場景選擇恰當(dāng)?shù)某瑫r閾值。

• 冪等：當(dāng)用戶多次請求同一事件時，得到的結(jié)果永遠(yuǎn)是同一個

3.Sentinel 簡介

隨著微服務(wù)的流行，服務(wù)和服務(wù)之間的穩(wěn)定性變得越來越重要。Sentinel 是面向分布式、多語言異構(gòu)化服務(wù)架構(gòu)的流量治理組件，主要以流量為切入點(diǎn)，從流量路由、流量控制、流量整形、熔斷降級、系統(tǒng)自適應(yīng)過載保護(hù)、熱點(diǎn)流量防護(hù)等多個維度來幫助開發(fā)者保障微服務(wù)的穩(wěn)定性。

4.Sentinel 特征

Sentinel.具有以下特征：

• 豐富的應(yīng)用場景：Sentinel 承接了阿里巴巴近 10 年的雙十一大促流量的核心場景，例如秒殺（即突發(fā)流量控制在系統(tǒng)容量可以承受的范圍）、消息削峰填谷、集群流量控制、實(shí)時熔斷下游不可用應(yīng)用等。
• 完備的實(shí)時監(jiān)控：Sentinel 同時提供實(shí)時的監(jiān)控功能。您可以在控制臺中看到接入應(yīng)用的單臺機(jī)器秒級數(shù)據(jù)，甚至 500 臺以下規(guī)模的集群的匯總運(yùn)行情況。
• 廣泛的開源生態(tài)：Sentinel 提供開箱即用的與其它開源框架/庫的整合模塊，例如與 Spring Cloud、Apache Dubbo、gRPC、Quarkus 的整合。您只需要引入相應(yīng)的依賴并進(jìn)行簡單的配置即可快速地接入 Sentinel。同時 Sentinel 提供 Java/Go/C++ 等多語言的原生實(shí)現(xiàn)。
• 完善的 SPI 擴(kuò)展機(jī)制：Sentinel 提供簡單易用、完善的 SPI 擴(kuò)展接口。您可以通過實(shí)現(xiàn)擴(kuò)展接口來快速地定制邏輯。例如定制規(guī)則管理、適配動態(tài)數(shù)據(jù)源等。

5.Sentinel 分為兩個部分

• 核心庫（Java 客戶端）不依賴任何框架/庫，能夠運(yùn)行于所有 Java 運(yùn)行時環(huán)境，同時對 Dubbo / Spring Cloud 等框架也有較好的支持。
• 控制臺（Dashboard）基于 Spring Boot 開發(fā)，打包后可以直接運(yùn)行，不需要額外的 Tomcat 等應(yīng)用容器。

控制臺功能

功能功能功能

實(shí)時監(jiān)控	族點(diǎn)鏈路	流控規(guī)則
熔斷規(guī)則	熱點(diǎn)規(guī)則	系統(tǒng)規(guī)則
授權(quán)規(guī)則	集群流控	機(jī)器列表

6.Sentinel 的基本概念

資源:資源是 Sentinel 的關(guān)鍵概念。它可以是 Java 應(yīng)用程序中的任何內(nèi)容，例如，由應(yīng)用程序提供的服務(wù)，或由應(yīng)用程序調(diào)用的其它應(yīng)用提供的服務(wù)，甚至可以是一段代碼。在接下來的文檔中，我們都會用資源來描述代碼塊。

只要通過 Sentinel API 定義的代碼，就是資源，能夠被 Sentinel 保護(hù)起來。大部分情況下，可以使用方法簽名，URL，甚至服務(wù)名稱作為資源名來標(biāo)示資源。

規(guī)則:圍繞資源的實(shí)時狀態(tài)設(shè)定的規(guī)則，可以包括流量控制規(guī)則、熔斷降級規(guī)則以及系統(tǒng)保護(hù)規(guī)則。所有規(guī)則可以動態(tài)實(shí)時調(diào)整。

資源定義 2 種方式

• Sentinel API 定義的代碼
• @SentinelResource 注解

7.@SentinelResource

@SentinelResource 注解用于定義資源埋點(diǎn)，但不支持 private 方法。默認(rèn)情況下，Sentinel 對控制資源的保護(hù)處理是直接拋出異常，這樣對用戶不友好，所以我們需要通過可選的異常處理 blockHandler 和 fallback 配置項(xiàng)處理一下異常信息

@SentinelResource 屬性：

• value：資源名稱，必需項(xiàng),不能為空
• blockHandler / blockHandlerClass: blockHandler 對應(yīng)處理 BlockException 的函數(shù)名稱，可選項(xiàng)。blockHandler 函數(shù)訪問范圍需要是 public，返回類型需要與原方法相匹配，參數(shù)類型需要和原方法相匹配并且最后加一個額外的參數(shù)，類型為 BlockException。blockHandler 函數(shù)默認(rèn)需要和原方法在同一個類中。若希望使用其他類的函數(shù)，則可以指定 blockHandlerClass 為對應(yīng)的類的 Class 對象，注意對應(yīng)的函數(shù)必需為 static 函數(shù)，否則無法解析。
• fallback / fallbackClass：fallback 函數(shù)名稱，可選項(xiàng)，用于在拋出異常的時候提供 fallback 處理邏輯。fallback 函數(shù)可以針對所有類型的異常（除了 exceptionsToIgnore 里面排除掉的異常類型）進(jìn)行處理。fallback 函數(shù)簽名和位置要求：1、返回值類型必須與原函數(shù)返回值類型一致；2、方法參數(shù)列表需要和原函數(shù)一致，或者可以額外多一個 Throwable 類型的參數(shù)用于接收對應(yīng)的異常。3、fallback 函數(shù)默認(rèn)需要和原方法在同一個類中。若希望使用其他類的函數(shù)，則可以指定 fallbackClass 為對應(yīng)的類的 Class 對象，注意對應(yīng)的函數(shù)必需為 static 函數(shù)，否則無法解析。
• defaultFallback（since 1.6.0）：默認(rèn)的 fallback 函數(shù)名稱，可選項(xiàng)，通常用于通用的 fallback 邏輯（即可以用于很多服務(wù)或方法）。默認(rèn) fallback 函數(shù)可以針對所有類型的異常（除了 exceptionsToIgnore 里面排除掉的異常類型）進(jìn)行處理。若同時配置了 fallback 和 defaultFallback，則只有 fallback 會生效。defaultFallback 函數(shù)簽名要求：1、返回值類型必須與原函數(shù)返回值類型一致；2、方法參數(shù)列表需要為空，或者可以額外多一個 Throwable 類型的參數(shù)用于接收對應(yīng)的異常。3、defaultFallback 函數(shù)默認(rèn)需要和原方法在同一個類中。若希望使用其他類的函數(shù)，則可以指定 fallbackClass 為對應(yīng)的類的 Class 對象，注意對應(yīng)的函數(shù)必需為 static 函數(shù)，否則無法解析。
• exceptionsToIgnore（since 1.6.0）：用于指定哪些異常被排除掉，不會計入異常統(tǒng)計中，也不會進(jìn)入 fallback 邏輯中，而是會原樣拋出。

blockHandler 自定義異常

@GetMapping("/testHotKey") @SentinelResource(value = "testHotKey", blockHandler = "dealHandler_testHotKey") public String testHotKey(@RequestParam(value = "p1", required = false) String p1,@RequestParam(value = "p2", required = false) String p2) {log.info("testE 熱點(diǎn)參數(shù)");return "------testHotKey"; }public String dealHandler_testHotKey(String p1, String p2, BlockException exception) {// 默認(rèn) Blocked by Sentinel (flow limiting)return "-----dealHandler_testHotKey"; }

Sentinel常見異常:

• FlowException 限流異常
• DegradeException 降級熔斷異常
• ParamFlowException 熱點(diǎn)參數(shù)異常
• SystemBlockException 系統(tǒng)異常
• AuthorityException 授權(quán),鑒權(quán)異常

8.流控規(guī)則設(shè)計理念?

流量控制有以下幾個角度:

• 資源的調(diào)用關(guān)系，例如資源的調(diào)用鏈路，資源和資源之間的關(guān)系；
• 運(yùn)行指標(biāo)，例如 QPS、線程池、系統(tǒng)負(fù)載等；
• 控制的效果，例如直接限流、冷啟動、排隊等。

Sentinel 的設(shè)計理念是讓您自由選擇控制的角度，并進(jìn)行靈活組合，從而達(dá)到想要的效果。

9.流控規(guī)則實(shí)現(xiàn)?

FlowRule 流控規(guī)則:同一個資源可以創(chuàng)建多條限流規(guī)則。FlowSlot 會對該資源的所有限流規(guī)則依次遍歷，直到有規(guī)則觸發(fā)限流或者所有規(guī)則遍歷完畢。

• resource：資源名，即限流規(guī)則的作用對象，唯一，默認(rèn)請求路徑。
• 針對來源：針對調(diào)用者進(jìn)行限流，填寫微服務(wù)名，若為 default 則不區(qū)分調(diào)用來源。
• 閾值類型
  • QPS(每秒鐘的請求數(shù)量)：當(dāng)調(diào)用該 resource 的 QPS 達(dá)到閾值的時候進(jìn)行限流。
  • 線程數(shù)：當(dāng)調(diào)用該 resource 的線程數(shù)達(dá)到閾值的時候進(jìn)行限流。
• 單機(jī)閾值：閾值
• 流控模式
  • 直接：達(dá)到限流條件直接限流。
  • 關(guān)聯(lián)：當(dāng)關(guān)聯(lián)的資源達(dá)到閾值時，就限流自己。
  • 鏈路：當(dāng)從入口資源進(jìn)來的流量達(dá)到閾值，就對指定資源進(jìn)行限流。
• 流控效果：
  • 快速失敗：直接失敗，拋出異常。
  • Warm Up：根據(jù) codeFactor(冷加載因子，默認(rèn)為 3)的值，從閾值/codeFactor,經(jīng)過設(shè)定的預(yù)熱時長，逐漸到達(dá)設(shè)置的 QPS 閾值。
  • 排隊等待：勻速排隊，讓請求以勻速通過，閾值類型必須設(shè)置為 QPS，否則無效。

10.關(guān)聯(lián)和鏈路的區(qū)別

說明

• 關(guān)聯(lián): A 資源關(guān)聯(lián) B 資源, 當(dāng) B 資源到達(dá)閾值時, 限流 A 資源
• 鏈路: A 資源入口資源為 B 資源, 當(dāng) A 資源到達(dá)閾值時, 限流 B 資源

其實(shí)關(guān)聯(lián)和鏈路是有本質(zhì)區(qū)別的

• 直接: 單個接口的限流
• 關(guān)聯(lián): 平級接口的限流
  • 高優(yōu)先級資源觸發(fā)閾值，對低優(yōu)先級資源限流。
• 鏈路: 上下級接口的限流
  • 資源閾值統(tǒng)計時，只統(tǒng)計從指定資源進(jìn)入當(dāng)前資源的請求，是對請求來源的限流

舉個例子

• 關(guān)聯(lián)
  配置: “查詢訂單” 關(guān)聯(lián) “下單” 接口, 當(dāng)"下單"到達(dá)閾值, 限流"查詢訂單"接口
• 鏈路
  配置: “查詢訂單的 service” 入口資源 “查詢訂單”, 當(dāng)"查詢訂單的 service"到達(dá)閾值時, 限流"查詢訂單”

11.Warm Up(預(yù)熱)

Warm Up 方式:即預(yù)熱/冷啟動方式。當(dāng)系統(tǒng)長期處于低水位的情況下，當(dāng)流量突然增加時，直接把系統(tǒng)拉升到高水位可能瞬間把系統(tǒng)壓垮。通過"冷啟動"，讓通過的流量緩慢增加，在一定時間內(nèi)逐漸增加到閾值上限，給冷系統(tǒng)一個預(yù)熱的時間，避免冷系統(tǒng)被壓垮。如秒殺系統(tǒng)在開啟瞬間，會有很多流量上來，很可能把系統(tǒng)打死，預(yù)熱方式就是為了保護(hù)系統(tǒng)，可慢慢的把流量放進(jìn)來，慢慢的把閾值增長到設(shè)置的閾值。

主要原理是它會根據(jù) codeFactor(冷加載因子,默認(rèn)為 3)的值，開始只能接受(閾值/codeFactor)流量,經(jīng)過設(shè)定的預(yù)熱時長，逐漸到達(dá)設(shè)置的 QPS 閾值。

例如:我們配置資源/testB，使用閾值類型為 QPS，單機(jī)閾值設(shè)置為 5，流控效果選擇 Warm Up，其它默認(rèn)，此設(shè)置的含義為：開始只能每秒接受 5/codeFactor 個請求,經(jīng)過設(shè)定的預(yù)熱時長(5 秒)，逐漸到達(dá)設(shè)置的 QPS 閾值 5，效果為：開始訪問 http://localhost:8401/testB 時每秒請求別超過 5/3 個才能正常訪問，5 秒后可以接受的請求可以達(dá)到每秒 5 次。

12.排隊等待

注意：勻速排隊模式暫時不支持 QPS > 1000 的場景。

勻速排隊方式會嚴(yán)格控制請求通過的間隔時間，也即是讓請求以均勻的速度通過，對應(yīng)的是漏桶算法，閾值類型必須設(shè)置為 QPS，否則無效。

例如:我們配置資源/testB，使用閾值類型為 QPS，單機(jī)閾值設(shè)置為 2，流控效果選擇排隊等待，超時時間設(shè)置為 20000ms(20 秒)，其它默認(rèn)，此設(shè)置的含義為：代表一秒勻速的通過 2 個請求，也就是每個請求平均間隔恒定為 1000 / 2 = 500 ms，每一個請求的最長等待時間為 20s。

13.熔斷降級設(shè)計理念

在限制的手段上，Sentinel 和 Hystrix 采取了完全不一樣的方法。Hystrix 通過線程池隔離的方式，來對依賴（在 Sentinel 的概念中對應(yīng)資源）進(jìn)行了隔離。這樣做的好處是資源和資源之間做到了最徹底的隔離。缺點(diǎn)是除了增加了線程切換的成本（過多的線程池導(dǎo)致線程數(shù)目過多），還需要預(yù)先給各個資源做線程池大小的分配。

Sentinel 對這個問題采取了兩種手段:

通過并發(fā)線程數(shù)進(jìn)行限制:和資源池隔離的方法不同，Sentinel 通過限制資源并發(fā)線程的數(shù)量，來減少不穩(wěn)定資源對其它資源的影響。這樣不但沒有線程切換的損耗，也不需要您預(yù)先分配線程池的大小。當(dāng)某個資源出現(xiàn)不穩(wěn)定的情況下，例如響應(yīng)時間變長，對資源的直接影響就是會造成線程數(shù)的逐步堆積。當(dāng)線程數(shù)在特定資源上堆積到一定的數(shù)量之后，對該資源的新請求就會被拒絕。堆積的線程完成任務(wù)后才開始繼續(xù)接收請求。

通過響應(yīng)時間對資源進(jìn)行降級:除了對并發(fā)線程數(shù)進(jìn)行控制以外，Sentinel 還可以通過響應(yīng)時間來快速降級不穩(wěn)定的資源。當(dāng)依賴的資源出現(xiàn)響應(yīng)時間過長后，所有對該資源的訪問都會被直接拒絕，直到過了指定的時間窗口之后才重新恢復(fù)。

14.熔斷規(guī)則?

除了流量控制以外，及時對調(diào)用鏈路中的不穩(wěn)定因素進(jìn)行熔斷也是 Sentinel 的使命之一。由于調(diào)用關(guān)系的復(fù)雜性，如果調(diào)用鏈路中的某個資源出現(xiàn)了不穩(wěn)定，可能會導(dǎo)致請求發(fā)生堆積，進(jìn)而導(dǎo)致級聯(lián)錯誤。

Sentinel 和 Hystrix 的原則是一致的: 當(dāng)檢測到調(diào)用鏈路中某個資源出現(xiàn)不穩(wěn)定的表現(xiàn)，例如請求響應(yīng)時間長或異常比例升高的時候，則對這個資源的調(diào)用進(jìn)行限制，讓請求快速失敗，避免影響到其它的資源而導(dǎo)致級聯(lián)故障。

DegradeRule 熔斷規(guī)則

Field說明默認(rèn)值

resource	資源名，即規(guī)則的作用對象
grade	熔斷策略，支持慢調(diào)用比例/異常比例/異常數(shù)策略	慢調(diào)用比例
count	慢調(diào)用比例模式下為慢調(diào)用臨界 RT（超出該值計為慢調(diào)用）；異常比例/異常數(shù)模式下為對應(yīng)的閾值
timeWindow	熔斷時長，單位為 s
minRequestAmount	熔斷觸發(fā)的最小請求數(shù)，請求數(shù)小于該值時即使異常比率超出閾值也不會熔斷（1.7.0 引入	5
statIntervalMs	統(tǒng)計時長（單位為 ms），如 60*1000 代表分鐘級（1.8.0 引入）	1000ms
slowRatioThreshold	慢調(diào)用比例閾值，僅慢調(diào)用比例模式有效（1.8.0 引入）

15.熔斷策略

Sentinel 提供以下幾種熔斷策略：

• 慢調(diào)用比例 (SLOW_REQUEST_RATIO)：選擇以慢調(diào)用比例作為閾值，需要設(shè)置允許的慢調(diào)用 RT（即最大的響應(yīng)時間），請求的響應(yīng)時間大于該值則統(tǒng)計為慢調(diào)用。當(dāng)單位統(tǒng)計時長（statIntervalMs）內(nèi)請求數(shù)目大于設(shè)置的最小請求數(shù)目，并且慢調(diào)用的比例大于閾值，則接下來的熔斷時長內(nèi)請求會自動被熔斷。經(jīng)過熔斷時長后熔斷器會進(jìn)入探測恢復(fù)狀態(tài)（HALF-OPEN 狀態(tài)），若接下來的一個請求響應(yīng)時間小于設(shè)置的慢調(diào)用 RT 則結(jié)束熔斷，若大于設(shè)置的慢調(diào)用 RT 則會再次被熔斷。
• 異常比例 (ERROR_RATIO)：當(dāng)單位統(tǒng)計時長（statIntervalMs）內(nèi)請求數(shù)目大于設(shè)置的最小請求數(shù)目，并且異常的比例大于閾值，則接下來的熔斷時長內(nèi)請求會自動被熔斷。經(jīng)過熔斷時長后熔斷器會進(jìn)入探測恢復(fù)狀態(tài)（HALF-OPEN 狀態(tài)），若接下來的一個請求成功完成（沒有錯誤）則結(jié)束熔斷，否則會再次被熔斷。異常比率的閾值范圍是 [0.0, 1.0]，代表 0% - 100%。
• 異常數(shù) (ERROR_COUNT)：當(dāng)單位統(tǒng)計時長內(nèi)的異常數(shù)目超過閾值之后會自動進(jìn)行熔斷。經(jīng)過熔斷時長后熔斷器會進(jìn)入探測恢復(fù)狀態(tài)（HALF-OPEN 狀態(tài)），若接下來的一個請求成功完成（沒有錯誤）則結(jié)束熔斷，否則會再次被熔斷。

16.慢調(diào)用比例

例如:如果 1 秒內(nèi)持續(xù)進(jìn)入大于等于 5 個請求，并且請求響應(yīng)的時間大于 200ms 時，這個請求即為慢調(diào)用，當(dāng)慢調(diào)用的比例大于 1 時會觸發(fā)降級，直到 5 秒后新的請求的響應(yīng)時間小于 200ms 時，才結(jié)束熔斷。

17.異常比例

例如:如果 1 秒內(nèi)持續(xù)進(jìn)入大于等于 5 個請求，并且請求中報異常的比例超過 0.2 則觸發(fā)降級(降級時間持續(xù) 5 秒)，5 秒后，新的請求若正常返回，才結(jié)束熔斷。

18.異常數(shù)

例如: 如果 1 秒內(nèi)持續(xù)進(jìn)入大于等于 5 個請求，并且請求異常數(shù)超過 5 時，會觸發(fā)降級(降級時間持續(xù) 5 秒)，5 秒后，新的請求若正常返回，才結(jié)束熔斷。

19.熱點(diǎn)規(guī)則

熱點(diǎn)規(guī)則(ParamFlowRule): 熱點(diǎn)即經(jīng)常訪問的數(shù)據(jù)。很多時候我們希望統(tǒng)計某個熱點(diǎn)數(shù)據(jù)中訪問頻次最高的 Top K 數(shù)據(jù)，并對其訪問進(jìn)行限制。比如：

• 商品 ID 為參數(shù)，統(tǒng)計一段時間內(nèi)最常購買的商品 ID 并進(jìn)行限制
• 用戶 ID 為參數(shù)，針對一段時間內(nèi)頻繁訪問的用戶 ID 進(jìn)行限制

熱點(diǎn)參數(shù)限流會統(tǒng)計傳入?yún)?shù)中的熱點(diǎn)參數(shù)，并根據(jù)配置的限流閾值與模式，對包含熱點(diǎn)參數(shù)的資源調(diào)用進(jìn)行限流。熱點(diǎn)參數(shù)限流可以看做是一種特殊的流量控制，僅對包含熱點(diǎn)參數(shù)的資源調(diào)用生效。

20.熱點(diǎn)規(guī)則示例

@GetMapping("/testHotKey") @SentinelResource(value = "testHotKey") public String testHotKey(@RequestParam(value = "p1", required = false) String p1,@RequestParam(value = "p2", required = false) String p2) {return "------testHotKey"; }

說明:當(dāng)攜帶第一個參數(shù)(p1)訪問/testHotKey 的請求量超過 1 秒 5 個時，進(jìn)行降級，攜帶第二個參數(shù)訪問永遠(yuǎn)不會觸發(fā)降級

21.參數(shù)例外項(xiàng)

當(dāng)攜帶第一個參數(shù)(p1)訪問/testHotKey 的請求量超過 1 秒 5 個時，進(jìn)行降級，特殊的當(dāng)傳的參數(shù)為 a 時，請求量超過 1 秒 100 才進(jìn)行降級。

22.授權(quán)規(guī)則

AuthorityRule:很多時候，我們需要根據(jù)調(diào)用方來限制資源是否通過，這時候可以使用 Sentinel 的訪問控制（黑白名單）的功能。黑白名單根據(jù)資源的請求來源（origin）限制資源是否通過，若配置白名單則只有請求來源位于白名單內(nèi)時才可通過；若配置黑名單則請求來源位于黑名單時不通過，其余的請求通過。

• resource：資源名，即限流規(guī)則的作用對象
• limitApp：對應(yīng)的黑名單/白名單，不同 origin 用 , 分隔，如 appA,appB
• strategy：限制模式，AUTHORITY_WHITE 為白名單模式，AUTHORITY_BLACK 為黑名單模式，默認(rèn)為白名單模式 比如我們希望控制對資源 test 的訪問設(shè)置白名單，只有來源為 appA 和 appB 的請求才可通過，則可以配置如下白名單規(guī)則：

AuthorityRule rule = new AuthorityRule(); rule.setResource("test"); rule.setStrategy(RuleConstant.AUTHORITY_WHITE); rule.setLimitApp("appA,appB"); AuthorityRuleManager.loadRules(Collections.singletonList(rule));

23.系統(tǒng)規(guī)則

系統(tǒng)保護(hù)規(guī)則是從應(yīng)用級別的入口流量進(jìn)行控制，從單臺機(jī)器的總體 Load、RT、入口 QPS 、CPU 使用率和線程數(shù)五個維度監(jiān)控應(yīng)用數(shù)據(jù)，讓系統(tǒng)盡可能跑在最大吞吐量的同時保證系統(tǒng)整體的穩(wěn)定性。 系統(tǒng)保護(hù)規(guī)則是應(yīng)用整體維度的，而不是資源維度的，并且僅對入口流量 (進(jìn)入應(yīng)用的流量) 生效。

• Load 自適應(yīng)（僅對 Linux/Unix-like 機(jī)器生效）：系統(tǒng)的 load1 作為啟發(fā)指標(biāo)，進(jìn)行自適應(yīng)系統(tǒng)保護(hù)。當(dāng)系統(tǒng) load1 超過設(shè)定的啟發(fā)值，且系統(tǒng)當(dāng)前的并發(fā)線程數(shù)超過估算的系統(tǒng)容量時才會觸發(fā)系統(tǒng)保護(hù)（BBR 階段）。系統(tǒng)容量由系統(tǒng)的 maxQps _ minRt 估算得出。設(shè)定參考值一般是 CPU cores _ 2.5。
• CPU 使用率：當(dāng)單臺機(jī)器上所有入口流量的 CPU 使用率達(dá)到閾值即觸發(fā)系統(tǒng)保護(hù)
• 平均 RT：當(dāng)單臺機(jī)器上所有入口流量的平均 RT 達(dá)到閾值即觸發(fā)系統(tǒng)保護(hù)，單位是毫秒。
• 并發(fā)線程數(shù)：當(dāng)單臺機(jī)器上所有入口流量的并發(fā)線程數(shù)達(dá)到閾值即觸發(fā)系統(tǒng)保護(hù)。
• 入口 QPS：當(dāng)單臺機(jī)器上所有入口流量的 QPS 達(dá)到閾值即觸發(fā)系統(tǒng)保護(hù)。

24.sentinel 持久化

主要分為拉模式和推模式

• 拉模式:持久化到本地文件

• 推模式:持久化到 nacos 或者 mysql

次重啟項(xiàng)目后在 Sentinel 中配置的規(guī)則都會清空，很是麻煩，我們可以通過持久化的方式解決這個問題。

可以將規(guī)則持久化到 nacos 或者 mysql,再最新的 sentinel1.8.6 版本,更新 sentinel 控制臺和 nacos 是互通的,修改任何一個位置,另一處會跟著改變,這一點(diǎn)還是比較人性化的,但是啟動的時候還是以 nacos 的配置為準(zhǔn).

[{"resource": "/flowLimit/persistent","limitApp": "default","grade": 1,"count": 1,"strategy": 0,"controlBehavior": 0,"clusterMode": false},{"resource": "/flowLimit/testHotKey","limitApp": "default","grade": 1,"count": 1,"strategy": 0,"controlBehavior": 0,"clusterMode": false} ]

25.工作原理

在 Sentinel 里面，所有的資源都對應(yīng)一個資源名稱（resourceName），每次資源調(diào)用都會創(chuàng)建一個 Entry 對象。Entry 可以通過對主流框架的適配自動創(chuàng)建，也可以通過注解的方式或調(diào)用 SphU API 顯式創(chuàng)建。Entry 創(chuàng)建的時候，同時也會創(chuàng)建一系列功能插槽（slot chain），這些插槽有不同的職責(zé)，例如:

• NodeSelectorSlot : 負(fù)責(zé)收集資源的路徑，并將這些資源的調(diào)用路徑，以樹狀結(jié)構(gòu)存儲起來，用于根據(jù)調(diào)用路徑來限流降級；
• ClusterBuilderSlot : 則用于存儲資源的統(tǒng)計信息以及調(diào)用者信息，例如該資源的 RT, QPS, thread count 等等，這些信息將用作為多維度限流，降級的依據(jù)；
• StatisticSlot : 則用于記錄、統(tǒng)計不同緯度的 runtime 指標(biāo)監(jiān)控信息；滑動窗口是其實(shí)現(xiàn);
• FlowSlot : 則用于根據(jù)預(yù)設(shè)的限流規(guī)則以及前面 slot 統(tǒng)計的狀態(tài)，來進(jìn)行流量控制；
• AuthoritySlot : 則根據(jù)配置的黑白名單和調(diào)用來源信息，來做黑白名單控制；
• DegradeSlot: 則通過統(tǒng)計信息以及預(yù)設(shè)的規(guī)則，來做熔斷降級；
• SystemSlot : 則通過系統(tǒng)的狀態(tài)，例如 load1 等，來控制總的入口流量；

每個 Slot 執(zhí)行完業(yè)務(wù)邏輯處理后，會調(diào)用 fireEntry()方法，該方法將會觸發(fā)下一個節(jié)點(diǎn)的 entry 方法，下一個節(jié)點(diǎn)又會調(diào)用他的 fireEntry，以此類推直到最后一個 Slot，由此就形成了 sentinel 的責(zé)任鏈。

26.插槽 Slot

Sentinel 將 ProcessorSlot 作為 SPI 接口進(jìn)行擴(kuò)展（1.7.2 版本以前 SlotChainBuilder 作為 SPI），使得 Slot Chain 具備了擴(kuò)展的能力。您可以自行加入自定義的 slot 并編排 slot 間的順序，從而可以給 Sentinel 添加自定義的功能。

sentinel 的工作流程就是圍繞著一個個插槽所組成的插槽鏈來展開的。默認(rèn)的各個插槽之間的順序是固定的，因?yàn)橛械牟宀坌枰蕾嚻渌牟宀塾嬎愠鰜淼慕Y(jié)果才能進(jìn)行工作。

sentinel 通過 SlotChainBuilder 作為 SPI 接口，使得 Slot Chain 具備了擴(kuò)展的能力。我們可以通過實(shí)現(xiàn) SlotsChainBuilder 接口加入自定義的 slot 并自定義編排各個 slot 之間的順序，從而可以給 sentinel 添加自定義的功能。

@Spi(isDefault = true) public class DefaultSlotChainBuilder implements SlotChainBuilder {@Overridepublic ProcessorSlotChain build() {ProcessorSlotChain chain = new DefaultProcessorSlotChain();List<ProcessorSlot> sortedSlotList = SpiLoader.of(ProcessorSlot.class).loadInstanceListSorted();for (ProcessorSlot slot : sortedSlotList) {if (!(slot instanceof AbstractLinkedProcessorSlot)) {RecordLog.warn("The ProcessorSlot(" + slot.getClass().getCanonicalName() + ") is not an instance of AbstractLinkedProcessorSlot, can't be added into ProcessorSlotChain");continue;}chain.addLast((AbstractLinkedProcessorSlot<?>) slot);}return chain;} }

總結(jié):sentinel 的限流降級等功能，主要是通過一個 SlotChain 實(shí)現(xiàn)的。在鏈?zhǔn)讲宀壑?#xff0c;有 7 個核心的 Slot，這些 Slot 各司其職，可以分為以下幾種類型：

• 一、進(jìn)行資源調(diào)用路徑構(gòu)造的 NodeSelectorSlot 和 ClusterBuilderSlot

• 二、進(jìn)行資源的實(shí)時狀態(tài)統(tǒng)計的 StatisticsSlot

• 三、進(jìn)行系統(tǒng)保護(hù)，限流，降級等規(guī)則校驗(yàn)的 SystemSlot、AuthoritySlot、FlowSlot、DegradeSlot

后面幾個 Slot 依賴于前面幾個 Slot 統(tǒng)計的結(jié)果。

27.chainMap 設(shè)計

public class CtSph implements Sph {private static final Object[] OBJECTS0 = new Object[0];//使用的普通的map,在高并發(fā)場景下,減少鎖帶來的性能消耗,因?yàn)椴皇侨勘仨毤渔iprivate static volatile Map<ResourceWrapper, ProcessorSlotChain> chainMap= new HashMap<ResourceWrapper, ProcessorSlotChain>();private static final Object LOCK = new Object(); }

構(gòu)建責(zé)任鏈: 上面的代碼簡單來說，就是從 chainMap 里面獲取 slot 功能鏈， 沒有的話，就構(gòu)建一個，這里需要注意一點(diǎn) Constants.MAX_SLOT_CHAIN_SIZE , chainMap 是限制了大小，最大不能超過 6000， 也就是說，默認(rèn)不能超過 6000 個資源，如果超過 6000 個資源，則會有資源的限流沒辦法生效

執(zhí)行責(zé)任鏈就是執(zhí)行各種 slot.

ProcessorSlot<Object> lookProcessChain(ResourceWrapper resourceWrapper) {// 根據(jù)資源獲取slot功能鏈ProcessorSlotChain chain = chainMap.get(resourceWrapper);if (chain == null) {// 上鎖保證僅會初始化一個,雙檢鎖synchronized (LOCK) {chain = chainMap.get(resourceWrapper);if (chain == null) {// Entry size limit. 最大的資源大小是6000個if (chainMap.size() >= Constants.MAX_SLOT_CHAIN_SIZE) {return null;}//構(gòu)建一個slot引用鏈 -----chain = SlotChainProvider.newSlotChain();// map存儲,寫時復(fù)制,提高讀取的效率,容量加1Map<ResourceWrapper, ProcessorSlotChain> newMap = new HashMap<ResourceWrapper, ProcessorSlotChain>(chainMap.size() + 1);newMap.putAll(chainMap);newMap.put(resourceWrapper, chain);chainMap = newMap;}}}return chain; }

28.常見 node

節(jié)點(diǎn)作用

StatisticNode	執(zhí)行具體的資源統(tǒng)計操作
DefaultNode	該節(jié)點(diǎn)持有指定上下文中指定資源的統(tǒng)計信息，當(dāng)在同一個上下文中多次調(diào)用 entry 方法時，該節(jié)點(diǎn)可能下會創(chuàng)建有一系列的子節(jié)點(diǎn)。 另外每個 DefaultNode 中會關(guān)聯(lián)一個 ClusterNode
ClusterNode	該節(jié)點(diǎn)中保存了資源的總體的運(yùn)行時統(tǒng)計信息，包括 rt，線程數(shù)，qps 等等，相同的資源會全局共享同一個 ClusterNode，不管他屬于哪個上下文
EntranceNode	該節(jié)點(diǎn)表示一棵調(diào)用鏈樹的入口節(jié)點(diǎn)，通過他可以獲取調(diào)用鏈樹中所有的子節(jié)點(diǎn)

29.滑動窗口實(shí)現(xiàn)

//SAMPLE_COUNT是窗口個數(shù),INTERVAL是總時間,intervalInMs/窗口數(shù)量= 窗口長度 public class StatisticNode implements Node {//秒級統(tǒng)計窗口是2個,每個統(tǒng)計時間是500msprivate transient volatile Metric rollingCounterInSecond = new ArrayMetric(SampleCountProperty.SAMPLE_COUNT,IntervalProperty.INTERVAL);//分鐘級統(tǒng)計窗口是60個,每個統(tǒng)計時間是1sprivate transient Metric rollingCounterInMinute = new ArrayMetric(60, 60 * 1000, false); }

窗口統(tǒng)計的事件:這是最基本的指標(biāo)，然后通過這些指標(biāo)，又可以計算出來比如說最大，最小，平均等等的一些指標(biāo)。

//窗口統(tǒng)計的事件 public enum MetricEvent {PASS,BLOCK,EXCEPTION,SUCCESS,RT,OCCUPIED_PASS }

MetricBucket 是窗口里面的統(tǒng)計指標(biāo)的具體實(shí)現(xiàn),MetricBucket 是由 LongAdder 數(shù)組組成的，一個 LongAdder 就是一個 MetricEvent,主要作用是創(chuàng)建各個事件,初始化最小 RT

public class WindowWrap<T> {/*** 單個窗口的時間長度（毫秒）*/private final long windowLengthInMs;/*** 窗口的開始時間戳（毫秒）。*/private long windowStart;/*** 統(tǒng)計數(shù)據(jù)。*/private T value;/*** 判斷給定時間是否在當(dāng)前窗口中*/public boolean isTimeInWindow(long timeMillis) {return windowStart <= timeMillis && timeMillis < windowStart + windowLengthInMs;} }

LeapArray

//Leap數(shù)組使用滑動窗口算法來計數(shù)數(shù)據(jù) public abstract class LeapArray<T> {protected int windowLengthInMs;protected int sampleCount;protected int intervalInMs;private double intervalInSecond;protected final AtomicReferenceArray<WindowWrap<T>> array;/*** 更新鎖僅在不推薦使用當(dāng)前存儲桶時使用*/private final ReentrantLock updateLock = new ReentrantLock();/***這個構(gòu)造方法其實(shí)就是計算出來這個窗口長度，創(chuàng)建了窗口數(shù)組。*/public LeapArray(int sampleCount, int intervalInMs) {AssertUtil.isTrue(sampleCount > 0, "bucket count is invalid: " + sampleCount);AssertUtil.isTrue(intervalInMs > 0, "total time interval of the sliding window should be positive");AssertUtil.isTrue(intervalInMs % sampleCount == 0, "time span needs to be evenly divided");this.windowLengthInMs = intervalInMs / sampleCount;this.intervalInMs = intervalInMs;this.intervalInSecond = intervalInMs / 1000.0;this.sampleCount = sampleCount;this.array = new AtomicReferenceArray<>(sampleCount);} }

30.Sentinel 和 hystrix

Hystrix 的資源模型設(shè)計上采用了命令模式，將對外部資源的調(diào)用和 fallback 邏輯封裝成一個命令對象（HystrixCommand / HystrixObservableCommand），其底層的執(zhí)行是基于 RxJava 實(shí)現(xiàn)的。每個 Command 創(chuàng)建時都要指定 commandKey 和 groupKey（用于區(qū)分資源）以及對應(yīng)的隔離策略（線程池隔離 or 信號量隔離）。線程池隔離模式下需要配置線程池對應(yīng)的參數(shù)（線程池名稱、容量、排隊超時等），然后 Command 就會在指定的線程池按照指定的容錯策略執(zhí)行；信號量隔離模式下需要配置最大并發(fā)數(shù)，執(zhí)行 Command 時 Hystrix 就會限制其并發(fā)調(diào)用。

Sentinel 的設(shè)計則更為簡單。相比 Hystrix Command 強(qiáng)依賴隔離規(guī)則，Sentinel 的資源定義與規(guī)則配置的耦合度更低。Hystrix 的 Command 強(qiáng)依賴于隔離規(guī)則配置的原因是隔離規(guī)則會直接影響 Command 的執(zhí)行。在執(zhí)行的時候 Hystrix 會解析 Command 的隔離規(guī)則來創(chuàng)建 RxJava Scheduler 并在其上調(diào)度執(zhí)行，若是線程池模式則 Scheduler 底層的線程池為配置的線程池，若是信號量模式則簡單包裝成當(dāng)前線程執(zhí)行的 Scheduler。而 Sentinel 并不指定執(zhí)行模型，也不關(guān)注應(yīng)用是如何執(zhí)行的。Sentinel 的原則非常簡單：根據(jù)對應(yīng)資源配置的規(guī)則來為資源執(zhí)行相應(yīng)的限流/降級/負(fù)載保護(hù)策略。在 Sentinel 中資源定義和規(guī)則配置是分離的。用戶先通過 Sentinel API 給對應(yīng)的業(yè)務(wù)邏輯定義資源（埋點(diǎn)），然后可以在需要的時候配置規(guī)則。埋點(diǎn)方式有兩種：

• try-catch 方式（通過 SphU.entry(...)），用戶在 catch 塊中執(zhí)行異常處理 / fallback
• if-else 方式（通過 SphO.entry(...)），當(dāng)返回 false 時執(zhí)行異常處理 / fallback

從 0.1.1 版本開始，Sentinel 還支持基于注解的資源定義方式，可以通過注解參數(shù)指定異常處理函數(shù)和 fallback 函數(shù)。

從 0.2.0 版本開始，Sentinel 引入異步調(diào)用鏈路支持，可以方便地統(tǒng)計異步調(diào)用資源的數(shù)據(jù)，維護(hù)異步調(diào)用鏈路，同時具備了適配異步框架/庫的能力。

Sentinel 提供多樣化的規(guī)則配置方式。除了直接通過 loadRules API 將規(guī)則注冊到內(nèi)存態(tài)之外，用戶還可以注冊各種外部數(shù)據(jù)源來提供動態(tài)的規(guī)則。用戶可以根據(jù)系統(tǒng)當(dāng)前的實(shí)時情況去動態(tài)地變更規(guī)則配置，數(shù)據(jù)源會將變更推送至 Sentinel 并即時生效。

隔離設(shè)計

隔離是 Hystrix 的核心功能之一。Hystrix 提供兩種隔離策略：線程池隔離（Bulkhead Pattern）和信號量隔離，其中最推薦也是最常用的是線程池隔離。Hystrix 的線程池隔離針對不同的資源分別創(chuàng)建不同的線程池，不同服務(wù)調(diào)用都發(fā)生在不同的線程池中，在線程池排隊、超時等阻塞情況時可以快速失敗，并可以提供 fallback 機(jī)制。線程池隔離的好處是隔離度比較高，可以針對某個資源的線程池去進(jìn)行處理而不影響其它資源，但是代價就是線程上下文切換的 overhead 比較大，特別是對低延時的調(diào)用有比較大的影響。

但是，實(shí)際情況下，線程池隔離并沒有帶來非常多的好處。首先就是過多的線程池會非常影響性能。考慮這樣一個場景，在 Tomcat 之類的 Servlet 容器使用 Hystrix，本身 Tomcat 自身的線程數(shù)目就非常多了（可能到幾十或一百多），如果加上 Hystrix 為各個資源創(chuàng)建的線程池，總共線程數(shù)目會非常多（幾百個線程），這樣上下文切換會有非常大的損耗。另外，線程池模式比較徹底的隔離性使得 Hystrix 可以針對不同資源線程池的排隊、超時情況分別進(jìn)行處理，但這其實(shí)是超時熔斷和流量控制要解決的問題，如果組件具備了超時熔斷和流量控制的能力，線程池隔離就顯得沒有那么必要了。

Hystrix 的信號量隔離限制對某個資源調(diào)用的并發(fā)數(shù)。這樣的隔離非常輕量級，僅限制對某個資源調(diào)用的并發(fā)數(shù)，而不是顯式地去創(chuàng)建線程池，所以 overhead 比較小，但是效果不錯，也支持超時失敗。Sentinel 可以通過并發(fā)線程數(shù)模式的流量控制來提供信號量隔離的功能。并且結(jié)合基于響應(yīng)時間的熔斷降級模式，可以在不穩(wěn)定資源的平均響應(yīng)時間比較高的時候自動降級，防止過多的慢調(diào)用占滿并發(fā)數(shù)，影響整個系統(tǒng)。

31.ContextUtil

ContextUtil 很經(jīng)典,使用了很多并發(fā)編程中的知識

先從 ThreadLocal 中嘗試獲取，獲取到則直接返回

如果第一步?jīng)]有獲取，嘗試從緩存中獲取該上下文名稱對應(yīng)的 入口節(jié)點(diǎn)

判斷緩存中入口節(jié)點(diǎn)數(shù)量是否大于 2000public final static int MAX_CONTEXT_NAME_SIZE = 2000;如果已經(jīng)大于 2000，返回一個 NULL_CONTEXT

以上檢查都通過根據(jù)上下文名稱生成入口節(jié)點(diǎn)（entranceNode），期間會進(jìn)行雙關(guān)檢索確保線程安全

加入至全局根節(jié)點(diǎn)下，并加入緩存，注意每個 ContextName 對應(yīng)一個入口節(jié)點(diǎn) entranceNode

根據(jù) ContextName 和 entranceNode 初始化上下文對象，并將上下文對象設(shè)置到當(dāng)前線程中

public class ContextUtil {/*** Store the context in ThreadLocal for easy access.*/private static ThreadLocal<Context> contextHolder = new ThreadLocal<>();/*** Holds all {@link EntranceNode}. Each {@link EntranceNode} is associated with a distinct context name.*/private static volatile Map<String, DefaultNode> contextNameNodeMap = new HashMap<>();private static final ReentrantLock LOCK = new ReentrantLock();private static final Context NULL_CONTEXT = new NullContext();static {// Cache the entrance node for default context.initDefaultContext();}private static void initDefaultContext() {String defaultContextName = Constants.CONTEXT_DEFAULT_NAME;EntranceNode node = new EntranceNode(new StringResourceWrapper(defaultContextName, EntryType.IN), null);Constants.ROOT.addChild(node);contextNameNodeMap.put(defaultContextName, node);}//SentinelResource注解生效的入口public static Context enter(String name, String origin) {if (Constants.CONTEXT_DEFAULT_NAME.equals(name)) {throw new ContextNameDefineException("The " + Constants.CONTEXT_DEFAULT_NAME + " can't be permit to defined!");}return trueEnter(name, origin);}protected static Context trueEnter(String name, String origin) {Context context = contextHolder.get();if (context == null) {Map<String, DefaultNode> localCacheNameMap = contextNameNodeMap;DefaultNode node = localCacheNameMap.get(name);if (node == null) {if (localCacheNameMap.size() > Constants.MAX_CONTEXT_NAME_SIZE) {setNullContext();return NULL_CONTEXT;} else {LOCK.lock();try {node = contextNameNodeMap.get(name);if (node == null) {if (contextNameNodeMap.size() > Constants.MAX_CONTEXT_NAME_SIZE) {setNullContext();return NULL_CONTEXT;} else {node = new EntranceNode(new StringResourceWrapper(name, EntryType.IN), null);// Add entrance node.Constants.ROOT.addChild(node);Map<String, DefaultNode> newMap = new HashMap<>(contextNameNodeMap.size() + 1);newMap.putAll(contextNameNodeMap);newMap.put(name, node);contextNameNodeMap = newMap;}}} finally {LOCK.unlock();}}}context = new Context(node, name);context.setOrigin(origin);contextHolder.set(context);}return context;}//xXXXXXXXXXXXXXXXx }

三.Gateway

1.網(wǎng)關(guān)的基本功能?

簡化客戶端的工作。網(wǎng)關(guān)將微服務(wù)封裝起來后，客戶端只需同網(wǎng)關(guān)交互，而不必調(diào)用各個不同服務(wù)；

降低函數(shù)間的耦合度。 一旦服務(wù)接口修改，只需修改網(wǎng)關(guān)的路由策略，不必修改每個調(diào)用該函數(shù)的客戶端，從而減少了程序間的耦合性

解放開發(fā)人員把精力專注于業(yè)務(wù)邏輯的實(shí)現(xiàn)。由網(wǎng)關(guān)統(tǒng)一實(shí)現(xiàn)服務(wù)路由(灰度與 ABTest)、負(fù)載均衡、訪問控制、流控熔斷降級等非業(yè)務(wù)相關(guān)功能，而不需要每個服務(wù) API 實(shí)現(xiàn)時都去考慮

2.主流網(wǎng)關(guān)的對比?

網(wǎng)關(guān)（API Gateway）的設(shè)計要素:

限流：實(shí)現(xiàn)微服務(wù)訪問流量計算，基于流量計算分析進(jìn)行限流，可以定義多種限流規(guī)則。

緩存：數(shù)據(jù)緩存。

日志：日志記錄。

監(jiān)控：記錄請求響應(yīng)數(shù)據(jù)，api耗時分析，性能監(jiān)控。

鑒權(quán)：權(quán)限身份認(rèn)證。

灰度：線上灰度部署，可以減小風(fēng)險。

路由：路由是API網(wǎng)關(guān)很核心的模塊功能，此模塊實(shí)現(xiàn)根據(jù)請求，鎖定目標(biāo)微服務(wù)并將
請求進(jìn)行轉(zhuǎn)發(fā)。

簡單介紹下你的網(wǎng)關(guān)實(shí)施方案:

開發(fā)語言：java + groovy，groovy的好處是網(wǎng)關(guān)服務(wù)不需要重啟
就可以動態(tài)的添加filter來實(shí) 現(xiàn)一些功能；

微服務(wù)基礎(chǔ)框架：springboot；

網(wǎng)關(guān)基礎(chǔ)組件：netflix zuul；

服務(wù)注冊中心：consul；

權(quán)限校驗(yàn)：jwt；

API監(jiān)控：prometheus + grafana；

API統(tǒng)一日志收集：logback + ELK；

壓力測試：Jmeter；

3.什么是 gateway?

springcloud 全家桶中國有個很重要的組件就是網(wǎng)關(guān)，在 1.x 版本中都是采用的 zuul 網(wǎng)關(guān)；zuul 是 netfix 開發(fā)的一個網(wǎng)關(guān)組件，但在 2.x 版本中，zuul 由于更新迭代的速度過慢，于是 springcloud 就自己推出了一個新的網(wǎng)關(guān)組件，那就是 gateway。

gateway 是在 spring 生態(tài)系統(tǒng)之上構(gòu)建的 API 網(wǎng)關(guān)服務(wù)，基于 Spring 5，Spring Boot2 和 Project Reactor 等技術(shù)。gateway 旨在提供一種簡單而有效的方式來對 API 進(jìn)行路由，以及提供一些強(qiáng)大的過濾器功能，例如：反向代理、熔斷、限流、重試等。

SpringCloud Gateway 是基于WebFlux框架實(shí)現(xiàn)的，而 WebFlux 框架底層則使用了高性能的Reactor模式通信框架Netty。

4.gateway 特性?

• 動態(tài)路由，能夠匹配任何請求屬性；
• 可以對路由指定 Predicate（斷言）和 Filter（過濾器），且易于編寫；
• 集成 Hystrix 的斷路器功能；
• 集成 SpringCloud 服務(wù)發(fā)現(xiàn)功能；
• 請求限流功能；
• 支持路徑重寫。

Spring Cloud Gateway 的目標(biāo)，不僅提供統(tǒng)一的路由方式，并且基于 Filter 鏈的方式提供了網(wǎng)關(guān)基本的功能，例如：安全，監(jiān)控/指標(biāo)，和限流。

提前聲明：Spring Cloud Gateway 底層使用了高性能的通信框架 Netty。

5.三大核心概念

• Route（路由）：路由是構(gòu)建網(wǎng)關(guān)的基本模塊，它有 ID，目標(biāo) URI，一系列的斷言和過濾器組成，如果請求與斷言相匹配則進(jìn)行路由
• Predicate（斷言）：參考的是 java8 的 java.util.function.Predicate，開發(fā)人員可以匹配 HTTP 請求中的所有內(nèi)容（例如請求頭或請求參數(shù)），如果請求與斷言相匹配則進(jìn)行路由
• Filter（過濾）：指的是 Spring 框架中 GatewayFilter 的實(shí)例，使用過濾器，可以在請求被路由前或者之后對請求進(jìn)行修改。

predicate 就是我們發(fā)的匹配條件；而 filter，就可以理解為一個無所不能的攔截器，有了這兩個元素，再加上目標(biāo) uri，就可以實(shí)現(xiàn)一個具體的路由了。

6.路由 Route

Route 主要由 路由 id、目標(biāo) uri、斷言集合和過濾器集合組成，那我們簡單看看這些屬性到底有什么作用。

id：路由標(biāo)識，要求唯一，名稱任意（默認(rèn)值 uuid，一般不用，需要自定義）

uri：請求最終被轉(zhuǎn)發(fā)到的目標(biāo)地址

order： 路由優(yōu)先級，數(shù)字越小，優(yōu)先級越高

predicates：斷言數(shù)組，即判斷條件，如果返回值是 boolean，則轉(zhuǎn)發(fā)請求到 uri 屬性指定的服務(wù)中

filters：過濾器數(shù)組，在請求傳遞過程中，對請求做一些修改

7.gateway 與 zuul 的區(qū)別

在 SpringCloud Finchley 正式版之前，Spring Cloud 推薦的網(wǎng)關(guān)是 Netflix 提供的 Zuul:

Zuul 1.x，是一個基于阻塞 I/O 的 API Gateway

Zuul1.x 基于 Servet2.5 使用阻塞架構(gòu)它不支持任何長連接(如 WebSocket) Zuul 的設(shè)計模式和 Nginx 較像，每次 I/0 操作都是從工作線程中選擇一個執(zhí)行，請求線程被阻塞到工作線程完成，但是差別是 Nginx 用 C++ 實(shí)現(xiàn)，Zuul 用 Java 實(shí)現(xiàn)，而 JVM 本身會有第一次加載較慢的情況，使得 Zuul 的性能相對較差。

Zuul 2.x 理念更先進(jìn)，想基于 Netty 非陽塞和支持長連接，但 SpringCloud 目前還沒有整合。Zuul 2.x 的性能較 Zuul 1.x 有較大提升在性能方面，根據(jù)官方提供的基準(zhǔn)測試，Spring Cloud Gateway 的 QPS (每秒請求數(shù))是 Zuul1.x 的 1.6 倍。

Spring Cloud Gateway 建立在 Spring Framework 5 和 Project Reactor 和 Spring Boot 2 之上，使用非阻塞 APl

Spring Cloud Gateway 還支持 WebSocket，并且與 Spring 緊密集成擁有更好的開發(fā)體驗(yàn)

8.zuul 模型的缺點(diǎn)

Springcloud 中所集成的 Zuul 版本，采用的是 Tomcat 容器，使用的是傳統(tǒng)的 Servlet IO 處理模型
Servlet 的生命周期?

• servlet 由 servlet container 進(jìn)行生命周期管理.container 啟動時構(gòu)造 servlet 對象并調(diào)用 servlet init()進(jìn)行初始化
• container 運(yùn)行時接受請求，并為每個請求分配一個線程(一般從線程池中獲取空閑線程)然后調(diào)用 service()
• container 關(guān)閉時調(diào)用 servlet destory()銷毀 servlet;

上述模式的缺點(diǎn):
servlet 是一人簡單的網(wǎng)絡(luò) IO 模型，當(dāng)請求進(jìn)入 servlet container 時，servet container 就會為其綁定一個線程，在并發(fā)不高的場是下這種模型易適用的。但是一旦高并發(fā)(化如抽風(fēng)用 jemeter 壓)，線程數(shù)量就會上漲，而線程資源代價是昂貴的(上線文切換，內(nèi)存消耗大)嚴(yán)重影響請求的處理時間。在一些簡單業(yè)務(wù)場展下，不希望為每個 reguest 分配一個線程，只需要 1 個或幾個線程就能應(yīng)對極大并發(fā)的請求，這種業(yè)務(wù)場下 servlet 模型沒有優(yōu)勢
所以 Zuul 1.X 是基于 servlet 之上的一個阻塞式處理模型，即 spring 實(shí)現(xiàn)了處理所有 request 請求的一個 servlet (DispatcherServlet)并由該 servlet 阻塞式處理。所以 Springcloud Zuul 無法擺脫 servlet 模型的弊端

9.有哪些謂詞?

• Path:指定路由,支持*號
• After：在指定時間之后
• Before：在指定時間之前
• Between：在指定時間之間,可以用于搶購時間的區(qū)間設(shè)定
• Cookie：帶 cookie 請求,可以支持正則表達(dá)式
• Header：帶指定 header,可以支持正則表達(dá)式
• Host：帶指定 host 請求,可以支持通配符
• Method：指定 method 的請求類型,比如嚴(yán)禁 delete 類型
• Query：帶指定查詢參數(shù),可以支持正則表達(dá)式
• RemoteAddr:來源地址的 list,匹配則通行
• Weight:權(quán)重路由

10.過濾器 filter

Gateway 過濾器的生命周期：

• PRE：這種過濾器在請求被路由之前調(diào)用。我們可利用這種過濾器實(shí)現(xiàn)身份驗(yàn)證、在集群中選擇請求的微服務(wù)、記錄調(diào)試信息等。

• POST：這種過濾器在路由到微服務(wù)以后執(zhí)行。這種過濾器可用來為響應(yīng)添加標(biāo)準(zhǔn)的 HTTP Header、收集統(tǒng)計信息和指標(biāo)、將響應(yīng)從微服務(wù)發(fā)送給客戶端等。

Gateway 過濾器從作用范圍可分為兩種:

• GatewayFilter：應(yīng)用到單個路由或者一個分組的路由上（需要在配置文件中配置）
• GlobalFilter：應(yīng)用到所有的路由上（無需配置，全局生效）

11.GatewayFilter

Spring Cloud Gateway 中內(nèi)置了許多的局部過濾器，如下圖：

局部過濾器需要在指定路由配置才能生效，默認(rèn)是不生效的。

filters:- AddResponseHeader=X-Response-Foo, Bar# StripPrefix：去除原始請求路徑中的前1級路徑，即/gateway- StripPrefix=1

12.GlobalFilter

全局過濾器應(yīng)用全部路由上，無需開發(fā)者配置，Spring Cloud Gateway 也內(nèi)置了一些全局過濾器，如下圖：

GlobalFilter 的功能其實(shí)和 GatewayFilter 是相同的，只是 GlobalFilter 的作用域是所有的路由配置，而不是綁定在指定的路由配置上。多個 GlobalFilter 可以通過 @Order 或者 getOrder() 方法指定執(zhí)行順序，order 值越小，執(zhí)行的優(yōu)先級越高。

13.order 順序

注意，由于過濾器有 pre 和 post 兩種類型，pre 類型過濾器如果 order 值越小，那么它就應(yīng)該在 pre 過濾器鏈的頂層，post 類型過濾器如果 order 值越小，那么它就應(yīng)該在 post 過濾器鏈的底層。示意圖如下：

14.高級使用

• 熔斷降級:

  • 直接使用 sentinel,在 sentinel 進(jìn)行對網(wǎng)關(guān)的熔斷降級
  • 通過 filer 配置,使用 hystrix 進(jìn)行熔斷降級

• 分布式限流:

  • 令牌桶原理,redis 和 lua 腳本結(jié)合使用

filters:- StripPrefix=1- name: Hystrixargs:name: fallbackCmdAfallbackUri: forward:/fallbackAhystrix.command.fallbackCmdA.execution.isolation.thread.timeoutInMilliseconds: 5000

這里的配置，使用了兩個過濾器：

（1）過濾器 StripPrefix，作用是去掉請求路徑的最前面 n 個部分截取掉。

StripPrefix=1 就代表截取路徑的個數(shù)為 1，比如前端過來請求/test/good/1/view，匹配成功后，路由到后端的請求路徑就會變成 http://localhost:8888/good/1/view。

（2）過濾器 Hystrix，作用是通過 Hystrix 進(jìn)行熔斷降級

當(dāng)上游的請求，進(jìn)入了 Hystrix 熔斷降級機(jī)制時，就會調(diào)用 fallbackUri 配置的降級地址。需要注意的是，還需要單獨(dú)設(shè)置 Hystrix 的 commandKey 的超時時間

@RestController public class FallbackController {@GetMapping("/fallbackA")public Response fallbackA() {Response response = new Response();response.setCode("100");response.setMessage("服務(wù)暫時不可用");return response;} }

lua 腳本分布式限流

15.自定義斷言工廠

新建一個類，繼承 AbstractRoutePredicateFactory 類，這個類的泛型是 自定義斷言工廠的一個內(nèi)部類叫做 Config 是一個固定的名字，在 Config 類中定義自定義斷言需要的一些屬性，并且自定義斷言工廠使用 @Component 注解，交給 spring 容器創(chuàng)建.

我們來設(shè)定一個場景: 假設(shè)我們的應(yīng)用僅僅讓 age 在(min,max)之間的人來訪問

@Component public class AgeRoutePredicateFactory extends AbstractRoutePredicateFactory<AgeRoutePredicateFactory.Config> {public AgeRoutePredicateFactory() {super(AgeRoutePredicateFactory.Config.class);}//讀取配置文件中的內(nèi)容并配置給配置類中的屬性@Overridepublic List<String> shortcutFieldOrder() {return Arrays.asList("minAge","maxAge");}@Overridepublic Predicate<ServerWebExchange> apply(Config config) {return exchange -> {// 獲取請求參數(shù)中的 age 屬性String age = exchange.getRequest().getQueryParams().getFirst("age");if(StringUtils.isNotEmpty(age)) {try {int a = Integer.parseInt(age);boolean res = a >= config.minAge && a <= config.maxAge;return res;} catch (Exception e) {System.out.println("輸入的參數(shù)不是數(shù)字格式");}}return false;};}@Validatedpublic static class Config {private Integer minAge;private Integer maxAge;public Integer getMinAge() {return minAge;}public void setMinAge(Integer minAge) {this.minAge = minAge;}public Integer getMaxage() {return maxAge;}public void setMaxage(Integer maxage) {this.maxAge = maxage;}} }

16.源碼分析

• HandlerMapping：SG 構(gòu)建的 HandlerMapping 實(shí)例是 RoutePredicatehandlerMapping
• WebHandler：構(gòu)建的 WebHandler 為 FilteringWebHandler，它接收 GlobalFilter 的集合作為參數(shù)
• Route：路由構(gòu)建由 RouteDefinitionRouteLocator 實(shí)例來處理，它基于路由配置（即上面的配置文件）來構(gòu)建 Route 實(shí)例

RoutePredicateHandlerMapping 是 HandlerMapping 的一個實(shí)例，HandlerMapping 歸屬于 SpringWebFlux.

斷言功能基于 Spring WebFlux 的 HandlerMapping 實(shí)現(xiàn)的,是通過斷言工廠實(shí)現(xiàn)的,如：AfterRoutePredicateFactory、PathRoutePredicateFactory 及 HostRoutePredicateFactory 等，這些工廠均繼承至抽象類 AbstractRoutePredicateFactory，而這個抽象類則實(shí)現(xiàn)了 RoutePredicateFactory 接口，這是一種抽象化思想，盡量做到解耦合和更好拓展性，而具體的斷言判別邏輯則是在各自工廠的 apply 方法中,通過 GatewayPredicate 路由斷言接口的 test 方法判別實(shí)現(xiàn)。

處理流程

我們知道，Gateway 的工作流程是這樣的：客戶端請求->A:Gateway Handler Mapping 接收請求參數(shù)并做相關(guān)斷言處理->B:Web Handler Mapping->GlobalFilter->各種自定義 Filter 邏輯->目標(biāo)服務(wù)接口調(diào)度，其中 A->B 的流轉(zhuǎn)是通過代理 GatewayFilter 來實(shí)現(xiàn)的，進(jìn)而流轉(zhuǎn)到各種 FilterChain 鏈。

Spring WebFlux 的 HandlerMapping 負(fù)責(zé)獲取當(dāng)前請求的各種參數(shù)，并下發(fā)到各種子處理 HandlerMapping 中，這里與斷言直接相關(guān)的是 RoutePredicateHandlerMapping，該類繼承至抽象類 AbstractHandlerMapping，而這個抽象類又實(shí)現(xiàn)了 HandlerMapping 接口。

當(dāng)前請求到來會調(diào)取 RoutePredicateHandlerMapping 類的 getHandlerInternal 方法，進(jìn)而通過 RouteDefinitionRouteLocator（該類實(shí)現(xiàn)了接口 RouteLocator）實(shí)現(xiàn)類中的 getRoutes 獲取已配置的 predicates，同時在該方法中轉(zhuǎn)換封裝好需要的 Route 實(shí)體返回，而具體的斷言攔截功能通過 Route 中的 AsyncPredicate 的 apply 方法中再調(diào)取 Predicate 的 test 方法實(shí)現(xiàn)斷言功能的，這就是從源碼層面分析得到的斷言工作流程。

四.Skywalking

1.微服務(wù)架構(gòu)

2.什么是 Skywalking

Skywalking 是一個國產(chǎn)的開源框架，2015 年由吳晟個人開源，2017 年加入 Apache 孵化器，國人開源的產(chǎn)品，主要開發(fā)人員來自于華為，2019 年 4 月 17 日 Apache 董事會批準(zhǔn) SkyWalking 成為頂級項(xiàng)目，支持 Java、.Net、NodeJs 等探針，數(shù)據(jù)存儲支持 Mysql、Elasticsearch 等，跟 Pinpoint 一樣采用字節(jié)碼注入的方式實(shí)現(xiàn)代碼的無侵入，探針采集數(shù)據(jù)粒度粗，但性能表現(xiàn)優(yōu)秀，且對云原生支持，目前增長勢頭強(qiáng)勁，社區(qū)活躍。

Skywalking 是分布式系統(tǒng)的應(yīng)用程序性能監(jiān)視工具，專為微服務(wù)，云原生架構(gòu)和基于容器（Docker，K8S,Mesos）架構(gòu)而設(shè)計，它是一款優(yōu)秀的 APM（Application Performance Management）工具，包括了分布式追蹤，性能指標(biāo)分析和服務(wù)依賴分析等。

3.Skywalking 架構(gòu)

SkyWalking 邏輯上分為四部分: 探針(節(jié)點(diǎn)數(shù)據(jù)采集), 平臺后端(數(shù)據(jù)上報及分析), 存儲(數(shù)據(jù)持久化)和用戶界面(數(shù)據(jù)可視化)。

• Skywalking agent 和業(yè)務(wù)端綁定在一起，負(fù)責(zé)收集各種監(jiān)控數(shù)據(jù)
• Skywalking oapservice 是負(fù)責(zé)處理監(jiān)控數(shù)據(jù)，接受 agent 的數(shù)據(jù)并存儲在數(shù)據(jù)庫中，接受來自 UI 的請求，查詢監(jiān)控數(shù)據(jù)。
• Skywalking UI 提供給用戶，展現(xiàn)各種監(jiān)控數(shù)據(jù)和告警。
• 數(shù)據(jù)持久化

4.采集過程

完整的采集過程:

• 一個 Trace 對應(yīng)一次完整的調(diào)用鏈路。
• 一個線程內(nèi)的調(diào)用對應(yīng)一個 TraceSegement。
• 同一個線程內(nèi)方法每調(diào)用一次就生成一個 Span，同時 spanId + 1。
• 跨進(jìn)程（如服務(wù)之間的調(diào)用）或跨線程（如異步調(diào)用）生成新的 TraceSegement 和 Sapn，并通過指針指向上游鏈路信息。

Skywalking 的鏈路追蹤數(shù)據(jù)的采集過程其實(shí)是一個生產(chǎn)者-消費(fèi)者模型。

生產(chǎn)消費(fèi)全景圖

5.功能特性

功能:

• 服務(wù)、服務(wù)實(shí)例、端點(diǎn)(URI)指標(biāo)分析
• 根本原因分析。在運(yùn)行時上分析由進(jìn)程內(nèi)代理和 ebpf 分析器支持的代碼。
• 業(yè)務(wù)拓?fù)鋱D分析
• 服務(wù)實(shí)例和端點(diǎn)(URI)依賴關(guān)系分析
• 服務(wù)和端點(diǎn)檢測速度慢
• 性能優(yōu)化
• 分布式跟蹤和上下文傳播
• 數(shù)據(jù)庫訪問指標(biāo)。檢測慢速數(shù)據(jù)庫訪問語句(包括 SQL 語句)
• 消息隊列性能和消耗延遲監(jiān)視
• 瀏覽器性能監(jiān)控
• 基礎(chǔ)設(shè)施(虛擬機(jī)、網(wǎng)絡(luò)、磁盤等)監(jiān)控
• 跨指標(biāo)、跟蹤和日志的協(xié)作
• 告警

特點(diǎn):

• 多語言支持，符合技術(shù)棧的 Agent 包括 net Core、PHP、NodeJS、Golang、LUA、Rust 和 c++代理，積極開發(fā)和維護(hù)。用于 C、c++、Golang 和 Rust 的 eBPF 分析器作為附加。
• 為多種開源項(xiàng)目提供了插件，為 Tomcat、 HttpClient、Spring、RabbitMQ、MySQL 等常見基礎(chǔ)設(shè)施和組件提供了自動探針。
• 微內(nèi)核 + 插件的架構(gòu),模塊化,可插拔，存儲、集群管理、使用插件集合都可以進(jìn)行自由選擇。
• 優(yōu)秀的可視化效果。
• 支持告警。
• 輕量高效，無需大數(shù)據(jù)平臺和大量的服務(wù)器資源。
• 多種監(jiān)控手段，可以通過語言探針和 service mesh 獲得監(jiān)控的數(shù)據(jù)。

6.工作原理?

Skywalking 使用“Agent”對服務(wù)進(jìn)行監(jiān)控，它可以把系統(tǒng)劃分為多個請求，然后把它們彼此關(guān)聯(lián)起來，并將相關(guān)信息發(fā)送到 Skywalking Collector，Collector 會把它們匯總起來，生成有用的報告和可視化圖表，供用戶使用。Skywalking 的還有一個 UI 界面也可以直接查看相關(guān)數(shù)據(jù)

它的工作原理很簡單，首先將受監(jiān)控服務(wù)組件連接到 SkywalkingCollector，然后收集操作日志，性能數(shù)據(jù)，應(yīng)用的狀態(tài)等信息，并將數(shù)據(jù)上送到 Skywalking Collector。Skywalking Collector 會把這些數(shù)據(jù)存儲到 Elasticsearch 中，Elasticsearch 是存儲搜索引擎，它會把收集的數(shù)據(jù)分析出來，然后把分析出來的數(shù)據(jù)發(fā)送到 SkywalkingUI 界面，這樣用戶就可以直接在 Skywalking UI 界面查看這些數(shù)據(jù)了 skywalking 還允許用戶通過 Restful API 進(jìn)行數(shù)據(jù)查詢，以便用戶可以自定義數(shù)據(jù)并獲取最新數(shù)據(jù)。

要使用 SkyWalking，需要給我們的項(xiàng)目中綁定一個 agent 探針，綁定后，SkyWalking 就會將你項(xiàng)目整體的監(jiān)控數(shù)據(jù)反饋給 SkyWalking oapservice，SkyWalking oapservice 就是 SkyWalking 的服務(wù)端，oapservice 會將這些監(jiān)控數(shù)據(jù)做處理，然后存儲到數(shù)據(jù)庫中：SkyWalking 支持的數(shù)據(jù)庫有很多種：ES，MysqL 等等很多都支持；然后 SkyWalking 提供了一個前端的可視化 ui 界面，我們程序員可以通過這個 ui 界面方便的查看到我們項(xiàng)目整體的數(shù)據(jù)，因?yàn)檫@個前端界面會向 oapservice 發(fā)送請求查詢數(shù)據(jù)；

7.持久化方式?

在 application.yml 中配置持久化方式.默認(rèn)的存儲方式就是采用的 h2 數(shù)據(jù)庫，這是一種基于內(nèi)存的數(shù)據(jù)庫，我們不用它，因?yàn)樗趦?nèi)存，只要一重啟 skywalking，這些監(jiān)控數(shù)據(jù)就會消失；

• H2 內(nèi)存數(shù)據(jù)庫
• MySQL 持久化存儲
• ShardingSphere 持久化存儲
• TiDB 持久化存儲
• elasticsearch 持久化存儲,最優(yōu)方案,是企業(yè)的首選方案

8.oapservice 的端口

oapservice 自動暴露了兩個端口，11800 端口和 12800 端口；

• 11800 端口是 oapservice 用來收集微服務(wù)監(jiān)控數(shù)據(jù)的 gRPC 端口，
• 12800 是 oapservice 用來接收前端 ui 界面請求的 HTTP 端口；
• 8080 是 UI 所占用的端口

我們也可以通過 config 文件夾下的 application.yaml 來修改這些端口號；

注意：在我們自己的微服務(wù)中，要將 oapservice 的端口號告訴給我們的微服務(wù)，否則我們自己的微服務(wù)是不知道 oapservice 的端口的，就沒有傳遞監(jiān)控數(shù)據(jù)給 oapservice 了

9.全鏈路監(jiān)控目標(biāo)要求？

探針的性能消: APM 組件服務(wù)的影響應(yīng)該做到足夠小。服務(wù)調(diào)用埋點(diǎn)本身會帶來性能損耗，這就需要調(diào)用跟蹤的低損耗，實(shí)際中還會通過配置采樣率的方式，選擇一部分請求去分析請求路徑。在一些高度優(yōu)化過的服務(wù)，即使一點(diǎn)點(diǎn)損耗也會很容易察覺到，而且有可能迫使在線服務(wù)的部署團(tuán)隊不得不將跟蹤系統(tǒng)關(guān)停。

代碼的侵入性: 即也作為業(yè)務(wù)組件，應(yīng)當(dāng)盡可能少入侵或者無入侵其他業(yè)務(wù)系統(tǒng)，對于使用方透明，減少開發(fā)人員的負(fù)擔(dān)。對于應(yīng)用的程序員來說，是不需要知道有跟蹤系統(tǒng)這回事的。如果一個跟蹤系統(tǒng)想生效，就必須需要依賴應(yīng)用的開發(fā)者主動配合，那么這個跟蹤系統(tǒng)也太脆弱了，往往由于跟蹤系統(tǒng)在應(yīng)用中植入代碼的 bug 或疏忽導(dǎo)致應(yīng)用出問題，這樣才是無法滿足對跟蹤系統(tǒng)“無所不在的部署”這個需求。

可擴(kuò)展性:一個優(yōu)秀的調(diào)用跟蹤系統(tǒng)必須支持分布式部署，具備良好的可擴(kuò)展性。能夠支持的組件越多當(dāng)然越好。或者提供便捷的插件開發(fā) API，對于一些沒有監(jiān)控到的組件，應(yīng)用開發(fā)者也可以自行擴(kuò)展。

數(shù)據(jù)的分析:數(shù)據(jù)的分析要快 ，分析的維度盡可能多。跟蹤系統(tǒng)能提供足夠快的信息反饋，就可以對生產(chǎn)環(huán)境下的異常狀況做出快速反應(yīng)。分析的全面，能夠避免二次開發(fā)。

10.APM 對比

目前市面上開源的 APM 系統(tǒng)主要有 CAT、Zipkin、Pinpoint、SkyWalking，大都是參考 Google 的 Dapper]實(shí)現(xiàn)的

• Zipkin 是 Twitter 開源的調(diào)用鏈路分析工具，目前基于 Spingcloud sleuth 得到了廣泛的應(yīng)用，特點(diǎn)是輕量，部署簡單。
• Pinpoint 是一個韓國團(tuán)隊開源的產(chǎn)品，運(yùn)用了字節(jié)碼增強(qiáng)技術(shù)，只需要在啟動時添加啟動參數(shù)即可，對代碼無侵入，目前支持 Java 和 PHP 語言，底層采用 HBase 來存儲數(shù)據(jù)，探針收集的數(shù)據(jù)粒度非常細(xì)，但性能損耗大，因其出現(xiàn)的時間較長，完成度也很高，應(yīng)用的公司較多
• Skywalking 是本土開源的基于字節(jié)碼注入的調(diào)用鏈路分析以及應(yīng)用監(jiān)控分析工具，特點(diǎn)是支持多種插件，UI 功能較強(qiáng)，接入端無代碼侵入。
• CAT 是由國內(nèi)美團(tuán)點(diǎn)評開源的，基于 Java 語言開發(fā)，目前提供 Java、C/C++、Node.js、Python、Go 等語言的客戶端，監(jiān)控數(shù)據(jù)會全量統(tǒng)計，國內(nèi)很多公司在用，例如美團(tuán)點(diǎn)評、攜程、拼多多等，CAT 跟下邊要介紹的 Zipkin 都需要在應(yīng)用程序中埋點(diǎn)，對代碼侵入性強(qiáng)。

PinpointZipkinJaegerSkyWalking

OpenTracing 兼容	否	是	是	是
客戶端支持語言	java,php	java,c#,go,php 等	java,c#,go,php 等	java, .net core,nodejs,php
存儲	hbase	es,mysql,Cassandra,內(nèi)存	es,mysql,Cassandra,內(nèi)存	es,h2,msyql,tidb,sharding sphere
傳輸協(xié)議支持	thrift	http,MQ	udp,http	gRPC,http
UI 豐富程度	高	低	中	中
實(shí)現(xiàn)方式	字節(jié)碼注入，無侵入	攔截請求，侵入	攔截請求，侵入	字節(jié)碼注入，無侵入
擴(kuò)展性	低	高	高	中
Trace 查詢	不支持	支持	支持	支持
告警支持	支持	不支持	不支持	支持
JVM 監(jiān)控	支持	不支持	不支持	支持
性能損失	高	中	中	低

五.Seata

1.Seata 是什么?

Seata 是一款開源的分布式事務(wù)解決方案，致力于提供高性能和簡單易用的分布式事務(wù)服務(wù)。Seata 將為用戶提供了 AT、TCC、SAGA 和 XA 事務(wù)模式，為用戶打造一站式的分布式解決方案。

2.Seata 的組成

seate 是一個典型的分布式事務(wù)處理過程，由一個 ID 和三組件模型組成
一個 ID：全局唯一的事務(wù) ID

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

3.Seata 架構(gòu)圖

4.調(diào)度生命周期?

TM 向 TC 申請開啟一個全局事務(wù)，全局事務(wù)創(chuàng)建成功并生成一個全局唯一的 XID;

XID 在微服務(wù)調(diào)用鏈路的上下文中傳播

RM 向 TC 注冊分支事務(wù)，將其納入 XID 對應(yīng)全局事務(wù)的管轄;

TM 向 TC 發(fā)起針對 XID 的全局提交或回滾決議;

TC 調(diào)度 XID 下管轄的全部分支事務(wù)完成提交或回滾請求

5.存儲模式

因?yàn)?TC 需要進(jìn)行全局事務(wù)和分支事務(wù)的記錄，所以需要對應(yīng)的存儲，目前，TC 有三種存儲模式( store.mode):

• file 模式:適合單機(jī)模式，全局事務(wù)會話信息在內(nèi)存中讀寫，并持久化本地文件 root.data，性能較高;
• db 模式:適合集群模式，全局事務(wù)會話信息通過 db 共享，相對性能差點(diǎn):
• redis 模式:解決 db 存儲的性能問題我們先采用 file 模式，最終我們部署單機(jī) TC Server 如下圖所示

6.Seata 的四種模式？

• AT 模式
• TCC 模式
• Saga 模式
• XA 模式

7.AT 模式

前提條件:

• 基于支持本地 ACID 事務(wù)的關(guān)系型數(shù)據(jù)庫。
• Java 應(yīng)用，通過 JDBC 訪問數(shù)據(jù)庫。

實(shí)現(xiàn)機(jī)制:

兩階段提交協(xié)議的演變：

• 一階段：業(yè)務(wù)數(shù)據(jù)和回滾日志記錄在同一個本地事務(wù)中提交，釋放本地鎖和連接資源。
• 二階段：
  • 提交異步化，非常快速地完成。
  • 回滾通過一階段的回滾日志進(jìn)行反向補(bǔ)償。

8.AT 模式工作機(jī)制

seata 首先要求在業(yè)務(wù)表所在的數(shù)據(jù)庫中創(chuàng)建一個 undo_log 表，用于記錄回滾 sql。所謂回滾 sql 就是與所執(zhí)行 sql 相反的 sql，比如執(zhí)行了一個 insert 語句，那么對應(yīng)的 undo log 就是一條 delete 語句。

業(yè)務(wù)表執(zhí)行了操作后，seata 會將執(zhí)行的 sql 進(jìn)行解析，生成回滾 sql 并且存儲到 undo_log 表中

本地事務(wù)提交前，會向 seata 的服務(wù)端注冊分支，申請對應(yīng)的業(yè)務(wù)表中對應(yīng)數(shù)據(jù)行的全局鎖，這時其他的事務(wù)就無法對這條數(shù)據(jù)進(jìn)行更新操作。

本地事務(wù)提交，業(yè)務(wù)數(shù)據(jù)的更新和前面生成的 undo log 會一起提交

將本地事務(wù)的執(zhí)行結(jié)果上報給 seata 服務(wù)端。也就是說 seata 服務(wù)端會記錄多個服務(wù)的本地事務(wù)。同時這些本地事務(wù)因?yàn)樵?seata 服務(wù)端的管控之下，所以使用的事務(wù) ID 和分支 ID 都是一樣的。

如果某一個本地事務(wù)發(fā)生報錯，那么 seata 服務(wù)端就會發(fā)起對應(yīng)分支的回滾請求

同時開啟一個本地事務(wù)，然后通過事務(wù) ID 和分支 ID 去 undo_log 表查詢到對應(yīng)的回滾 sql。并且執(zhí)行回滾 sql，再將執(zhí)行結(jié)果上報給 seata 服務(wù)端

如果沒有發(fā)生報錯，seata 服務(wù)端也會在對應(yīng)分支發(fā)起請求，然后會異步批量的刪除 undo_log 表中的記錄

總結(jié)一句話，為什么能實(shí)現(xiàn)分布式事務(wù)，就是因?yàn)?seata 服務(wù)端將這些本地事務(wù)都記錄下來了，同時也在每個庫中記錄了 undo log。當(dāng)有一個報錯時，就找到這同一組的所有的本地事務(wù)，然后統(tǒng)一利用記錄的 undo log 回退數(shù)據(jù)

undo log 表涉及的字段。其中 xid 就是事務(wù) ID,branch_id 就是分支 ID

9.TCC 模式?

一個分布式的全局事務(wù)，整體是 兩階段提交 的模型。全局事務(wù)是由若干分支事務(wù)組成的，分支事務(wù)要滿足 兩階段提交 的模型要求，即需要每個分支事務(wù)都具備自己的：

• 一階段 prepare 行為
• 二階段 commit 或 rollback 行為

根據(jù)兩階段行為模式的不同，我們將分支事務(wù)劃分為 Automatic (Branch) Transaction Mode 和 Manual (Branch) Transaction Mode.

AT 模式 基于 支持本地 ACID 事務(wù) 的 關(guān)系型數(shù)據(jù)庫：

• 一階段 prepare 行為：在本地事務(wù)中，一并提交業(yè)務(wù)數(shù)據(jù)更新和相應(yīng)回滾日志記錄。
• 二階段 commit 行為：馬上成功結(jié)束，自動 異步批量清理回滾日志。
• 二階段 rollback 行為：通過回滾日志，自動 生成補(bǔ)償操作，完成數(shù)據(jù)回滾。

相應(yīng)的，TCC 模式，不依賴于底層數(shù)據(jù)資源的事務(wù)支持：

• 一階段 prepare 行為：調(diào)用 自定義 的 prepare 邏輯。
• 二階段 commit 行為：調(diào)用 自定義 的 commit 邏輯。
• 二階段 rollback 行為：調(diào)用 自定義 的 rollback 邏輯。

所謂 TCC 模式，是指支持把 自定義 的分支事務(wù)納入到全局事務(wù)的管理中。

//在接口上加@LocalTCC//在實(shí)現(xiàn)類上加@TwoPhaseBusinessAction注解 @TwoPhaseBusinessAction(name ="reducestock", commitMethod ="commitTcc"，rollbackMethod ="cancelTcc") Product reduceStock(BusinessActionContextparameter(paramame = "productid") Integer productid,@BusinessActionContextParameter(paramName = "amount") Integer amount);

10.Saga 模式

Saga模式:是 SEATA 提供的長事務(wù)解決方案，在 Saga 模式中，業(yè)務(wù)流程中每個參與者都提交本地事務(wù)，當(dāng)出現(xiàn)某一個參與者失敗則補(bǔ)償前面已經(jīng)成功的參與者，一階段正向服務(wù)和二階段補(bǔ)償服務(wù)都由業(yè)務(wù)開發(fā)實(shí)現(xiàn)。

Saga模式適用場景：

• 業(yè)務(wù)流程長、業(yè)務(wù)流程多
• 參與者包含其它公司或遺留系統(tǒng)服務(wù)，無法提供 TCC 模式要求的三個接口

優(yōu)勢:

• 一階段提交本地事務(wù)，無鎖，高性能
• 事件驅(qū)動架構(gòu)，參與者可異步執(zhí)行，高吞吐
• 補(bǔ)償服務(wù)易于實(shí)現(xiàn)

缺點(diǎn):

• 不保證隔離性

11.XA 模式

XA 模式 RM 驅(qū)動分支事務(wù)的行為包含以下兩個階段：

• 執(zhí)行階段：

• 向 TC 注冊分支
• XA Start，執(zhí)行業(yè)務(wù) SQL，XA End
• XA prepare，并向 TC 上報 XA 分支的執(zhí)行情況：成功或失敗

• 完成階段：

  • 收到 TC 的分支提交請求，XA Commit
  • 收到 TC 的分支回滾請求，XA Rollback

12.Seata 寫隔離?

• 一階段本地事務(wù)提交前，需要確保先拿到 全局鎖 。
• 拿不到 全局鎖 ，不能提交本地事務(wù)。
• 拿 全局鎖 的嘗試被限制在一定范圍內(nèi)，超出范圍將放棄，并回滾本地事務(wù)，釋放本地鎖。

以一個示例來說明：

兩個全局事務(wù) tx1 和 tx2，分別對 a 表的 m 字段進(jìn)行更新操作，m 的初始值 1000。

tx1 先開始，開啟本地事務(wù)，拿到本地鎖，更新操作 m = 1000 - 100 = 900。本地事務(wù)提交前，先拿到該記錄的 全局鎖 ，本地提交釋放本地鎖。 tx2 后開始，開啟本地事務(wù)，拿到本地鎖，更新操作 m = 900 - 100 = 800。本地事務(wù)提交前，嘗試拿該記錄的 全局鎖 ，tx1 全局提交前，該記錄的全局鎖被 tx1 持有，tx2 需要重試等待 全局鎖 。

tx1 二階段全局提交，釋放 全局鎖 。tx2 拿到 全局鎖 提交本地事務(wù)。

如果 tx1 的二階段全局回滾，則 tx1 需要重新獲取該數(shù)據(jù)的本地鎖，進(jìn)行反向補(bǔ)償?shù)母虏僮?#xff0c;實(shí)現(xiàn)分支的回滾。

此時，如果 tx2 仍在等待該數(shù)據(jù)的 全局鎖，同時持有本地鎖，則 tx1 的分支回滾會失敗。分支的回滾會一直重試，直到 tx2 的 全局鎖 等鎖超時，放棄 全局鎖 并回滾本地事務(wù)釋放本地鎖，tx1 的分支回滾最終成功。

因?yàn)檎麄€過程 全局鎖 在 tx1 結(jié)束前一直是被 tx1 持有的，所以不會發(fā)生 臟寫 的問題。

13.Seata 讀隔離?

在數(shù)據(jù)庫本地事務(wù)隔離級別 讀已提交（Read Committed） 或以上的基礎(chǔ)上，Seata（AT 模式）的默認(rèn)全局隔離級別是 讀未提交（Read Uncommitted） 。

如果應(yīng)用在特定場景下，必需要求全局的 讀已提交 ，目前 Seata 的方式是通過 SELECT FOR UPDATE 語句的代理。

SELECT FOR UPDATE 語句的執(zhí)行會申請 全局鎖 ，如果 全局鎖 被其他事務(wù)持有，則釋放本地鎖（回滾 SELECT FOR UPDATE 語句的本地執(zhí)行）并重試。這個過程中，查詢是被 block 住的，直到 全局鎖 拿到，即讀取的相關(guān)數(shù)據(jù)是 已提交 的，才返回。

出于總體性能上的考慮，Seata 目前的方案并沒有對所有 SELECT 語句都進(jìn)行代理，僅針對 FOR UPDATE 的 SELECT 語句。

14.保證事務(wù)的隔離性？

因 seata 一階段本地事務(wù)已提交，為防止其他事務(wù)臟讀臟寫需要加強(qiáng)隔離。

• 臟讀 select 語句加 for update，代理方法增加@GlobalLock+@Transactional 或@GlobalTransactional
• 臟寫 必須使用@GlobalTransactional

注:如果你查詢的業(yè)務(wù)的接口沒有@GlobalTransactional 包裹，也就是這個方法上壓根沒有分布式事務(wù)的需求，這時你可以在方法上標(biāo)注@GlobalLock+@Transactional 注解，并且在查詢語句上加 for update。 如果你查詢的接口在事務(wù)鏈路上外層有@GlobalTransactional 注解，那么你查詢的語句只要加 for update 就行。設(shè)計這個注解的原因是在沒有這個注解之前，需要查詢分布式事務(wù)讀已提交的數(shù)據(jù)，但業(yè)務(wù)本身不需要分布式事務(wù)。 若使用@GlobalTransactional 注解就會增加一些沒用的額外的 rpc 開銷比如 begin 返回 xid，提交事務(wù)等。GlobalLock 簡化了 rpc 過程，使其做到更高的性能。

六.Apisix

1.什么是 Apisix?

APISIX 是一個微服務(wù) API 網(wǎng)關(guān)，具有高性能、可擴(kuò)展性等優(yōu)點(diǎn)。它基于 nginx（openresty）、Lua、etcd 實(shí)現(xiàn)功能，借鑒了 Kong 的思路。和傳統(tǒng)的 API 網(wǎng)關(guān)相比，APISIX 具有較高的性能和較低的資源消耗，并且具有豐富的插件，也方便自己進(jìn)行插件擴(kuò)展。

作為一個脫胎于 NGINX 和 OpenResty 的軟件，APISIX 人造繼承了 NGINX 的性能和 OpenResty 的靈活性，因而，APISIX 的性能在一眾 API 網(wǎng)關(guān)中都是首屈一指的。

2.Apisix 的優(yōu)點(diǎn)?

具體來說，像 NGINX + Linux epoll 提供了高性能的網(wǎng)絡(luò) IO 基礎(chǔ)設(shè)施，這些是 C 語言實(shí)現(xiàn)的，是動態(tài)的。而 OpenResty 則集成了 LuaJIT，它基于 NGINX 提供的生命周期鉤子進(jìn)行擴(kuò)大，容許用戶通過 Lua 代碼對 NGINX 進(jìn)行編程。而 LuaJIT 自身，得益于優(yōu)良的 JIT 實(shí)現(xiàn)，它能夠在運(yùn)行時對代碼進(jìn)行 JIT 編譯，當(dāng)熱門路上的內(nèi)容被編譯為機(jī)器碼后，性能將能夠與原生 C 語言相比。

沒有復(fù)用 NGINX 的 location 來解決路由匹配，而是應(yīng)用了基數(shù)樹的形式。能夠提供根本安穩(wěn)的匹配速度。請求路由是通過查詢 ETCD 的路由和消費(fèi)方進(jìn)行插件匹配，過濾得到可使用的插件后運(yùn)行插件進(jìn)行動態(tài)上游反向代理。

在 APISIX 中，上述配置操作過程都是齊全動靜的，location 能夠動靜配置，upstream 和 SSL 證書這些全副都能夠動靜配置。這次要得益于 APISIX 應(yīng)用了 etcd 作為配置核心，通過 etcd watch 機(jī)制實(shí)現(xiàn)了動靜的更新其配置，從而不須要依賴 reload 和重啟。

3.Apisix 架構(gòu)

4.外圍模塊

APISIX 在外圍模塊中提供了很多開箱即用的性能，比方負(fù)載平衡、動靜上游、灰度公布、服務(wù)熔斷、身份認(rèn)證、可觀測性、服務(wù)發(fā)現(xiàn)、限流限速和日志收集等性能。

APISIX 中的很多性能都是通過插件形式進(jìn)行實(shí)現(xiàn)的，目前 APISIX 的插件已靠近 80 個，將來還在繼續(xù)擴(kuò)大減少中。提到插件，不得不說 APISIX 提供的插件運(yùn)行時是一個十分易于開發(fā)的插件框架，用戶能夠輕而易舉地應(yīng)用 Lua 編寫本人的插件，來實(shí)現(xiàn)特定業(yè)務(wù)性能。如果切實(shí)不具備 Lua 的開發(fā)保護(hù)能力也能夠應(yīng)用內(nèi)部 Plugin Runner（APISIX 多語言插件） 或者 WASM 開發(fā)插件。

5.基本概念

Route路由:路由是請求的入口點(diǎn)，它定義了客戶端請求與服務(wù)之間的匹配規(guī)則，路由可以與服務(wù)（service）、上游（Upstream）關(guān)聯(lián)，一個服務(wù)可以對應(yīng)一組路由，一個路由可以對應(yīng)一個上游對象（一組后端服務(wù)節(jié)點(diǎn)），因此，每個匹配到路由的請求將被網(wǎng)關(guān)代理到路由綁定的上游服務(wù)中。

Upstream上游服務(wù):包含了已創(chuàng)建的上游服務(wù)（即后端服務(wù)），可以對上游服務(wù)的多個目標(biāo)節(jié)點(diǎn)進(jìn)行負(fù)載均衡和健康檢查。

Service服務(wù):服務(wù)由路由中公共的插件配置、上游目標(biāo)信息組合而成。服務(wù)與路由、上游關(guān)聯(lián)，一個服務(wù)可對應(yīng)一組上游節(jié)點(diǎn)、可被多條路由綁定。

Consumer消費(fèi)者:消費(fèi)者是路由的消費(fèi)方，形式包括開發(fā)者、最終用戶、API 調(diào)用等。創(chuàng)建消費(fèi)者時，需綁定至少一個認(rèn)證類插件。

6.控制臺

七.OpenSergo

總結(jié)

以上是生活随笔為你收集整理的【檀越剑指大厂—SpringCloudAlibaba】SpringCloudAlibaba高阶的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。