一.Nacos

1.什么是 nacos?

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

服務發現與健康監測

動態配置服務

動態 DNS 服務

服務及其元數據管理

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

2.nacos 架構圖

3.配置中心架構圖

4.開源配置中心

微服務配置文件問題:

• 配置文件相對分散。在一個微服務架構下，配置文件會隨著微服務的增多變的越來越多，而且分散在各個微服務中，不好統一配置和管理。

• 配置文件無法區分環境。微服務項目可能會有多個環境，例如：測試環境、預發布環境、生產環境。每一個環境所使用的配置理論上都是不同的，一旦需要修改，就需要我們去各個微服務下手動維護，這比較困難。

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

配置中心解決思路:

• 首先把項目中各種配置全部都放到一個集中的地方進行統一管理，并提供一套標準的接口。

• 當各個服務需要獲取配置的時候，就來配置中心的接口拉取自己的配置。

• 當配置中心中的各種參數有更新的時候，也能通知到各個服務實時的過來同步最新的信息，使之動態更新。

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

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

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

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

5.Config 配置中心

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

Nacos Client 從 Nacos Server 端獲取數據時，調用的是此接口 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 #服務注冊地址config:server-addr: http://120.79.36.53:8848 #配置中心地址file-extension: yaml #文件類型group: DEV_GROUP #組別namespace: 64d48a25-ed26-4931-ac47-e9b85ab57e48 #命名空間

7.nacos 三要素

• 命名空間: 命名空間之間是隔離的,可以用來區分不同的環境,默認是 public
• 組別: 命名空間相同,也可以用組別來區分環境,默認是 DEFAULT_GROUP
• Data Id: 是微服務名稱和環境的結合體

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

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

當使用 Nacos Config 后，Profile 的配置就存儲到 Data ID 下，即一個 Profile 對應一個 Data ID

Data ID 的拼接格式:

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

• prefix 默認為 spring.application.name 的值，也可以通過配置項 spring.cloud.nacos.config.prefix 來配置
• spring.profiles.active 取 spring.profiles.active 的值，即為當前環境對應的 profile
• file-extension 為配置內容的數據格式，可以通過配置項 spring.cloud.nacos.config.file-extension 來配置

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

Namespace:Namespace 區分環境，清晰明了，而且有利于做權限控制,方便管理配置文件

nacos 命名空間默認是 public,可以自定義新建命名空間,主要用在區分環境,不同的環境下面使用不同的命名空間,不同命名空間的服務不能相互調用.

配置的時候不是配置命名空間名稱,應該配置命名空間的 id

8.配置動態刷新

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

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

共享配置:

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

高可用:在 nacos 服務宕機時,暫時使用本地的文件,從 CAP 架構上來說,實現了 AP,高可用架構.在 nacos 服務宕機了后,客戶端還能繼續訪問服務端,保證業務流程不因 nacos 宕機變成完全不可用.

9.nacos 持久化

1.默認數據庫

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

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.執行腳本

mysql-schema.sql

4.新增配置

10.集群部署

Nacos Server 有兩種運行模式：

• standalone
• cluster

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

在客戶端配置多個節點信息,也可以用 nginx 做多個節點的負載均衡,在客戶端配置 nginx 的訪問節點也是可以的

#使用單機部署 sh bin/startup.sh -m standalone#訪問 默認賬號和密碼為：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 的集群選舉算法是自己實現的Raft 算法，主要是對于naming 服務，動態配置服務是沒有用到這個 raft 集群心跳和數據更新的功能的；

功能點主要有三點：

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

注意：

datum 指的的對于注冊的服務和實例抽象包裝

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

11.Nacos 2.X 的優點

Nacos 1.X 的痛點:Nacos 1.X 心跳多，無效查詢多，心跳續約感知變化慢，連接消耗大，資源空耗嚴重。

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

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

Nacos 2.X 的優點:

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

12.注冊中心對比

Spring Cloud Eureka :

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

Spring Cloud Zookeeper ：

• CP 模型，ZAB 算法，數據強一致性
• 維護成本較高，客戶端，session 狀態，網絡故障等問題，會導致服務異常
• 集群伸縮性限制，內存，GC 和連接
• 無控制臺管理

Spring cloud Consul：

• 適用于 Service Mesh 架構，使用于 JAVA 生態
• AP 模型，Raft+Gossip 算法，數據最終一致性
• 未經大規模市場驗證，無法保證可靠性
• Go 語言編寫，內部異常排查困難

Spring Cloud Nacos ：

• 開箱即用，適用于 dubbo，spring cloud
• AP 模型，數據最終一致性
• 注冊中心，配置中心二合一，提供控制臺管理
• 純國產，久經雙十一考驗

13.注冊中心原理

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

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

LongPollingRunnable:如果 md5 值不一樣，則發送數據變更通知，調用 safeNotifyListener 方法_

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

15.注冊的原理?

注冊的邏輯主要在 NacosNamingService 實現類,registerInstance 是注冊實例.具體實現在 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,里面有對實例的增刪改查@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.防止讀寫沖突?

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

使用 CopyOnWrite 技術,主要是因為在獲取實例列表的場景下,屬于讀多寫少的場景,在讀的時候不加鎖,寫的時候加鎖,消耗一點性能,但是最大限度的提高了讀的效率,也就是常說的空間換時間,這個時間指的是讀取實例的時間.

17.Alibaba 和 Netflix 套件

仔細看看各組件的功能描述，Spring Cloud Alibaba 套件和 Spring Cloud Netflix 套件大致的對應關系：

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

二.Sentinel

1.基本概念

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

2.容錯設計?

• 流控：即流量控制，根據流量、并發線程數、響應時間等指標，把隨機到來的流量調整成合適的形狀，即流量塑性，保證系統在流量突增情況下的可用性，避免系統被瞬時的流量高峰沖垮，一旦達到閾值則進行拒絕服務、排隊等降級操作。

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

• 降級：當訪問量劇增、服務出現異常或者非核心服務影響到核心流程時，暫時犧牲掉一些東西，以保障整個系統的平穩運行。

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

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

• 冪等：當用戶多次請求同一事件時，得到的結果永遠是同一個

3.Sentinel 簡介

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

4.Sentinel 特征

Sentinel.具有以下特征：

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

5.Sentinel 分為兩個部分

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

控制臺功能

功能功能功能

實時監控	族點鏈路	流控規則
熔斷規則	熱點規則	系統規則
授權規則	集群流控	機器列表

6.Sentinel 的基本概念

資源:資源是 Sentinel 的關鍵概念。它可以是 Java 應用程序中的任何內容，例如，由應用程序提供的服務，或由應用程序調用的其它應用提供的服務，甚至可以是一段代碼。在接下來的文檔中，我們都會用資源來描述代碼塊。

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

規則:圍繞資源的實時狀態設定的規則，可以包括流量控制規則、熔斷降級規則以及系統保護規則。所有規則可以動態實時調整。

資源定義 2 種方式

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

7.@SentinelResource

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

@SentinelResource 屬性：

• value：資源名稱，必需項,不能為空
• blockHandler / blockHandlerClass: blockHandler 對應處理 BlockException 的函數名稱，可選項。blockHandler 函數訪問范圍需要是 public，返回類型需要與原方法相匹配，參數類型需要和原方法相匹配并且最后加一個額外的參數，類型為 BlockException。blockHandler 函數默認需要和原方法在同一個類中。若希望使用其他類的函數，則可以指定 blockHandlerClass 為對應的類的 Class 對象，注意對應的函數必需為 static 函數，否則無法解析。
• fallback / fallbackClass：fallback 函數名稱，可選項，用于在拋出異常的時候提供 fallback 處理邏輯。fallback 函數可以針對所有類型的異常（除了 exceptionsToIgnore 里面排除掉的異常類型）進行處理。fallback 函數簽名和位置要求：1、返回值類型必須與原函數返回值類型一致；2、方法參數列表需要和原函數一致，或者可以額外多一個 Throwable 類型的參數用于接收對應的異常。3、fallback 函數默認需要和原方法在同一個類中。若希望使用其他類的函數，則可以指定 fallbackClass 為對應的類的 Class 對象，注意對應的函數必需為 static 函數，否則無法解析。
• defaultFallback（since 1.6.0）：默認的 fallback 函數名稱，可選項，通常用于通用的 fallback 邏輯（即可以用于很多服務或方法）。默認 fallback 函數可以針對所有類型的異常（除了 exceptionsToIgnore 里面排除掉的異常類型）進行處理。若同時配置了 fallback 和 defaultFallback，則只有 fallback 會生效。defaultFallback 函數簽名要求：1、返回值類型必須與原函數返回值類型一致；2、方法參數列表需要為空，或者可以額外多一個 Throwable 類型的參數用于接收對應的異常。3、defaultFallback 函數默認需要和原方法在同一個類中。若希望使用其他類的函數，則可以指定 fallbackClass 為對應的類的 Class 對象，注意對應的函數必需為 static 函數，否則無法解析。
• exceptionsToIgnore（since 1.6.0）：用于指定哪些異常被排除掉，不會計入異常統計中，也不會進入 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 熱點參數");return "------testHotKey"; }public String dealHandler_testHotKey(String p1, String p2, BlockException exception) {// 默認 Blocked by Sentinel (flow limiting)return "-----dealHandler_testHotKey"; }

Sentinel常見異常:

• FlowException 限流異常
• DegradeException 降級熔斷異常
• ParamFlowException 熱點參數異常
• SystemBlockException 系統異常
• AuthorityException 授權,鑒權異常

8.流控規則設計理念?

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

• 資源的調用關系，例如資源的調用鏈路，資源和資源之間的關系；
• 運行指標，例如 QPS、線程池、系統負載等；
• 控制的效果，例如直接限流、冷啟動、排隊等。

Sentinel 的設計理念是讓您自由選擇控制的角度，并進行靈活組合，從而達到想要的效果。

9.流控規則實現?

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

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

10.關聯和鏈路的區別

說明

• 關聯: A 資源關聯 B 資源, 當 B 資源到達閾值時, 限流 A 資源
• 鏈路: A 資源入口資源為 B 資源, 當 A 資源到達閾值時, 限流 B 資源

其實關聯和鏈路是有本質區別的

• 直接: 單個接口的限流
• 關聯: 平級接口的限流
  • 高優先級資源觸發閾值，對低優先級資源限流。
• 鏈路: 上下級接口的限流
  • 資源閾值統計時，只統計從指定資源進入當前資源的請求，是對請求來源的限流

舉個例子

• 關聯
  配置: “查詢訂單” 關聯 “下單” 接口, 當"下單"到達閾值, 限流"查詢訂單"接口
• 鏈路
  配置: “查詢訂單的 service” 入口資源 “查詢訂單”, 當"查詢訂單的 service"到達閾值時, 限流"查詢訂單”

11.Warm Up(預熱)

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

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

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

12.排隊等待

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

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

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

13.熔斷降級設計理念

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

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

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

通過響應時間對資源進行降級:除了對并發線程數進行控制以外，Sentinel 還可以通過響應時間來快速降級不穩定的資源。當依賴的資源出現響應時間過長后，所有對該資源的訪問都會被直接拒絕，直到過了指定的時間窗口之后才重新恢復。

14.熔斷規則?

除了流量控制以外，及時對調用鏈路中的不穩定因素進行熔斷也是 Sentinel 的使命之一。由于調用關系的復雜性，如果調用鏈路中的某個資源出現了不穩定，可能會導致請求發生堆積，進而導致級聯錯誤。

Sentinel 和 Hystrix 的原則是一致的: 當檢測到調用鏈路中某個資源出現不穩定的表現，例如請求響應時間長或異常比例升高的時候，則對這個資源的調用進行限制，讓請求快速失敗，避免影響到其它的資源而導致級聯故障。

DegradeRule 熔斷規則

Field說明默認值

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

15.熔斷策略

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

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

16.慢調用比例

例如:如果 1 秒內持續進入大于等于 5 個請求，并且請求響應的時間大于 200ms 時，這個請求即為慢調用，當慢調用的比例大于 1 時會觸發降級，直到 5 秒后新的請求的響應時間小于 200ms 時，才結束熔斷。

17.異常比例

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

18.異常數

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

19.熱點規則

熱點規則(ParamFlowRule): 熱點即經常訪問的數據。很多時候我們希望統計某個熱點數據中訪問頻次最高的 Top K 數據，并對其訪問進行限制。比如：

• 商品 ID 為參數，統計一段時間內最常購買的商品 ID 并進行限制
• 用戶 ID 為參數，針對一段時間內頻繁訪問的用戶 ID 進行限制

熱點參數限流會統計傳入參數中的熱點參數，并根據配置的限流閾值與模式，對包含熱點參數的資源調用進行限流。熱點參數限流可以看做是一種特殊的流量控制，僅對包含熱點參數的資源調用生效。

20.熱點規則示例

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

說明:當攜帶第一個參數(p1)訪問/testHotKey 的請求量超過 1 秒 5 個時，進行降級，攜帶第二個參數訪問永遠不會觸發降級

21.參數例外項

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

22.授權規則

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

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

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

23.系統規則

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

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

24.sentinel 持久化

主要分為拉模式和推模式

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

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

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

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

[{"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 里面，所有的資源都對應一個資源名稱（resourceName），每次資源調用都會創建一個 Entry 對象。Entry 可以通過對主流框架的適配自動創建，也可以通過注解的方式或調用 SphU API 顯式創建。Entry 創建的時候，同時也會創建一系列功能插槽（slot chain），這些插槽有不同的職責，例如:

• NodeSelectorSlot : 負責收集資源的路徑，并將這些資源的調用路徑，以樹狀結構存儲起來，用于根據調用路徑來限流降級；
• ClusterBuilderSlot : 則用于存儲資源的統計信息以及調用者信息，例如該資源的 RT, QPS, thread count 等等，這些信息將用作為多維度限流，降級的依據；
• StatisticSlot : 則用于記錄、統計不同緯度的 runtime 指標監控信息；滑動窗口是其實現;
• FlowSlot : 則用于根據預設的限流規則以及前面 slot 統計的狀態，來進行流量控制；
• AuthoritySlot : 則根據配置的黑白名單和調用來源信息，來做黑白名單控制；
• DegradeSlot: 則通過統計信息以及預設的規則，來做熔斷降級；
• SystemSlot : 則通過系統的狀態，例如 load1 等，來控制總的入口流量；

每個 Slot 執行完業務邏輯處理后，會調用 fireEntry()方法，該方法將會觸發下一個節點的 entry 方法，下一個節點又會調用他的 fireEntry，以此類推直到最后一個 Slot，由此就形成了 sentinel 的責任鏈。

26.插槽 Slot

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

sentinel 的工作流程就是圍繞著一個個插槽所組成的插槽鏈來展開的。默認的各個插槽之間的順序是固定的，因為有的插槽需要依賴其他的插槽計算出來的結果才能進行工作。

sentinel 通過 SlotChainBuilder 作為 SPI 接口，使得 Slot Chain 具備了擴展的能力。我們可以通過實現 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;} }

總結:sentinel 的限流降級等功能，主要是通過一個 SlotChain 實現的。在鏈式插槽中，有 7 個核心的 Slot，這些 Slot 各司其職，可以分為以下幾種類型：

• 一、進行資源調用路徑構造的 NodeSelectorSlot 和 ClusterBuilderSlot

• 二、進行資源的實時狀態統計的 StatisticsSlot

• 三、進行系統保護，限流，降級等規則校驗的 SystemSlot、AuthoritySlot、FlowSlot、DegradeSlot

后面幾個 Slot 依賴于前面幾個 Slot 統計的結果。

27.chainMap 設計

public class CtSph implements Sph {private static final Object[] OBJECTS0 = new Object[0];//使用的普通的map,在高并發場景下,減少鎖帶來的性能消耗,因為不是全部必須加鎖private static volatile Map<ResourceWrapper, ProcessorSlotChain> chainMap= new HashMap<ResourceWrapper, ProcessorSlotChain>();private static final Object LOCK = new Object(); }

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

執行責任鏈就是執行各種 slot.

ProcessorSlot<Object> lookProcessChain(ResourceWrapper resourceWrapper) {// 根據資源獲取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;}//構建一個slot引用鏈 -----chain = SlotChainProvider.newSlotChain();// map存儲,寫時復制,提高讀取的效率,容量加1Map<ResourceWrapper, ProcessorSlotChain> newMap = new HashMap<ResourceWrapper, ProcessorSlotChain>(chainMap.size() + 1);newMap.putAll(chainMap);newMap.put(resourceWrapper, chain);chainMap = newMap;}}}return chain; }

28.常見 node

節點作用

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

29.滑動窗口實現

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

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

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

MetricBucket 是窗口里面的統計指標的具體實現,MetricBucket 是由 LongAdder 數組組成的，一個 LongAdder 就是一個 MetricEvent,主要作用是創建各個事件,初始化最小 RT

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

LeapArray

//Leap數組使用滑動窗口算法來計數數據 public abstract class LeapArray<T> {protected int windowLengthInMs;protected int sampleCount;protected int intervalInMs;private double intervalInSecond;protected final AtomicReferenceArray<WindowWrap<T>> array;/*** 更新鎖僅在不推薦使用當前存儲桶時使用*/private final ReentrantLock updateLock = new ReentrantLock();/***這個構造方法其實就是計算出來這個窗口長度，創建了窗口數組。*/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 的資源模型設計上采用了命令模式，將對外部資源的調用和 fallback 邏輯封裝成一個命令對象（HystrixCommand / HystrixObservableCommand），其底層的執行是基于 RxJava 實現的。每個 Command 創建時都要指定 commandKey 和 groupKey（用于區分資源）以及對應的隔離策略（線程池隔離 or 信號量隔離）。線程池隔離模式下需要配置線程池對應的參數（線程池名稱、容量、排隊超時等），然后 Command 就會在指定的線程池按照指定的容錯策略執行；信號量隔離模式下需要配置最大并發數，執行 Command 時 Hystrix 就會限制其并發調用。

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

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

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

從 0.2.0 版本開始，Sentinel 引入異步調用鏈路支持，可以方便地統計異步調用資源的數據，維護異步調用鏈路，同時具備了適配異步框架/庫的能力。

Sentinel 提供多樣化的規則配置方式。除了直接通過 loadRules API 將規則注冊到內存態之外，用戶還可以注冊各種外部數據源來提供動態的規則。用戶可以根據系統當前的實時情況去動態地變更規則配置，數據源會將變更推送至 Sentinel 并即時生效。

隔離設計

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

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

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

31.ContextUtil

ContextUtil 很經典,使用了很多并發編程中的知識

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

如果第一步沒有獲取，嘗試從緩存中獲取該上下文名稱對應的 入口節點

判斷緩存中入口節點數量是否大于 2000public final static int MAX_CONTEXT_NAME_SIZE = 2000;如果已經大于 2000，返回一個 NULL_CONTEXT

以上檢查都通過根據上下文名稱生成入口節點（entranceNode），期間會進行雙關檢索確保線程安全

加入至全局根節點下，并加入緩存，注意每個 ContextName 對應一個入口節點 entranceNode

根據 ContextName 和 entranceNode 初始化上下文對象，并將上下文對象設置到當前線程中

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.網關的基本功能?

簡化客戶端的工作。網關將微服務封裝起來后，客戶端只需同網關交互，而不必調用各個不同服務；

降低函數間的耦合度。 一旦服務接口修改，只需修改網關的路由策略，不必修改每個調用該函數的客戶端，從而減少了程序間的耦合性

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

2.主流網關的對比?

網關（API Gateway）的設計要素:

限流：實現微服務訪問流量計算，基于流量計算分析進行限流，可以定義多種限流規則。

緩存：數據緩存。

日志：日志記錄。

監控：記錄請求響應數據，api耗時分析，性能監控。

鑒權：權限身份認證。

灰度：線上灰度部署，可以減小風險。

路由：路由是API網關很核心的模塊功能，此模塊實現根據請求，鎖定目標微服務并將
請求進行轉發。

簡單介紹下你的網關實施方案:

開發語言：java + groovy，groovy的好處是網關服務不需要重啟
就可以動態的添加filter來實 現一些功能；

微服務基礎框架：springboot；

網關基礎組件：netflix zuul；

服務注冊中心：consul；

權限校驗：jwt；

API監控：prometheus + grafana；

API統一日志收集：logback + ELK；

壓力測試：Jmeter；

3.什么是 gateway?

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

gateway 是在 spring 生態系統之上構建的 API 網關服務，基于 Spring 5，Spring Boot2 和 Project Reactor 等技術。gateway 旨在提供一種簡單而有效的方式來對 API 進行路由，以及提供一些強大的過濾器功能，例如：反向代理、熔斷、限流、重試等。

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

4.gateway 特性?

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

Spring Cloud Gateway 的目標，不僅提供統一的路由方式，并且基于 Filter 鏈的方式提供了網關基本的功能，例如：安全，監控/指標，和限流。

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

5.三大核心概念

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

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

6.路由 Route

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

id：路由標識，要求唯一，名稱任意（默認值 uuid，一般不用，需要自定義）

uri：請求最終被轉發到的目標地址

order： 路由優先級，數字越小，優先級越高

predicates：斷言數組，即判斷條件，如果返回值是 boolean，則轉發請求到 uri 屬性指定的服務中

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

7.gateway 與 zuul 的區別

在 SpringCloud Finchley 正式版之前，Spring Cloud 推薦的網關是 Netflix 提供的 Zuul:

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

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

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

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

Spring Cloud Gateway 還支持 WebSocket，并且與 Spring 緊密集成擁有更好的開發體驗

8.zuul 模型的缺點

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

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

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

9.有哪些謂詞?

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

10.過濾器 filter

Gateway 過濾器的生命周期：

• PRE：這種過濾器在請求被路由之前調用。我們可利用這種過濾器實現身份驗證、在集群中選擇請求的微服務、記錄調試信息等。

• POST：這種過濾器在路由到微服務以后執行。這種過濾器可用來為響應添加標準的 HTTP Header、收集統計信息和指標、將響應從微服務發送給客戶端等。

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

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

11.GatewayFilter

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

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

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

12.GlobalFilter

全局過濾器應用全部路由上，無需開發者配置，Spring Cloud Gateway 也內置了一些全局過濾器，如下圖：

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

13.order 順序

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

14.高級使用

• 熔斷降級:

  • 直接使用 sentinel,在 sentinel 進行對網關的熔斷降級
  • 通過 filer 配置,使用 hystrix 進行熔斷降級

• 分布式限流:

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

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

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

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

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

（2）過濾器 Hystrix，作用是通過 Hystrix 進行熔斷降級

當上游的請求，進入了 Hystrix 熔斷降級機制時，就會調用 fallbackUri 配置的降級地址。需要注意的是，還需要單獨設置 Hystrix 的 commandKey 的超時時間

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

lua 腳本分布式限流

15.自定義斷言工廠

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

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

@Component public class AgeRoutePredicateFactory extends AbstractRoutePredicateFactory<AgeRoutePredicateFactory.Config> {public AgeRoutePredicateFactory() {super(AgeRoutePredicateFactory.Config.class);}//讀取配置文件中的內容并配置給配置類中的屬性@Overridepublic List<String> shortcutFieldOrder() {return Arrays.asList("minAge","maxAge");}@Overridepublic Predicate<ServerWebExchange> apply(Config config) {return exchange -> {// 獲取請求參數中的 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("輸入的參數不是數字格式");}}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 構建的 HandlerMapping 實例是 RoutePredicatehandlerMapping
• WebHandler：構建的 WebHandler 為 FilteringWebHandler，它接收 GlobalFilter 的集合作為參數
• Route：路由構建由 RouteDefinitionRouteLocator 實例來處理，它基于路由配置（即上面的配置文件）來構建 Route 實例

RoutePredicateHandlerMapping 是 HandlerMapping 的一個實例，HandlerMapping 歸屬于 SpringWebFlux.

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

處理流程

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

Spring WebFlux 的 HandlerMapping 負責獲取當前請求的各種參數，并下發到各種子處理 HandlerMapping 中，這里與斷言直接相關的是 RoutePredicateHandlerMapping，該類繼承至抽象類 AbstractHandlerMapping，而這個抽象類又實現了 HandlerMapping 接口。

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

四.Skywalking

1.微服務架構

2.什么是 Skywalking

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

Skywalking 是分布式系統的應用程序性能監視工具，專為微服務，云原生架構和基于容器（Docker，K8S,Mesos）架構而設計，它是一款優秀的 APM（Application Performance Management）工具，包括了分布式追蹤，性能指標分析和服務依賴分析等。

3.Skywalking 架構

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

• Skywalking agent 和業務端綁定在一起，負責收集各種監控數據
• Skywalking oapservice 是負責處理監控數據，接受 agent 的數據并存儲在數據庫中，接受來自 UI 的請求，查詢監控數據。
• Skywalking UI 提供給用戶，展現各種監控數據和告警。
• 數據持久化

4.采集過程

完整的采集過程:

• 一個 Trace 對應一次完整的調用鏈路。
• 一個線程內的調用對應一個 TraceSegement。
• 同一個線程內方法每調用一次就生成一個 Span，同時 spanId + 1。
• 跨進程（如服務之間的調用）或跨線程（如異步調用）生成新的 TraceSegement 和 Sapn，并通過指針指向上游鏈路信息。

Skywalking 的鏈路追蹤數據的采集過程其實是一個生產者-消費者模型。

生產消費全景圖

5.功能特性

功能:

• 服務、服務實例、端點(URI)指標分析
• 根本原因分析。在運行時上分析由進程內代理和 ebpf 分析器支持的代碼。
• 業務拓撲圖分析
• 服務實例和端點(URI)依賴關系分析
• 服務和端點檢測速度慢
• 性能優化
• 分布式跟蹤和上下文傳播
• 數據庫訪問指標。檢測慢速數據庫訪問語句(包括 SQL 語句)
• 消息隊列性能和消耗延遲監視
• 瀏覽器性能監控
• 基礎設施(虛擬機、網絡、磁盤等)監控
• 跨指標、跟蹤和日志的協作
• 告警

特點:

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

6.工作原理?

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

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

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

7.持久化方式?

在 application.yml 中配置持久化方式.默認的存儲方式就是采用的 h2 數據庫，這是一種基于內存的數據庫，我們不用它，因為它基于內存，只要一重啟 skywalking，這些監控數據就會消失；

• H2 內存數據庫
• MySQL 持久化存儲
• ShardingSphere 持久化存儲
• TiDB 持久化存儲
• elasticsearch 持久化存儲,最優方案,是企業的首選方案

8.oapservice 的端口

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

• 11800 端口是 oapservice 用來收集微服務監控數據的 gRPC 端口，
• 12800 是 oapservice 用來接收前端 ui 界面請求的 HTTP 端口；
• 8080 是 UI 所占用的端口

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

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

9.全鏈路監控目標要求？

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

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

可擴展性:一個優秀的調用跟蹤系統必須支持分布式部署，具備良好的可擴展性。能夠支持的組件越多當然越好。或者提供便捷的插件開發 API，對于一些沒有監控到的組件，應用開發者也可以自行擴展。

數據的分析:數據的分析要快 ，分析的維度盡可能多。跟蹤系統能提供足夠快的信息反饋，就可以對生產環境下的異常狀況做出快速反應。分析的全面，能夠避免二次開發。

10.APM 對比

目前市面上開源的 APM 系統主要有 CAT、Zipkin、Pinpoint、SkyWalking，大都是參考 Google 的 Dapper]實現的

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

PinpointZipkinJaegerSkyWalking

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

五.Seata

1.Seata 是什么?

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

2.Seata 的組成

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

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

3.Seata 架構圖

4.調度生命周期?

TM 向 TC 申請開啟一個全局事務，全局事務創建成功并生成一個全局唯一的 XID;

XID 在微服務調用鏈路的上下文中傳播

RM 向 TC 注冊分支事務，將其納入 XID 對應全局事務的管轄;

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

TC 調度 XID 下管轄的全部分支事務完成提交或回滾請求

5.存儲模式

因為 TC 需要進行全局事務和分支事務的記錄，所以需要對應的存儲，目前，TC 有三種存儲模式( store.mode):

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

6.Seata 的四種模式？

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

7.AT 模式

前提條件:

• 基于支持本地 ACID 事務的關系型數據庫。
• Java 應用，通過 JDBC 訪問數據庫。

實現機制:

兩階段提交協議的演變：

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

8.AT 模式工作機制

seata 首先要求在業務表所在的數據庫中創建一個 undo_log 表，用于記錄回滾 sql。所謂回滾 sql 就是與所執行 sql 相反的 sql，比如執行了一個 insert 語句，那么對應的 undo log 就是一條 delete 語句。

業務表執行了操作后，seata 會將執行的 sql 進行解析，生成回滾 sql 并且存儲到 undo_log 表中

本地事務提交前，會向 seata 的服務端注冊分支，申請對應的業務表中對應數據行的全局鎖，這時其他的事務就無法對這條數據進行更新操作。

本地事務提交，業務數據的更新和前面生成的 undo log 會一起提交

將本地事務的執行結果上報給 seata 服務端。也就是說 seata 服務端會記錄多個服務的本地事務。同時這些本地事務因為在 seata 服務端的管控之下，所以使用的事務 ID 和分支 ID 都是一樣的。

如果某一個本地事務發生報錯，那么 seata 服務端就會發起對應分支的回滾請求

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

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

總結一句話，為什么能實現分布式事務，就是因為 seata 服務端將這些本地事務都記錄下來了，同時也在每個庫中記錄了 undo log。當有一個報錯時，就找到這同一組的所有的本地事務，然后統一利用記錄的 undo log 回退數據

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

9.TCC 模式?

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

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

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

AT 模式 基于 支持本地 ACID 事務 的 關系型數據庫：

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

相應的，TCC 模式，不依賴于底層數據資源的事務支持：

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

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

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

10.Saga 模式

Saga模式:是 SEATA 提供的長事務解決方案，在 Saga 模式中，業務流程中每個參與者都提交本地事務，當出現某一個參與者失敗則補償前面已經成功的參與者，一階段正向服務和二階段補償服務都由業務開發實現。

Saga模式適用場景：

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

優勢:

• 一階段提交本地事務，無鎖，高性能
• 事件驅動架構，參與者可異步執行，高吞吐
• 補償服務易于實現

缺點:

• 不保證隔離性

11.XA 模式

XA 模式 RM 驅動分支事務的行為包含以下兩個階段：

• 執行階段：

• 向 TC 注冊分支
• XA Start，執行業務 SQL，XA End
• XA prepare，并向 TC 上報 XA 分支的執行情況：成功或失敗

• 完成階段：

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

12.Seata 寫隔離?

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

以一個示例來說明：

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

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

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

如果 tx1 的二階段全局回滾，則 tx1 需要重新獲取該數據的本地鎖，進行反向補償的更新操作，實現分支的回滾。

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

因為整個過程 全局鎖 在 tx1 結束前一直是被 tx1 持有的，所以不會發生 臟寫 的問題。

13.Seata 讀隔離?

在數據庫本地事務隔離級別 讀已提交（Read Committed） 或以上的基礎上，Seata（AT 模式）的默認全局隔離級別是 讀未提交（Read Uncommitted） 。

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

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

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

14.保證事務的隔離性？

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

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

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

六.Apisix

1.什么是 Apisix?

APISIX 是一個微服務 API 網關，具有高性能、可擴展性等優點。它基于 nginx（openresty）、Lua、etcd 實現功能，借鑒了 Kong 的思路。和傳統的 API 網關相比，APISIX 具有較高的性能和較低的資源消耗，并且具有豐富的插件，也方便自己進行插件擴展。

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

2.Apisix 的優點?

具體來說，像 NGINX + Linux epoll 提供了高性能的網絡 IO 基礎設施，這些是 C 語言實現的，是動態的。而 OpenResty 則集成了 LuaJIT，它基于 NGINX 提供的生命周期鉤子進行擴大，容許用戶通過 Lua 代碼對 NGINX 進行編程。而 LuaJIT 自身，得益于優良的 JIT 實現，它能夠在運行時對代碼進行 JIT 編譯，當熱門路上的內容被編譯為機器碼后，性能將能夠與原生 C 語言相比。

沒有復用 NGINX 的 location 來解決路由匹配，而是應用了基數樹的形式。能夠提供根本安穩的匹配速度。請求路由是通過查詢 ETCD 的路由和消費方進行插件匹配，過濾得到可使用的插件后運行插件進行動態上游反向代理。

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

3.Apisix 架構

4.外圍模塊

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

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

5.基本概念

Route路由:路由是請求的入口點，它定義了客戶端請求與服務之間的匹配規則，路由可以與服務（service）、上游（Upstream）關聯，一個服務可以對應一組路由，一個路由可以對應一個上游對象（一組后端服務節點），因此，每個匹配到路由的請求將被網關代理到路由綁定的上游服務中。

Upstream上游服務:包含了已創建的上游服務（即后端服務），可以對上游服務的多個目標節點進行負載均衡和健康檢查。

Service服務:服務由路由中公共的插件配置、上游目標信息組合而成。服務與路由、上游關聯，一個服務可對應一組上游節點、可被多條路由綁定。

Consumer消費者:消費者是路由的消費方，形式包括開發者、最終用戶、API 調用等。創建消費者時，需綁定至少一個認證類插件。

6.控制臺

七.OpenSergo

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。