Spring Cloud Alibaba 中間件

🔗 Spring官方介紹 [??Spring官方對Spring Cloud Alibaba的更新不及時]

🔗 Spring Cloud Alibaba官網

📝 代碼記錄

Nacos（服務注冊與發現）

Nacos(Dynamic Naming and Configuration Service, Nacos)，一個易于構建 Al Agent 應用的動態服務發現、配置管理和AI智能體管理平臺。

Nacos = Eureka + Config + Bus = Spring Cloud Consul

Nacos官網

組件名	語言	CAP	服務健康檢查	對外暴露接口	Spring Cloud集成
Eureka	Java	AP	可配支持	HTTP	已集成
Consul	Go	CP	支持	HTTP/DNS	已集成
Zookeeper	Java	CP	支持	客戶端	已集成
Nacos	Java	AP	支持	客戶端	已集成

Nacos 在阿里巴巴內部有超過 10 萬的實例運行，已經過了類似雙十一等各種大型流量的考驗，Nacos默認是AP模式，

但也可以調整切換為CP，一般用默認AP即可。

下載與安裝

• spring-cloud-starter-alibaba-nacos-config: 實現配置的動態更新
• spring-cloud-starter-alibaba-nacos-discovery: 實現服務的注冊與發現

注冊中心

主要配合spring-cloud-starter-alibaba-nacos-discovery

服務發現：yml配置nacos相關配置、主啟動配置EnableDiscoveryClient注解

調用注冊中心中的服務：只需在配置中增加RestTemplate的bean，并增加loadbalancer注解，調用服務的接口時將host寫成服務名稱即可

配置中心

主要配合spring-cloud-starter-alibaba-nacos-discovery

nacos端配置文件DataId的命名規則:

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

Namespace，Group，DataId

目的是解決 多環境、多項目、多配置文件的管理

Nacos 數據模型 Key 由三元組（Namespace，Group，DataId）唯一確定, Namespace默認是空串，公共命名空間（public），分組默認是 DEFAULT_GROUP。

Sentinel（服務熔斷和降級）

面向分布式、多語言異構化服務架構的流量治理組件。

從流量路由、流量控制、流量整形、熔斷降級、系統自適應過載保護、熱點流量防護等多個維度來幫助開發者保障微服務的穩定性

Sentinel官網/Github

Sentinel后臺端口8719，前臺端口8080，前臺用戶名密碼都是sentinel

SentinelResource注解

SentinelResource是一個流量防衛組件注解，用于指定防護資源，對配置的資源進行流量控制、熔斷降級等功能。

SentinelResource注解配置說明

注意fallback與blockHandler的區別

• blockHandler，主要針對sentinel配置后出現的違規情況處理
• fallback，程序異常了，JVM拋出的異常服務降級

流控規則

流控規則說明

Sentinel能夠對流量進行控制，主要是監控應用的QPS流量或者并發線程數等指標，如果達到指定的閾值時，就會被流量進行控制，以避免服務被瞬時的高并發流量擊垮，保證服務的高可靠性。

流控模式

• 直接：默認的流控模式，當接口達到限流條件時，直接開啟限流功能。
• 關聯：當關聯的資源達到閾值，就限流自己；當與A關聯的資源B達到閾值后，就限流A自己。(A惹事B掛了)
• 鏈路： 來自不同鏈路的請求對同一個目標訪問時，實施針對性的不同限流措施，比如C請求來訪問就限流，D請求來訪問就是OK

流控效果

• 快速失敗：直接失敗，拋出異常。Blocked by Sentinel (flow limiting)
• Warm up：限流，冷啟動。當流量增大的時候，希望系統從空閑狀態到繁忙狀態的切換時間長一些。公式：閾值除以冷卻因子coldFactor（默認值為3），經過預熱時長后才會達到閾值。默認coldFactor為3，即請求QPS從threshold/3開始，經預熱時長逐漸升至設定的QPS閾值
• 排隊等待：主要處理間隔性突發流量，當一秒內發起大量請求，后幾秒卻是空閑狀態。排隊等待重排請求，使得服務器勻速處理請求。

熔斷規則

Sentinel 熔斷降級會在調用鏈路中某個資源出現不穩定狀態時（例如調用超時或異常比例升高），對這個資源的調用進行限制，讓請求快速失敗，避免影響到其它的資源而導致級聯錯誤。當資源被降級后，在接下來的降級時間窗口之內，對該資源的調用都自動熔斷（默認行為是拋出 DegradeException）。

熔斷規則說明

• 慢調用比例(SLOW_REQUEST_RATIO) ：在統計時長內，實際請求數目 > 設定的最小請求數 且 實際慢調用比例 > 比例閾值，進入熔斷狀態。
• 異常比例(ERROR_RATION): 異常比例達到閾值，進入熔斷狀態
• 異常數(ERROR_COUNT): 數量達到閾值，進入熔斷狀態

熱點規則

熱點即經常訪問的數據，很多時候我們希望統計或者限制某個熱點數據中訪問頻次最高的TopN數據，并對其訪問進修限流或者其他操作

熱點規則說明

簡單來說就是對指定入參限流，sentinel還可以有參數例外項，即對特定的參數值不限流，其他的參數值都限流

授權規則

對請求分黑白名單

來源訪問控制說明

??注意要實現RequestOriginParser再配合可視化端

Seata（分布式事務）

??面試重災區，Seata分布式三大模式的原理需要仔細了解

背景：一次業務操作需要跨多個數據源或需要跨多個系統進行遠程調用，就會產生分布式事務問題；但是關系型數據庫提供的能力是單機事務，一但遇到分布式事務場景，就需要通過更多其他技術手段來解決問題。

Seata(Simple Extensible Autonomous Transaction Architecture), 是一款開源的分布式事務解決方案，致力于在微服務架構下提供高性能和簡單易用的分布式事務服務。

Seata官網/Github, Alibaba開發，2023.10.29捐贈給Apache

Seata部署

Seata三大模式

• Seata AT
• Seata TCC
• Seata SAGA
• Seata XA

工作流程

Seata對分布式事務的協調和控制就是1+3

• 1個XID：XID是全局事務的唯一標識，他可以在服務的調用鏈路中傳遞，綁定到服務的事務上下文中。
• 3（TC->TM->RM）
  • TC(Transaction Coordinator)事務協調者
    • 維護全局和分支事務的狀態，驅動全局事務提交或回滾。
  • TM(Transaction Manager)事務管理器
    • 定義全局事務的范圍：開始全局事務、提交或回滾全局事務。
  • RM(Resource Manager)資源管理器
    • 管理分支事務處理的資源，與TC交談以注冊分支事務和報告分支事務的狀態，并驅動分支事務提交或回滾。

三個組件相互協作，TC以Seata服務器形式獨立部署，TM和RM則是以Seata Client的形式集成在微服務中運行

流程：

1. TM向TC申請開啟一個全局事務，全局事務創建成功并生成一個全局唯一的XID。
2. XID在微服務調用鏈路的上下文中傳播。
3. RM向TC注冊分支事務，將其納入XID對應全局事務的管轄。
4. TM向TC發起針對XID的全局提交或回滾決議。
5. TC調度XID下管轄的全部分支事務完成提交或回滾請求。