開發者說:Sentinel 流控功能在 SpringMVC/SpringBoot 上的實踐
從使用者的視角來感受一個開源專案的成長,是我們推出「開發者說」專欄的初衷,即在開發者進行開源專案選型時,提供更為立體的專案資訊。專欄所有內容均來自作者原創/投稿,本文是「開發者說」的第6篇,作者 Jason Joo,@友樂活(北京),Sentinel Committer.
1st:《深度剖析開源分散式事務方案 Seata 的事務協調器》
3st:《訊息佇列 Kafka 和 RocketMQ 之我見》
5th:《基於 Nacos 的閘道器灰度路由和服務權重灰度》
整合 Sentinel 前生
流控在分散式系統中是較為基本的需求,其需要在系統負載、服務質量、流量甄別、安全⻛控等⽅⾯進⾏保障,並根據業務需求,進⾏動態調整或⼈工臨時介入,尤其是在⼀些事件性的時期,以實現快速控制和恢復服務的效果。
流控手段一般掛載在流量閘道器和業務內的邏輯。
流量閘道器常見於 Nginx 這類代理層,通過擴充套件外掛、Lua指令碼進⾏針對 IP/Path/Query 等形式的流控。業務內則⼤多在區域性或框架層進行訊號量、執行緒池、超時時間或其它邏輯來實現流控。前者主要體現在運維的可操作性,不侵⼊業務線,而後者則針對性更強,但有侵⼊性或修改時需要部署,⾯向業務團隊可控。
兩種型別的流控往往⽐較割裂(由不同的團隊在不共享的空間內進行控制),常出現指標的不協調性。
為了解決這⼀問題,我們開始彙總現有的需求,調研相關的系統,並準備實現⼀套可以同時面向業務和運維,進行應用級隔離和滿足基本規則型別需求的流控實現,預期是在 Nginx 端利用LuaJIT實現一套更為強大的流控模組。
調研過程中,適逢 Sentinel 0.1/0.2的釋出,⽀持servlet整合(URL限流),帶有操作⾯板(Dashboard),支援基本的實時狀況檢視、實時的修改分發規則、全域性負載和單點熔斷,能基於QPS、訊號量等形式進行流控。除了零侵入以外,基本滿⾜我們的需求,所以準備基於 Sentinel 進行方案落地嘗試。
整合 Sentinel 的實踐
我們的基本需求如下:
- 基於 URL 做流控
- 基於 Dashboard 做動態修改規則
- 業務端針對 SpringMVC/SpringBoot
- ⽀持非同步 Servlet (後續提出)
- sentinel-transport 監聽端⼝可定製(涉及防⽕牆配置、同⼀節點多服務)
整合適配
基於 Sentinel 所提供的功能、適配方式,需要進行基本的配置和修改。
整合方式
現有項⽬流量⼊口部分⼤多為基於 SpringMVC 的專案,少部分為 SpringBoot 專案,並且從運維部署的角度看,⽬前主要有普通運⾏方式(JVM/Tomcat)和容器化方式。
- 普通運行方式:盡量避免修改 JVM 啟動引數,引數通過集中配置中心或 properties ⽂件來定義;
- 容器化⽅式:引數⼤多是通過 ENV 環境變量進行定義。
所以我們根據實際的需求,將 Sentinel 初始化⼯作進⾏了封裝,基於 SpringMVC 提供了XML初始化方式,基於 SpringBoot 提供了註解初始化方式,例如:
@InitDefaults(
projectName = "demo",
sentinelPort = 19000,
sentinelGroup = "test"
)
整合框圖
整合要點
- ⾃動判斷是否引⼊了對應的 Sentinel 依賴
- ⾃動配置
- 採用ZooKeeper為規則儲存中心(重⽤現有基建)
- 節點端支援對規則的讀和寫
- 整合sentinel-transport-netty-http來支援Dashboard
- 利用 Dashboard 通過 API 操作單⼀節點的能⼒間接地將規則寫入Zookeeper,從而分發⾄所有節點
主要使⽤了sentinel-web-servlet,採用這個方案,⽆需對Dashboard做任何⼆次開發,可跟隨升級,對業務侵入較少
對 Sentinel 的期待
- 簡化不同場景下的流控整合與落地
- 更簡單非嚴格的叢集限流,引入⾼可⽤
- Dashboard
- 實現 Dubbo/ZooKeeper/Spring/Servlet 相關適配標準的開箱即用
本文作者:
Jason Joo,Sentinel Committer,@友樂活(北京),[email protected],擁有超過⼗年的軟硬體體系技術實踐,傍身技能:Java/C/Golang,資料中介軟體/分散式系統設計/容器編排排程熟悉TCP/IP協議棧與優化(*nix),Linux核心⼆次開發。
本文作者:中介軟體小哥
本文為雲棲社群原創內容,未經