戰(zhàn)：配置流程、底層原理與高并發(fā)防護(hù)策略)
做服務(wù)治理的人都知道一句話流量防護(hù)不是上線之后就一勞永逸的事。我最早接觸 Sentinel 是在一次壓測現(xiàn)場——某個(gè)核心接口在流量翻倍時(shí)直接讓數(shù)據(jù)庫連接池打滿后續(xù)所有依賴它的服務(wù)開始連環(huán)超時(shí)當(dāng)時(shí)團(tuán)隊(duì)的應(yīng)對(duì)方式還停留在“加機(jī)器”這一個(gè)維度上。后來才開始認(rèn)真搞限流降級(jí)也才慢慢把這些問題帶到 Sentinel 的配置和底層原理上來。聊到“Sentinel 的配置流程及底層原理”大多數(shù)人第一反應(yīng)是去控制臺(tái)加幾條流控規(guī)則。但真正踩過坑之后才會(huì)意識(shí)到配置流程背后是對(duì)資源模型的理解底層原理背后是統(tǒng)計(jì)窗口和狀態(tài)狀態(tài)機(jī)。這篇文章不打算把官方文檔復(fù)述一遍而是從一個(gè)實(shí)踐者的角度把接入步驟、規(guī)則設(shè)置、控制臺(tái)用法和核心機(jī)制串成一條線講清楚“每一步為什么要這么做”也讓準(zhǔn)備接手這塊的讀者少走彎路。你可能已經(jīng)用它做過一些基礎(chǔ)限流也可能只是聽過名字這里盡量讓兩種讀者都能拿到自己需要的東西。1. 先想明白 Sentinel 解決什么問題很多團(tuán)隊(duì)是在系統(tǒng)已經(jīng)被突發(fā)流量打掛之后才想起上 Sentinel但上完之后又不確定它到底應(yīng)該管到哪一層。先把這個(gè)底層問題聊透后面配置才會(huì)自然。Sentinel 的核心價(jià)值說起來很樸素保護(hù)系統(tǒng)不被瞬時(shí)流量沖垮同時(shí)避免某個(gè)下游故障把整條鏈路拖死。它做的事情可以拆成三件一是流量控制給每個(gè)接口設(shè)置一個(gè)可接受的最大訪問量超過的部分直接拒絕二是熔斷降級(jí)當(dāng)下游接口的失敗率或者響應(yīng)時(shí)間超過閾值時(shí)暫時(shí)切掉這條調(diào)用讓下游有時(shí)間恢復(fù)三是系統(tǒng)負(fù)載保護(hù)當(dāng)整體機(jī)器的 CPU、負(fù)載已經(jīng)過高時(shí)就不再讓新的請(qǐng)求進(jìn)入系統(tǒng)。這三件事看起來獨(dú)立最終目的其實(shí)一致把“不可控的外部流量”和“已經(jīng)出現(xiàn)的內(nèi)部故障”隔離在系統(tǒng)承受范圍之內(nèi)。所以你在配置時(shí)不應(yīng)該只是為了填一個(gè)數(shù)字而是要回答一個(gè)問題這個(gè)接口在當(dāng)前的機(jī)器規(guī)格、數(shù)據(jù)庫連接數(shù)、第三方依賴能力下到底能承受多少 QPS如果答不上來那后面所有規(guī)則都是拍腦袋。1.1 核心能力限流、熔斷、系統(tǒng)保護(hù)拿一張對(duì)照表來概括這也是我在做技術(shù)選型評(píng)審時(shí)習(xí)慣用的方式能力解決什么問題典型配置入口流量控制閾值內(nèi)的請(qǐng)求放行超出部分快速失敗、排隊(duì)或預(yù)熱流控規(guī)則熔斷降級(jí)下游異常比例或響應(yīng)時(shí)間超限時(shí)主動(dòng)斷開調(diào)用熔斷規(guī)則系統(tǒng)自適應(yīng)保護(hù)根據(jù)機(jī)器整體負(fù)載限制入口流量防止系統(tǒng)整體過載系統(tǒng)規(guī)則熱點(diǎn)參數(shù)限流針對(duì)某個(gè)熱點(diǎn)參數(shù)值如商品ID、用戶ID單獨(dú)設(shè)定閾值熱點(diǎn)規(guī)則這四類規(guī)則在配置時(shí)互不沖突也可以疊加使用。比如一個(gè)訂單查詢接口既需要設(shè)置總量限流又需要對(duì)某些秒殺商品的參數(shù)做熱點(diǎn)限流還需要在數(shù)據(jù)庫慢查詢導(dǎo)致 RT 上升時(shí)觸發(fā)熔斷。規(guī)則之間是不同維度的保護(hù)沒有誰替代誰的問題。1.2 引入前先做一次技術(shù)判斷有一點(diǎn)我想先潑冷水并不是所有系統(tǒng)都需要 Sentinel。如果你的服務(wù)沒有明顯的波峰波谷、也沒有脆弱的第三方依賴純單機(jī)部署且并發(fā)量極低那用更輕量的信號(hào)量限流或者一個(gè)簡單的攔截器就夠了。引入 Sentinel 本身會(huì)帶來一些運(yùn)行成本和學(xué)習(xí)成本比如控制臺(tái)部署、規(guī)則持久化、客戶端上報(bào)這些對(duì)小團(tuán)隊(duì)來說并不是零負(fù)擔(dān)。我的建議是先判斷是否存在以下場景第一有突發(fā)的營銷流量或者被爬蟲刷接口的可能第二系統(tǒng)中存在一個(gè)明顯脆弱的依賴比如某臺(tái)數(shù)據(jù)庫、某個(gè)外部 API一旦它故障會(huì)拖垮整條鏈路第三你們正在做微服務(wù)拆分服務(wù)的調(diào)用關(guān)系網(wǎng)越來越密。滿足其中任意一條才有必要認(rèn)真考慮 Sentinel并且值得把規(guī)則設(shè)計(jì)和持續(xù)調(diào)優(yōu)當(dāng)成一項(xiàng)長期工作。2. 接入 Sentinel 的完整配置流程前面是認(rèn)知層面的事這一節(jié)開始進(jìn)入實(shí)際操作。接入流程說簡單也簡單總共就四步引入依賴、埋點(diǎn)資源、啟動(dòng)控制臺(tái)、下發(fā)規(guī)則。但每一步里都藏著容易繞彎的細(xì)節(jié)。2.1 依賴引入與資源埋點(diǎn)首先在項(xiàng)目的依賴管理文件里加入 Sentinel 相關(guān)組件。如果你用的是 Java 技術(shù)棧最簡單的做法是先引入核心包再加上控制臺(tái)通信的擴(kuò)展包。具體坐標(biāo)不用死記到 Maven 倉庫搜sentinel-core和你使用的那一套微服務(wù)集成器拿對(duì)應(yīng)版本即可。我一般會(huì)把版本統(tǒng)一管理在一個(gè)依賴清單文件里避免多個(gè)服務(wù)各自為戰(zhàn)。引入依賴之后還有一個(gè)更重要的動(dòng)作埋點(diǎn)。Sentinel 所有規(guī)則都是圍繞“資源”來定義的資源名就是一個(gè)接口、一段代碼或者一個(gè)方法的唯一標(biāo)識(shí)。埋點(diǎn)最原始的方式是手動(dòng)保護(hù)業(yè)務(wù)代碼Entry entry null; try { // 進(jìn)入資源資源名建議使用接口路徑例如 /api/order/create entry SphU.entry(/api/order/create, EntryType.IN); // 這里是你的業(yè)務(wù)邏輯 } catch (BlockException e) { // 被限流或熔斷時(shí)執(zhí)行兜底邏輯比如返回提示 } finally { if (entry ! null) { entry.exit(); } }手動(dòng)埋點(diǎn)的好處是控制精確壞處是侵入性強(qiáng)每個(gè)需要保護(hù)的接口都要寫一遍。所以更常見的做法是用注解SentinelResource(value createOrder, blockHandler createOrderBlockHandler) public String createOrder(Long orderId) { // 業(yè)務(wù)邏輯 } public String createOrderBlockHandler(Long orderId, BlockException e) { return 系統(tǒng)繁忙請(qǐng)稍后重試; }這里我非常想強(qiáng)調(diào)一個(gè)配置時(shí)最容易忽略的細(xì)節(jié)注解里的value和控制臺(tái)上看到的資源名必須完全一致包括大小寫和路徑風(fēng)格。很多規(guī)則“不生效”根本不是系統(tǒng)問題而是代碼里和規(guī)則上寫的是兩個(gè)不同的字符串。團(tuán)隊(duì)內(nèi)部最好約定統(tǒng)一規(guī)則接口路徑風(fēng)格的資源名入口寫在 Controller 層內(nèi)部細(xì)粒度方法再單獨(dú)埋點(diǎn)。另外埋點(diǎn)后entry.exit()必須放在finally里保證執(zhí)行。如果漏了統(tǒng)計(jì)的“當(dāng)前正在執(zhí)行數(shù)量”會(huì)一直累加后續(xù)的請(qǐng)求就會(huì)被誤判成超線程并發(fā)規(guī)則表現(xiàn)就跟預(yù)期完全對(duì)不上了。2.2 啟動(dòng)控制臺(tái)與規(guī)則下發(fā)依賴和埋點(diǎn)完成后第二步是部署控制臺(tái)。控制臺(tái)是一個(gè)獨(dú)立運(yùn)行的應(yīng)用負(fù)責(zé)展示每個(gè)客戶端的實(shí)時(shí)指標(biāo)也負(fù)責(zé)把人寫的規(guī)則推送到客戶端內(nèi)存?？蛻舳私尤肟刂婆_(tái)時(shí)一般通過 JVM 參數(shù)指定控制臺(tái)地址和項(xiàng)目名java -Dproject.nameorder-service \ -Dcsp.sentinel.dashboard.server127.0.0.1:8080 \ -jar order-service.jar把csp.sentinel.dashboard.server指向控制臺(tái)的地址和端口。啟動(dòng)完成后打開控制臺(tái)網(wǎng)頁過十幾秒就能在“機(jī)器列表”里看到你的服務(wù)實(shí)例。之后再進(jìn)入“簇點(diǎn)鏈路”頁面就能看到所有被埋過點(diǎn)的資源。選擇某個(gè)資源點(diǎn)“流控”按鈕填入閾值并保存規(guī)則就被實(shí)時(shí)推送到 JVM 內(nèi)存。這里必須明確通過控制臺(tái)配置的規(guī)則默認(rèn)只保存在內(nèi)存里應(yīng)用一重啟規(guī)則就沒了。很多第一次用的人都會(huì)在這個(gè)地方翻車頭天下午辛辛苦苦配了一堆規(guī)則晚上發(fā)布一個(gè)新版本第二天發(fā)現(xiàn)所有限流全部失效。因此規(guī)則持久化不是可選項(xiàng)而是生產(chǎn)環(huán)境接入的必選動(dòng)作。2.3 規(guī)則如何做到不丟持久化規(guī)則持久化的思路是把規(guī)則從“控制臺(tái)直接推內(nèi)存”改成“客戶端從一個(gè)可靠數(shù)據(jù)源里拉”。這個(gè)數(shù)據(jù)源可以是本地文件、數(shù)據(jù)庫或者你們已有的配置中心。Sentinel 提供了一套數(shù)據(jù)源擴(kuò)展機(jī)制核心就是ReadableDataSource和WritableDataSource。以本地文件為例規(guī)則會(huì)先寫到磁盤文件里應(yīng)用啟動(dòng)時(shí)就從這個(gè)文件加載ReadableDataSourceString, ListFlowRule flowDataSource new FileRefreshableDataSource(flow-rules.json, source - JSON.parseArray(source, FlowRule.class) ); FlowRuleManager.register2Property(flowDataSource.getProperty());這樣應(yīng)用重啟后會(huì)自動(dòng)從文件里恢復(fù)規(guī)則。但本地文件只解決“規(guī)則不丟”的問題還沒解決“多臺(tái)機(jī)器同時(shí)改”的問題所以生產(chǎn)環(huán)境我更推薦走配置中心把所有規(guī)則放在同一個(gè)配置里改動(dòng)后自動(dòng)推送到每一臺(tái)機(jī)器。只要把規(guī)則文件的內(nèi)容變成配置中心里的一個(gè)配置項(xiàng)然后使用對(duì)應(yīng)的數(shù)據(jù)源擴(kuò)展客戶端就能保持和配置中心同步。做持久化時(shí)要注意一個(gè)坑規(guī)則推送方式有“拉模式”和“推模式”的區(qū)別。拉模式下客戶端定時(shí)從數(shù)據(jù)源拉取最新規(guī)則簡單但對(duì)數(shù)據(jù)源壓力大更新延遲高推模式下配置中心主動(dòng)推送實(shí)時(shí)性好也更容易在推送前做校驗(yàn)。多數(shù)線上環(huán)境都應(yīng)該選擇推模式。3. 底層原理從一次調(diào)用看 Sentinel 內(nèi)部發(fā)生了什么配置層面的東西練幾遍就熟了但底層原理才是區(qū)分“會(huì)用”和“用得明白”的分水嶺。我下面用一次普通的接口調(diào)用來拆解 Sentinel 的內(nèi)部動(dòng)作。3.1 責(zé)任鏈設(shè)計(jì)ProcessorSlot 鏈當(dāng)你調(diào)用SphU.entry()時(shí)Sentinel 并不是簡單做一個(gè)計(jì)數(shù)器判斷而是把這次請(qǐng)求交給一條處理鏈去執(zhí)行。這條鏈由一組 slot 組成每個(gè) slot 負(fù)責(zé)一件獨(dú)立的事Slot 名稱職責(zé)NodeSelectorSlot負(fù)責(zé)構(gòu)建調(diào)用鏈路徑上的上下文節(jié)點(diǎn)用來區(qū)分不同來源的調(diào)用ClusterBuilderSlot構(gòu)建資源的集群維度統(tǒng)計(jì)節(jié)點(diǎn)維護(hù)該資源的全局實(shí)時(shí)統(tǒng)計(jì)StatisticSlot完成所有指標(biāo)統(tǒng)計(jì)比如請(qǐng)求總數(shù)、成功數(shù)、失敗數(shù)、RT并觸發(fā)后續(xù)規(guī)則判斷AuthoritySlot黑白名單判斷校驗(yàn)調(diào)用來源是否被允許SystemSlot系統(tǒng)負(fù)載保護(hù)超過系統(tǒng)閾值直接攔截FlowSlot流量控制規(guī)則校驗(yàn)DegradeSlot熔斷降級(jí)規(guī)則校驗(yàn)這套設(shè)計(jì)借鑒了 Web 應(yīng)用里常見過濾器鏈的思路。每次調(diào)用依次經(jīng)過這些 slot每個(gè) slot 只關(guān)心自己負(fù)責(zé)的邏輯。以流控規(guī)則為例StatisticSlot 先把本次請(qǐng)求記錄到統(tǒng)計(jì)結(jié)構(gòu)里然后 FlowSlot 讀流控規(guī)則看當(dāng)前統(tǒng)計(jì)值是否已經(jīng)超過閾值。一旦超過就直接拋出限流異常后面的業(yè)務(wù)代碼就不會(huì)執(zhí)行了。理解這條鏈還有個(gè)好處就是知道 Sentinel 的擴(kuò)展點(diǎn)在哪。官方允許你插入自定義 slot通過實(shí)現(xiàn)ProcessorSlot接口再替換SlotChainBuilder來追加自己的處理邏輯。這樣你可以在不改變原有規(guī)則的前提下加入自定義的攔截邏輯比如做灰度放行、自定義優(yōu)先級(jí)排隊(duì)。鏈本身是每個(gè)資源單獨(dú)構(gòu)建的內(nèi)部會(huì)緩存復(fù)用不會(huì)每次請(qǐng)求都重新創(chuàng)建。這也是 Sentinel 能夠保持低開銷的關(guān)鍵之一。3.2 滑動(dòng)窗口如何統(tǒng)計(jì) QPS搞清楚 QPS 是怎么算出來的是理解限流閾值的關(guān)鍵。很多人在寫限流時(shí)下意識(shí)用“固定一秒”的計(jì)數(shù)但固定時(shí)間窗口有一個(gè)問題如果 0.9 秒時(shí)來了 100 個(gè)請(qǐng)求下一秒剛開始又來了 100 個(gè)請(qǐng)求這兩個(gè)窗口單獨(dú)看都沒超閾值但零點(diǎn)幾秒內(nèi)的瞬時(shí)請(qǐng)求其實(shí)是 200 個(gè)能把服務(wù)瞬間打沒。Sentinel 用的是滑動(dòng)窗口。它把時(shí)間切成一格一格的“槽”每個(gè)槽記錄這個(gè)小時(shí)間段內(nèi)的計(jì)數(shù)統(tǒng)計(jì)當(dāng)前時(shí)間點(diǎn)往前推一個(gè)完整窗口的總和。舉個(gè)例子默認(rèn)配置下 1 秒被分成 2 個(gè)槽每個(gè)槽記錄 500ms 的數(shù)據(jù)。當(dāng)前時(shí)間落在哪個(gè)槽就更新哪個(gè)槽窗口滑動(dòng)時(shí)早于當(dāng)前時(shí)間窗口的數(shù)據(jù)會(huì)被自動(dòng)丟掉。這樣統(tǒng)計(jì)出來的 QPS 更貼近真實(shí)瞬時(shí)流量不會(huì)出現(xiàn)固定窗口那種跨邊界突刺。在實(shí)現(xiàn)層面這一套數(shù)據(jù)結(jié)構(gòu)叫LeapArray底層是一個(gè)環(huán)形數(shù)組。數(shù)組里的每個(gè)槽維護(hù)一個(gè)MetricBucket里面存放著各種計(jì)數(shù)指標(biāo)。因?yàn)榻y(tǒng)計(jì)操作非常高頻Sentinel 在底層用了一些無鎖化和原子類的技巧來減少并發(fā)沖突這也是它能在高并發(fā)下保持穩(wěn)定性能的原因。你需要記得的關(guān)鍵點(diǎn)Sentinel 統(tǒng)計(jì)窗口本身也可以通過配置調(diào)整。默認(rèn)是 1 秒窗口對(duì)常規(guī)場景足夠了如果你的服務(wù)要求更精細(xì)的統(tǒng)計(jì)可以把窗口切小但代價(jià)是統(tǒng)計(jì)數(shù)據(jù)結(jié)構(gòu)占用更多內(nèi)存。我在調(diào)優(yōu)時(shí)一般不會(huì)輕易動(dòng)這個(gè)參數(shù)除非壓測發(fā)現(xiàn)有明顯的窗口邊緣誤判。3.3 熔斷降級(jí)的狀態(tài)機(jī)實(shí)現(xiàn)流量控制看統(tǒng)計(jì)窗口熔斷降級(jí)看的是狀態(tài)機(jī)。Sentinel 的熔斷邏輯圍繞三種狀態(tài)轉(zhuǎn)換CLOSED熔斷關(guān)閉請(qǐng)求正常放行。OPEN熔斷開啟所有請(qǐng)求都會(huì)被快速拒絕。HALF_OPEN半開狀態(tài)允許少量探測請(qǐng)求通過用探測結(jié)果決定是恢復(fù)關(guān)閉還是繼續(xù)保持熔斷。狀態(tài)流轉(zhuǎn)是這樣的初始是 CLOSED當(dāng)熔斷策略的指標(biāo)超過閾值時(shí)狀態(tài)進(jìn)入 OPENOPEN 狀態(tài)會(huì)持續(xù)一個(gè)時(shí)間窗口這個(gè)窗口時(shí)間由timeWindow參數(shù)控制窗口到了之后不直接回到 CLOSED而是先進(jìn)入 HALF_OPEN放幾個(gè)請(qǐng)求去試探下游是否已經(jīng)恢復(fù)如果試探成功狀態(tài)轉(zhuǎn)回 CLOSED重新正常放流如果試探還是失敗則立刻打回 OPEN繼續(xù)熔斷等待下一次嘗試。這套狀態(tài)機(jī)的價(jià)值在于“試探”。熔斷不是一刀切永久拒絕而是給下游恢復(fù)留出通道。生產(chǎn)環(huán)境里一個(gè)常見錯(cuò)誤是把timeWindow設(shè)置得太短比如 5 秒下游數(shù)據(jù)庫還在重啟半開試探立刻失敗又被打回 OPEN往復(fù)幾次后效果不好設(shè)置太長又會(huì)造成長時(shí)間的無效拒絕。我的經(jīng)驗(yàn)是結(jié)合依賴方實(shí)際的恢復(fù)速度來設(shè)置通常 30 秒起步寧可長一些也不要頻繁在半開狀態(tài)間震蕩。4. 規(guī)則配置細(xì)節(jié)與參數(shù)調(diào)優(yōu)控制臺(tái)上填幾個(gè)數(shù)字很容易但每個(gè)數(shù)字背后的含義和組合效果才是重點(diǎn)。這一節(jié)會(huì)把主流規(guī)則類型的關(guān)鍵參數(shù)拆開。4.1 流量控制規(guī)則的關(guān)鍵參數(shù)流量控制規(guī)則最基礎(chǔ)的配置里有這么幾個(gè)參數(shù)參數(shù)含義取值說明resource資源名和埋點(diǎn)名稱完全一致grade閾值類型0 表示 QPS1 表示并發(fā)線程數(shù)count閾值達(dá)到這個(gè)值就觸發(fā)限流strategy流控策略0 表示直接基于資源自身1 表示關(guān)聯(lián)資源2 表示鏈路controlBehavior流控效果0 快速失敗1 預(yù)熱2 勻速排隊(duì)大多數(shù)場景直接用 QPS 閾值就夠了也就是把grade設(shè)為 0。但有一種情況我建議用并發(fā)線程數(shù)就是你的接口內(nèi)部阻塞較多、連接池有限、單個(gè)請(qǐng)求耗時(shí)很長。這時(shí)候 QPS 限流會(huì)掩蓋“同時(shí)占用線程過多”的真實(shí)風(fēng)險(xiǎn)改用并發(fā)線程數(shù)限制反而更穩(wěn)。再單獨(dú)說controlBehavior?？焖偈∽畋┝Φ珪?huì)把超出的請(qǐng)求一瞬間全部拒絕對(duì)用戶不友好預(yù)熱模式適合系統(tǒng)剛啟動(dòng)、或者規(guī)則閾值長期較低的場景——它允許流量在設(shè)定的預(yù)熱時(shí)間內(nèi)緩慢爬升到目標(biāo)閾值而不是一上線就滿負(fù)荷放行勻速排隊(duì)則適合有任務(wù)堆積場景的削峰填谷請(qǐng)求排成隊(duì)列勻速通過而不是集中爆發(fā)。我自己在秒殺系統(tǒng)里用得最多的是預(yù)熱勻速排隊(duì)組合既能保住后端又不會(huì)把用戶體驗(yàn)全砍掉。4.2 熔斷規(guī)則的閾值設(shè)置技巧熔斷規(guī)則在配置時(shí)有三種策略慢調(diào)用比例、異常比例、異常數(shù)。官方不同版本的參數(shù)名有差異我以當(dāng)前主流版本的習(xí)慣寫法來說明DegradeRule rule new DegradeRule(); rule.setResource(/api/pay/callback); // 慢調(diào)用比例策略RT 超過 500ms 算慢調(diào)用 rule.setGrade(CircuitBreakingStrategy.SLOW_REQUEST_RATIO); rule.setCount(500); rule.setTimeWindow(30); rule.setStatIntervalMs(10000); // 10 秒內(nèi)至少 5 個(gè)請(qǐng)求時(shí)才開始判斷 rule.setMinRequestAmount(5); // 慢調(diào)用占比超過 80% 就熔斷 rule.setSlowRatioThreshold(0.8);這里有一個(gè)新手常犯的錯(cuò)誤直接把count當(dāng)成平均響應(yīng)時(shí)間閾值來填。SLOW_REQUEST_RATIO 策略下count表示“響應(yīng)時(shí)間超過多少毫秒算慢調(diào)用”而不是“平均 RT 超過多少就熔斷”。兩者的差別很大。慢調(diào)用比例更科學(xué)因?yàn)槠骄?RT 容易被極端值拉高只要少數(shù)請(qǐng)求特別慢就會(huì)觸發(fā)誤判。異常比例和異常數(shù)則適合那些錯(cuò)誤率明顯代表下游故障的場景。但要注意這里統(tǒng)計(jì)的是業(yè)務(wù)代碼拋出的異常如果你在業(yè)務(wù)邏輯里大量使用 try-catch 把異常吞掉或者對(duì)外層錯(cuò)誤做了包裝統(tǒng)計(jì)到的異常數(shù)就是包裝后的數(shù)量規(guī)則效果可能會(huì)失真。熔斷規(guī)則配置時(shí)還要注意minRequestAmount。它的作用是避免“樣本太少誤判”。比如一個(gè)接口剛上線只在 3 個(gè)請(qǐng)求里失敗了 2 次異常比例就到 66%如果沒設(shè)置最小請(qǐng)求數(shù)可能瞬間就被熔斷。我一般要求團(tuán)隊(duì)在多數(shù)場景下把這個(gè)值設(shè)為至少 5 到 10。4.3 系統(tǒng)保護(hù)與熱點(diǎn)參數(shù)規(guī)則系統(tǒng)規(guī)則和前面幾種規(guī)則不同它不針對(duì)某個(gè)具體資源而是對(duì)整個(gè)系統(tǒng)的入口流量做保護(hù)。你可以設(shè)定一個(gè)負(fù)載閾值當(dāng)系統(tǒng)負(fù)載超過這個(gè)值就開始限制入口請(qǐng)求。這種規(guī)則適合應(yīng)對(duì)“服務(wù)整體過載”的場景因?yàn)樗吹牟皇悄硞€(gè)接口的指標(biāo)而是整個(gè)機(jī)器的健康度。配置時(shí)一般從 JVM 參數(shù)或者控制臺(tái)讀取系統(tǒng)指標(biāo)再和預(yù)設(shè)閾值比較。熱點(diǎn)參數(shù)限流則非常適合常見的“單點(diǎn)熱點(diǎn)”場景。比如一個(gè)商品詳情接口總 QPS 可能沒超過整體閾值但某個(gè)爆款商品的 QPS 單獨(dú)很高。這時(shí)普通流量規(guī)則攔不住因?yàn)榭偭繘]超。熱點(diǎn)規(guī)則可以針對(duì)參數(shù)值單獨(dú)限流參數(shù) id 等于 9527 時(shí)每秒只允許 100 個(gè)請(qǐng)求其他參數(shù)值按默認(rèn)總閾值走。配置時(shí)通常要指定參數(shù)索引和第幾位的參數(shù)這里最容易踩的坑是參數(shù)索引寫錯(cuò)比如方法首參是userId次參是goodsId你要對(duì)商品限流就必須把索引配成 1而不是 0。5. 常見問題與排障經(jīng)驗(yàn)實(shí)錄配置和原理都聊完了最后一節(jié)是我在落地過程中真正遇到過的疑難雜癥。這些坑在官方文檔里不會(huì)寫太細(xì)但遇到了非常耗時(shí)。5.1 規(guī)則不生效的排查路線規(guī)則配置后界面上也顯示成功了流量打上去就是不被限流。遇到這種情況我一般按下面的順序排查。先看資源名是否完全一致。前面提到過手動(dòng)埋點(diǎn)SphU.entry(/api/order/create)和注解SentinelResource(value createOrder)寫出的資源名只要有一點(diǎn)不一致規(guī)則就關(guān)聯(lián)不上。這一步是最常見的根因。再看當(dāng)前應(yīng)用是否成功接入了控制臺(tái)。進(jìn)控制臺(tái)“簇點(diǎn)鏈路”頁找到對(duì)應(yīng)資源確認(rèn)已經(jīng)能看到實(shí)時(shí)的請(qǐng)求數(shù)和指標(biāo)。如果資源根本不出現(xiàn)在鏈路里說明埋點(diǎn)本身有問題規(guī)則自然無效。還要看統(tǒng)計(jì)采樣。默認(rèn)規(guī)則只在統(tǒng)計(jì)滑窗內(nèi)有數(shù)據(jù)時(shí)才參與判斷。如果你設(shè)置了minRequestAmount或類似的閾值而當(dāng)前請(qǐng)求樣本太少即使流量看起來超了也不會(huì)觸發(fā)。很多人在壓測時(shí)發(fā)現(xiàn)前幾秒規(guī)則不生效其實(shí)是因?yàn)闃颖緮?shù)還沒達(dá)到最低判定要求。最后看是否并發(fā)到達(dá)。QPS 限流判斷的是滑動(dòng)窗口內(nèi)統(tǒng)計(jì)出來的速率如果你用線程并發(fā)數(shù)模式那要看的是“當(dāng)前占用線程數(shù)”兩者表現(xiàn)完全不同。改規(guī)則前先確認(rèn)自己用的哪個(gè)模式別拿 QPS 的預(yù)期去解釋線程數(shù)的現(xiàn)象。5.2 控制臺(tái)數(shù)據(jù)不刷新或看不到服務(wù)控制臺(tái)列表里遲遲看不到客戶端或者看到之后指標(biāo)曲線死的一般不動(dòng)我通常會(huì)先排查客戶端到控制臺(tái)的網(wǎng)絡(luò)連通性。Sentinel 的 dashboard 通信走的是 HTTP 接口如果中間有防火墻或者端口沒放開數(shù)據(jù)就傳不過來。然后看客戶端的project.name和dashboard.server參數(shù)是否真實(shí)生效。Spring Boot 應(yīng)用在引入相關(guān)依賴后可能會(huì)自動(dòng)注入?yún)?shù)但如果你同時(shí)指定了配置文件里的對(duì)應(yīng)項(xiàng)兩邊不一致時(shí)容易讓人困惑。啟動(dòng)時(shí)加-Dcsp.sentinel.dashboard.server...是最直接的方式。還有一個(gè)環(huán)境相關(guān)的問題服務(wù)實(shí)例注冊到控制臺(tái)會(huì)有一定的延遲并不是啟動(dòng)后立即出現(xiàn)。正常情況大約需要等 10 到 30 秒。如果等了很久還是沒有去看客戶端在logs/csp目錄下生成的sentinel-record.log里面會(huì)明確記錄注冊過程和報(bào)錯(cuò)信息。5.3 高并發(fā)下的性能損耗與取舍另一個(gè)大家最關(guān)心的問題是Sentinel 本身會(huì)吃掉多少性能從我的壓測經(jīng)驗(yàn)看常規(guī)的限流判斷在每請(qǐng)求上增加的耗時(shí)非常低通常在大幾十微秒到一百多微秒這個(gè)量級(jí)主要影響不是 CPU而是業(yè)務(wù)代碼里多了一次資源的 entry/exit 調(diào)用和統(tǒng)計(jì)更新。對(duì)于絕大多數(shù)業(yè)務(wù)系統(tǒng)這個(gè)開銷可以接受。但如果你的接口本身就是超高頻調(diào)用比如單機(jī)每秒幾萬次又想同時(shí)開啟多種規(guī)則那就要關(guān)注幾個(gè)點(diǎn)一是把不必要的規(guī)則類型關(guān)掉只保留必需的二是合理控制統(tǒng)計(jì)窗口和滑窗粒度三是避免在兜底邏輯里做耗時(shí)操作。兜底方法里如果做了遠(yuǎn)程調(diào)用或者復(fù)雜計(jì)算這個(gè)開銷反而容易掩蓋 Sentinel 本身的性能表現(xiàn)。壓測時(shí)建議單獨(dú)測兩種狀態(tài)一種是不接入 Sentinel 的裸接口性能一種是開啟限流規(guī)則后的性能。兩者對(duì)比你才能真正知道規(guī)則疊加帶來的成本而不是憑感覺懷疑它。使用 Sentinel 一年多之后我最大的感受是這類組件的難點(diǎn)不在于“怎么配置”而在于你是否真正理解流量和依賴之間的因果關(guān)系。配置只是一個(gè)出口背后的滑動(dòng)窗口、責(zé)任鏈、熔斷狀態(tài)機(jī)才是決定規(guī)則是否合理的地基。每次上線新業(yè)務(wù)、每次壓測調(diào)優(yōu)我都會(huì)回到控制臺(tái)重新看一遍資源名、閾值和規(guī)則之間的對(duì)應(yīng)關(guān)系而不是只看那一兩條報(bào)警。希望這篇文章里那些踩過的坑和調(diào)參的思路能幫你少走一段彎路。 Sentinel實(shí)戰(zhàn)：配置流程、底層原理與高并發(fā)防護(hù)策略
做服務(wù)治理的人都知道一句話流量防護(hù)不是上線之后就一勞永逸的事。我最早接觸 Sentinel 是在一次壓測現(xiàn)場——某個(gè)核心接口在流量翻倍時(shí)直接讓數(shù)據(jù)庫連接池打滿后續(xù)所有依賴它的服務(wù)開始連環(huán)超時(shí)當(dāng)時(shí)團(tuán)隊(duì)的應(yīng)對(duì)方式還停留在“加機(jī)器”這一個(gè)維度上。后來才開始認(rèn)真搞限流降級(jí)也才慢慢把這些問題帶到 Sentinel 的配置和底層原理上來。聊到“Sentinel 的配置流程及底層原理”大多數(shù)人第一反應(yīng)是去控制臺(tái)加幾條流控規(guī)則。但真正踩過坑之后才會(huì)意識(shí)到配置流程背后是對(duì)資源模型的理解底層原理背后是統(tǒng)計(jì)窗口和狀態(tài)狀態(tài)機(jī)。這篇文章不打算把官方文檔復(fù)述一遍而是從一個(gè)實(shí)踐者的角度把接入步驟、規(guī)則設(shè)置、控制臺(tái)用法和核心機(jī)制串成一條線講清楚“每一步為什么要這么做”也讓準(zhǔn)備接手這塊的讀者少走彎路。你可能已經(jīng)用它做過一些基礎(chǔ)限流也可能只是聽過名字這里盡量讓兩種讀者都能拿到自己需要的東西。1. 先想明白 Sentinel 解決什么問題很多團(tuán)隊(duì)是在系統(tǒng)已經(jīng)被突發(fā)流量打掛之后才想起上 Sentinel但上完之后又不確定它到底應(yīng)該管到哪一層。先把這個(gè)底層問題聊透后面配置才會(huì)自然。Sentinel 的核心價(jià)值說起來很樸素保護(hù)系統(tǒng)不被瞬時(shí)流量沖垮同時(shí)避免某個(gè)下游故障把整條鏈路拖死。它做的事情可以拆成三件一是流量控制給每個(gè)接口設(shè)置一個(gè)可接受的最大訪問量超過的部分直接拒絕二是熔斷降級(jí)當(dāng)下游接口的失敗率或者響應(yīng)時(shí)間超過閾值時(shí)暫時(shí)切掉這條調(diào)用讓下游有時(shí)間恢復(fù)三是系統(tǒng)負(fù)載保護(hù)當(dāng)整體機(jī)器的 CPU、負(fù)載已經(jīng)過高時(shí)就不再讓新的請(qǐng)求進(jìn)入系統(tǒng)。這三件事看起來獨(dú)立最終目的其實(shí)一致把“不可控的外部流量”和“已經(jīng)出現(xiàn)的內(nèi)部故障”隔離在系統(tǒng)承受范圍之內(nèi)。所以你在配置時(shí)不應(yīng)該只是為了填一個(gè)數(shù)字而是要回答一個(gè)問題這個(gè)接口在當(dāng)前的機(jī)器規(guī)格、數(shù)據(jù)庫連接數(shù)、第三方依賴能力下到底能承受多少 QPS如果答不上來那后面所有規(guī)則都是拍腦袋。1.1 核心能力限流、熔斷、系統(tǒng)保護(hù)拿一張對(duì)照表來概括這也是我在做技術(shù)選型評(píng)審時(shí)習(xí)慣用的方式能力解決什么問題典型配置入口流量控制閾值內(nèi)的請(qǐng)求放行超出部分快速失敗、排隊(duì)或預(yù)熱流控規(guī)則熔斷降級(jí)下游異常比例或響應(yīng)時(shí)間超限時(shí)主動(dòng)斷開調(diào)用熔斷規(guī)則系統(tǒng)自適應(yīng)保護(hù)根據(jù)機(jī)器整體負(fù)載限制入口流量防止系統(tǒng)整體過載系統(tǒng)規(guī)則熱點(diǎn)參數(shù)限流針對(duì)某個(gè)熱點(diǎn)參數(shù)值如商品ID、用戶ID單獨(dú)設(shè)定閾值熱點(diǎn)規(guī)則這四類規(guī)則在配置時(shí)互不沖突也可以疊加使用。比如一個(gè)訂單查詢接口既需要設(shè)置總量限流又需要對(duì)某些秒殺商品的參數(shù)做熱點(diǎn)限流還需要在數(shù)據(jù)庫慢查詢導(dǎo)致 RT 上升時(shí)觸發(fā)熔斷。規(guī)則之間是不同維度的保護(hù)沒有誰替代誰的問題。1.2 引入前先做一次技術(shù)判斷有一點(diǎn)我想先潑冷水并不是所有系統(tǒng)都需要 Sentinel。如果你的服務(wù)沒有明顯的波峰波谷、也沒有脆弱的第三方依賴純單機(jī)部署且并發(fā)量極低那用更輕量的信號(hào)量限流或者一個(gè)簡單的攔截器就夠了。引入 Sentinel 本身會(huì)帶來一些運(yùn)行成本和學(xué)習(xí)成本比如控制臺(tái)部署、規(guī)則持久化、客戶端上報(bào)這些對(duì)小團(tuán)隊(duì)來說并不是零負(fù)擔(dān)。我的建議是先判斷是否存在以下場景第一有突發(fā)的營銷流量或者被爬蟲刷接口的可能第二系統(tǒng)中存在一個(gè)明顯脆弱的依賴比如某臺(tái)數(shù)據(jù)庫、某個(gè)外部 API一旦它故障會(huì)拖垮整條鏈路第三你們正在做微服務(wù)拆分服務(wù)的調(diào)用關(guān)系網(wǎng)越來越密。滿足其中任意一條才有必要認(rèn)真考慮 Sentinel并且值得把規(guī)則設(shè)計(jì)和持續(xù)調(diào)優(yōu)當(dāng)成一項(xiàng)長期工作。2. 接入 Sentinel 的完整配置流程前面是認(rèn)知層面的事這一節(jié)開始進(jìn)入實(shí)際操作。接入流程說簡單也簡單總共就四步引入依賴、埋點(diǎn)資源、啟動(dòng)控制臺(tái)、下發(fā)規(guī)則。但每一步里都藏著容易繞彎的細(xì)節(jié)。2.1 依賴引入與資源埋點(diǎn)首先在項(xiàng)目的依賴管理文件里加入 Sentinel 相關(guān)組件。如果你用的是 Java 技術(shù)棧最簡單的做法是先引入核心包再加上控制臺(tái)通信的擴(kuò)展包。具體坐標(biāo)不用死記到 Maven 倉庫搜sentinel-core和你使用的那一套微服務(wù)集成器拿對(duì)應(yīng)版本即可。我一般會(huì)把版本統(tǒng)一管理在一個(gè)依賴清單文件里避免多個(gè)服務(wù)各自為戰(zhàn)。引入依賴之后還有一個(gè)更重要的動(dòng)作埋點(diǎn)。Sentinel 所有規(guī)則都是圍繞“資源”來定義的資源名就是一個(gè)接口、一段代碼或者一個(gè)方法的唯一標(biāo)識(shí)。埋點(diǎn)最原始的方式是手動(dòng)保護(hù)業(yè)務(wù)代碼Entry entry null; try { // 進(jìn)入資源資源名建議使用接口路徑例如 /api/order/create entry SphU.entry(/api/order/create, EntryType.IN); // 這里是你的業(yè)務(wù)邏輯 } catch (BlockException e) { // 被限流或熔斷時(shí)執(zhí)行兜底邏輯比如返回提示 } finally { if (entry ! null) { entry.exit(); } }手動(dòng)埋點(diǎn)的好處是控制精確壞處是侵入性強(qiáng)每個(gè)需要保護(hù)的接口都要寫一遍。所以更常見的做法是用注解SentinelResource(value createOrder, blockHandler createOrderBlockHandler) public String createOrder(Long orderId) { // 業(yè)務(wù)邏輯 } public String createOrderBlockHandler(Long orderId, BlockException e) { return 系統(tǒng)繁忙請(qǐng)稍后重試; }這里我非常想強(qiáng)調(diào)一個(gè)配置時(shí)最容易忽略的細(xì)節(jié)注解里的value和控制臺(tái)上看到的資源名必須完全一致包括大小寫和路徑風(fēng)格。很多規(guī)則“不生效”根本不是系統(tǒng)問題而是代碼里和規(guī)則上寫的是兩個(gè)不同的字符串。團(tuán)隊(duì)內(nèi)部最好約定統(tǒng)一規(guī)則接口路徑風(fēng)格的資源名入口寫在 Controller 層內(nèi)部細(xì)粒度方法再單獨(dú)埋點(diǎn)。另外埋點(diǎn)后entry.exit()必須放在finally里保證執(zhí)行。如果漏了統(tǒng)計(jì)的“當(dāng)前正在執(zhí)行數(shù)量”會(huì)一直累加后續(xù)的請(qǐng)求就會(huì)被誤判成超線程并發(fā)規(guī)則表現(xiàn)就跟預(yù)期完全對(duì)不上了。2.2 啟動(dòng)控制臺(tái)與規(guī)則下發(fā)依賴和埋點(diǎn)完成后第二步是部署控制臺(tái)。控制臺(tái)是一個(gè)獨(dú)立運(yùn)行的應(yīng)用負(fù)責(zé)展示每個(gè)客戶端的實(shí)時(shí)指標(biāo)也負(fù)責(zé)把人寫的規(guī)則推送到客戶端內(nèi)存?？蛻舳私尤肟刂婆_(tái)時(shí)一般通過 JVM 參數(shù)指定控制臺(tái)地址和項(xiàng)目名java -Dproject.nameorder-service \ -Dcsp.sentinel.dashboard.server127.0.0.1:8080 \ -jar order-service.jar把csp.sentinel.dashboard.server指向控制臺(tái)的地址和端口。啟動(dòng)完成后打開控制臺(tái)網(wǎng)頁過十幾秒就能在“機(jī)器列表”里看到你的服務(wù)實(shí)例。之后再進(jìn)入“簇點(diǎn)鏈路”頁面就能看到所有被埋過點(diǎn)的資源。選擇某個(gè)資源點(diǎn)“流控”按鈕填入閾值并保存規(guī)則就被實(shí)時(shí)推送到 JVM 內(nèi)存。這里必須明確通過控制臺(tái)配置的規(guī)則默認(rèn)只保存在內(nèi)存里應(yīng)用一重啟規(guī)則就沒了。很多第一次用的人都會(huì)在這個(gè)地方翻車頭天下午辛辛苦苦配了一堆規(guī)則晚上發(fā)布一個(gè)新版本第二天發(fā)現(xiàn)所有限流全部失效。因此規(guī)則持久化不是可選項(xiàng)而是生產(chǎn)環(huán)境接入的必選動(dòng)作。2.3 規(guī)則如何做到不丟持久化規(guī)則持久化的思路是把規(guī)則從“控制臺(tái)直接推內(nèi)存”改成“客戶端從一個(gè)可靠數(shù)據(jù)源里拉”。這個(gè)數(shù)據(jù)源可以是本地文件、數(shù)據(jù)庫或者你們已有的配置中心。Sentinel 提供了一套數(shù)據(jù)源擴(kuò)展機(jī)制核心就是ReadableDataSource和WritableDataSource。以本地文件為例規(guī)則會(huì)先寫到磁盤文件里應(yīng)用啟動(dòng)時(shí)就從這個(gè)文件加載ReadableDataSourceString, ListFlowRule flowDataSource new FileRefreshableDataSource(flow-rules.json, source - JSON.parseArray(source, FlowRule.class) ); FlowRuleManager.register2Property(flowDataSource.getProperty());這樣應(yīng)用重啟后會(huì)自動(dòng)從文件里恢復(fù)規(guī)則。但本地文件只解決“規(guī)則不丟”的問題還沒解決“多臺(tái)機(jī)器同時(shí)改”的問題所以生產(chǎn)環(huán)境我更推薦走配置中心把所有規(guī)則放在同一個(gè)配置里改動(dòng)后自動(dòng)推送到每一臺(tái)機(jī)器。只要把規(guī)則文件的內(nèi)容變成配置中心里的一個(gè)配置項(xiàng)然后使用對(duì)應(yīng)的數(shù)據(jù)源擴(kuò)展客戶端就能保持和配置中心同步。做持久化時(shí)要注意一個(gè)坑規(guī)則推送方式有“拉模式”和“推模式”的區(qū)別。拉模式下客戶端定時(shí)從數(shù)據(jù)源拉取最新規(guī)則簡單但對(duì)數(shù)據(jù)源壓力大更新延遲高推模式下配置中心主動(dòng)推送實(shí)時(shí)性好也更容易在推送前做校驗(yàn)。多數(shù)線上環(huán)境都應(yīng)該選擇推模式。3. 底層原理從一次調(diào)用看 Sentinel 內(nèi)部發(fā)生了什么配置層面的東西練幾遍就熟了但底層原理才是區(qū)分“會(huì)用”和“用得明白”的分水嶺。我下面用一次普通的接口調(diào)用來拆解 Sentinel 的內(nèi)部動(dòng)作。3.1 責(zé)任鏈設(shè)計(jì)ProcessorSlot 鏈當(dāng)你調(diào)用SphU.entry()時(shí)Sentinel 并不是簡單做一個(gè)計(jì)數(shù)器判斷而是把這次請(qǐng)求交給一條處理鏈去執(zhí)行。這條鏈由一組 slot 組成每個(gè) slot 負(fù)責(zé)一件獨(dú)立的事Slot 名稱職責(zé)NodeSelectorSlot負(fù)責(zé)構(gòu)建調(diào)用鏈路徑上的上下文節(jié)點(diǎn)用來區(qū)分不同來源的調(diào)用ClusterBuilderSlot構(gòu)建資源的集群維度統(tǒng)計(jì)節(jié)點(diǎn)維護(hù)該資源的全局實(shí)時(shí)統(tǒng)計(jì)StatisticSlot完成所有指標(biāo)統(tǒng)計(jì)比如請(qǐng)求總數(shù)、成功數(shù)、失敗數(shù)、RT并觸發(fā)后續(xù)規(guī)則判斷AuthoritySlot黑白名單判斷校驗(yàn)調(diào)用來源是否被允許SystemSlot系統(tǒng)負(fù)載保護(hù)超過系統(tǒng)閾值直接攔截FlowSlot流量控制規(guī)則校驗(yàn)DegradeSlot熔斷降級(jí)規(guī)則校驗(yàn)這套設(shè)計(jì)借鑒了 Web 應(yīng)用里常見過濾器鏈的思路。每次調(diào)用依次經(jīng)過這些 slot每個(gè) slot 只關(guān)心自己負(fù)責(zé)的邏輯。以流控規(guī)則為例StatisticSlot 先把本次請(qǐng)求記錄到統(tǒng)計(jì)結(jié)構(gòu)里然后 FlowSlot 讀流控規(guī)則看當(dāng)前統(tǒng)計(jì)值是否已經(jīng)超過閾值。一旦超過就直接拋出限流異常后面的業(yè)務(wù)代碼就不會(huì)執(zhí)行了。理解這條鏈還有個(gè)好處就是知道 Sentinel 的擴(kuò)展點(diǎn)在哪。官方允許你插入自定義 slot通過實(shí)現(xiàn)ProcessorSlot接口再替換SlotChainBuilder來追加自己的處理邏輯。這樣你可以在不改變原有規(guī)則的前提下加入自定義的攔截邏輯比如做灰度放行、自定義優(yōu)先級(jí)排隊(duì)。鏈本身是每個(gè)資源單獨(dú)構(gòu)建的內(nèi)部會(huì)緩存復(fù)用不會(huì)每次請(qǐng)求都重新創(chuàng)建。這也是 Sentinel 能夠保持低開銷的關(guān)鍵之一。3.2 滑動(dòng)窗口如何統(tǒng)計(jì) QPS搞清楚 QPS 是怎么算出來的是理解限流閾值的關(guān)鍵。很多人在寫限流時(shí)下意識(shí)用“固定一秒”的計(jì)數(shù)但固定時(shí)間窗口有一個(gè)問題如果 0.9 秒時(shí)來了 100 個(gè)請(qǐng)求下一秒剛開始又來了 100 個(gè)請(qǐng)求這兩個(gè)窗口單獨(dú)看都沒超閾值但零點(diǎn)幾秒內(nèi)的瞬時(shí)請(qǐng)求其實(shí)是 200 個(gè)能把服務(wù)瞬間打沒。Sentinel 用的是滑動(dòng)窗口。它把時(shí)間切成一格一格的“槽”每個(gè)槽記錄這個(gè)小時(shí)間段內(nèi)的計(jì)數(shù)統(tǒng)計(jì)當(dāng)前時(shí)間點(diǎn)往前推一個(gè)完整窗口的總和。舉個(gè)例子默認(rèn)配置下 1 秒被分成 2 個(gè)槽每個(gè)槽記錄 500ms 的數(shù)據(jù)。當(dāng)前時(shí)間落在哪個(gè)槽就更新哪個(gè)槽窗口滑動(dòng)時(shí)早于當(dāng)前時(shí)間窗口的數(shù)據(jù)會(huì)被自動(dòng)丟掉。這樣統(tǒng)計(jì)出來的 QPS 更貼近真實(shí)瞬時(shí)流量不會(huì)出現(xiàn)固定窗口那種跨邊界突刺。在實(shí)現(xiàn)層面這一套數(shù)據(jù)結(jié)構(gòu)叫LeapArray底層是一個(gè)環(huán)形數(shù)組。數(shù)組里的每個(gè)槽維護(hù)一個(gè)MetricBucket里面存放著各種計(jì)數(shù)指標(biāo)。因?yàn)榻y(tǒng)計(jì)操作非常高頻Sentinel 在底層用了一些無鎖化和原子類的技巧來減少并發(fā)沖突這也是它能在高并發(fā)下保持穩(wěn)定性能的原因。你需要記得的關(guān)鍵點(diǎn)Sentinel 統(tǒng)計(jì)窗口本身也可以通過配置調(diào)整。默認(rèn)是 1 秒窗口對(duì)常規(guī)場景足夠了如果你的服務(wù)要求更精細(xì)的統(tǒng)計(jì)可以把窗口切小但代價(jià)是統(tǒng)計(jì)數(shù)據(jù)結(jié)構(gòu)占用更多內(nèi)存。我在調(diào)優(yōu)時(shí)一般不會(huì)輕易動(dòng)這個(gè)參數(shù)除非壓測發(fā)現(xiàn)有明顯的窗口邊緣誤判。3.3 熔斷降級(jí)的狀態(tài)機(jī)實(shí)現(xiàn)流量控制看統(tǒng)計(jì)窗口熔斷降級(jí)看的是狀態(tài)機(jī)。Sentinel 的熔斷邏輯圍繞三種狀態(tài)轉(zhuǎn)換CLOSED熔斷關(guān)閉請(qǐng)求正常放行。OPEN熔斷開啟所有請(qǐng)求都會(huì)被快速拒絕。HALF_OPEN半開狀態(tài)允許少量探測請(qǐng)求通過用探測結(jié)果決定是恢復(fù)關(guān)閉還是繼續(xù)保持熔斷。狀態(tài)流轉(zhuǎn)是這樣的初始是 CLOSED當(dāng)熔斷策略的指標(biāo)超過閾值時(shí)狀態(tài)進(jìn)入 OPENOPEN 狀態(tài)會(huì)持續(xù)一個(gè)時(shí)間窗口這個(gè)窗口時(shí)間由timeWindow參數(shù)控制窗口到了之后不直接回到 CLOSED而是先進(jìn)入 HALF_OPEN放幾個(gè)請(qǐng)求去試探下游是否已經(jīng)恢復(fù)如果試探成功狀態(tài)轉(zhuǎn)回 CLOSED重新正常放流如果試探還是失敗則立刻打回 OPEN繼續(xù)熔斷等待下一次嘗試。這套狀態(tài)機(jī)的價(jià)值在于“試探”。熔斷不是一刀切永久拒絕而是給下游恢復(fù)留出通道。生產(chǎn)環(huán)境里一個(gè)常見錯(cuò)誤是把timeWindow設(shè)置得太短比如 5 秒下游數(shù)據(jù)庫還在重啟半開試探立刻失敗又被打回 OPEN往復(fù)幾次后效果不好設(shè)置太長又會(huì)造成長時(shí)間的無效拒絕。我的經(jīng)驗(yàn)是結(jié)合依賴方實(shí)際的恢復(fù)速度來設(shè)置通常 30 秒起步寧可長一些也不要頻繁在半開狀態(tài)間震蕩。4. 規(guī)則配置細(xì)節(jié)與參數(shù)調(diào)優(yōu)控制臺(tái)上填幾個(gè)數(shù)字很容易但每個(gè)數(shù)字背后的含義和組合效果才是重點(diǎn)。這一節(jié)會(huì)把主流規(guī)則類型的關(guān)鍵參數(shù)拆開。4.1 流量控制規(guī)則的關(guān)鍵參數(shù)流量控制規(guī)則最基礎(chǔ)的配置里有這么幾個(gè)參數(shù)參數(shù)含義取值說明resource資源名和埋點(diǎn)名稱完全一致grade閾值類型0 表示 QPS1 表示并發(fā)線程數(shù)count閾值達(dá)到這個(gè)值就觸發(fā)限流strategy流控策略0 表示直接基于資源自身1 表示關(guān)聯(lián)資源2 表示鏈路controlBehavior流控效果0 快速失敗1 預(yù)熱2 勻速排隊(duì)大多數(shù)場景直接用 QPS 閾值就夠了也就是把grade設(shè)為 0。但有一種情況我建議用并發(fā)線程數(shù)就是你的接口內(nèi)部阻塞較多、連接池有限、單個(gè)請(qǐng)求耗時(shí)很長。這時(shí)候 QPS 限流會(huì)掩蓋“同時(shí)占用線程過多”的真實(shí)風(fēng)險(xiǎn)改用并發(fā)線程數(shù)限制反而更穩(wěn)。再單獨(dú)說controlBehavior?？焖偈∽畋┝Φ珪?huì)把超出的請(qǐng)求一瞬間全部拒絕對(duì)用戶不友好預(yù)熱模式適合系統(tǒng)剛啟動(dòng)、或者規(guī)則閾值長期較低的場景——它允許流量在設(shè)定的預(yù)熱時(shí)間內(nèi)緩慢爬升到目標(biāo)閾值而不是一上線就滿負(fù)荷放行勻速排隊(duì)則適合有任務(wù)堆積場景的削峰填谷請(qǐng)求排成隊(duì)列勻速通過而不是集中爆發(fā)。我自己在秒殺系統(tǒng)里用得最多的是預(yù)熱勻速排隊(duì)組合既能保住后端又不會(huì)把用戶體驗(yàn)全砍掉。4.2 熔斷規(guī)則的閾值設(shè)置技巧熔斷規(guī)則在配置時(shí)有三種策略慢調(diào)用比例、異常比例、異常數(shù)。官方不同版本的參數(shù)名有差異我以當(dāng)前主流版本的習(xí)慣寫法來說明DegradeRule rule new DegradeRule(); rule.setResource(/api/pay/callback); // 慢調(diào)用比例策略RT 超過 500ms 算慢調(diào)用 rule.setGrade(CircuitBreakingStrategy.SLOW_REQUEST_RATIO); rule.setCount(500); rule.setTimeWindow(30); rule.setStatIntervalMs(10000); // 10 秒內(nèi)至少 5 個(gè)請(qǐng)求時(shí)才開始判斷 rule.setMinRequestAmount(5); // 慢調(diào)用占比超過 80% 就熔斷 rule.setSlowRatioThreshold(0.8);這里有一個(gè)新手常犯的錯(cuò)誤直接把count當(dāng)成平均響應(yīng)時(shí)間閾值來填。SLOW_REQUEST_RATIO 策略下count表示“響應(yīng)時(shí)間超過多少毫秒算慢調(diào)用”而不是“平均 RT 超過多少就熔斷”。兩者的差別很大。慢調(diào)用比例更科學(xué)因?yàn)槠骄?RT 容易被極端值拉高只要少數(shù)請(qǐng)求特別慢就會(huì)觸發(fā)誤判。異常比例和異常數(shù)則適合那些錯(cuò)誤率明顯代表下游故障的場景。但要注意這里統(tǒng)計(jì)的是業(yè)務(wù)代碼拋出的異常如果你在業(yè)務(wù)邏輯里大量使用 try-catch 把異常吞掉或者對(duì)外層錯(cuò)誤做了包裝統(tǒng)計(jì)到的異常數(shù)就是包裝后的數(shù)量規(guī)則效果可能會(huì)失真。熔斷規(guī)則配置時(shí)還要注意minRequestAmount。它的作用是避免“樣本太少誤判”。比如一個(gè)接口剛上線只在 3 個(gè)請(qǐng)求里失敗了 2 次異常比例就到 66%如果沒設(shè)置最小請(qǐng)求數(shù)可能瞬間就被熔斷。我一般要求團(tuán)隊(duì)在多數(shù)場景下把這個(gè)值設(shè)為至少 5 到 10。4.3 系統(tǒng)保護(hù)與熱點(diǎn)參數(shù)規(guī)則系統(tǒng)規(guī)則和前面幾種規(guī)則不同它不針對(duì)某個(gè)具體資源而是對(duì)整個(gè)系統(tǒng)的入口流量做保護(hù)。你可以設(shè)定一個(gè)負(fù)載閾值當(dāng)系統(tǒng)負(fù)載超過這個(gè)值就開始限制入口請(qǐng)求。這種規(guī)則適合應(yīng)對(duì)“服務(wù)整體過載”的場景因?yàn)樗吹牟皇悄硞€(gè)接口的指標(biāo)而是整個(gè)機(jī)器的健康度。配置時(shí)一般從 JVM 參數(shù)或者控制臺(tái)讀取系統(tǒng)指標(biāo)再和預(yù)設(shè)閾值比較。熱點(diǎn)參數(shù)限流則非常適合常見的“單點(diǎn)熱點(diǎn)”場景。比如一個(gè)商品詳情接口總 QPS 可能沒超過整體閾值但某個(gè)爆款商品的 QPS 單獨(dú)很高。這時(shí)普通流量規(guī)則攔不住因?yàn)榭偭繘]超。熱點(diǎn)規(guī)則可以針對(duì)參數(shù)值單獨(dú)限流參數(shù) id 等于 9527 時(shí)每秒只允許 100 個(gè)請(qǐng)求其他參數(shù)值按默認(rèn)總閾值走。配置時(shí)通常要指定參數(shù)索引和第幾位的參數(shù)這里最容易踩的坑是參數(shù)索引寫錯(cuò)比如方法首參是userId次參是goodsId你要對(duì)商品限流就必須把索引配成 1而不是 0。5. 常見問題與排障經(jīng)驗(yàn)實(shí)錄配置和原理都聊完了最后一節(jié)是我在落地過程中真正遇到過的疑難雜癥。這些坑在官方文檔里不會(huì)寫太細(xì)但遇到了非常耗時(shí)。5.1 規(guī)則不生效的排查路線規(guī)則配置后界面上也顯示成功了流量打上去就是不被限流。遇到這種情況我一般按下面的順序排查。先看資源名是否完全一致。前面提到過手動(dòng)埋點(diǎn)SphU.entry(/api/order/create)和注解SentinelResource(value createOrder)寫出的資源名只要有一點(diǎn)不一致規(guī)則就關(guān)聯(lián)不上。這一步是最常見的根因。再看當(dāng)前應(yīng)用是否成功接入了控制臺(tái)。進(jìn)控制臺(tái)“簇點(diǎn)鏈路”頁找到對(duì)應(yīng)資源確認(rèn)已經(jīng)能看到實(shí)時(shí)的請(qǐng)求數(shù)和指標(biāo)。如果資源根本不出現(xiàn)在鏈路里說明埋點(diǎn)本身有問題規(guī)則自然無效。還要看統(tǒng)計(jì)采樣。默認(rèn)規(guī)則只在統(tǒng)計(jì)滑窗內(nèi)有數(shù)據(jù)時(shí)才參與判斷。如果你設(shè)置了minRequestAmount或類似的閾值而當(dāng)前請(qǐng)求樣本太少即使流量看起來超了也不會(huì)觸發(fā)。很多人在壓測時(shí)發(fā)現(xiàn)前幾秒規(guī)則不生效其實(shí)是因?yàn)闃颖緮?shù)還沒達(dá)到最低判定要求。最后看是否并發(fā)到達(dá)。QPS 限流判斷的是滑動(dòng)窗口內(nèi)統(tǒng)計(jì)出來的速率如果你用線程并發(fā)數(shù)模式那要看的是“當(dāng)前占用線程數(shù)”兩者表現(xiàn)完全不同。改規(guī)則前先確認(rèn)自己用的哪個(gè)模式別拿 QPS 的預(yù)期去解釋線程數(shù)的現(xiàn)象。5.2 控制臺(tái)數(shù)據(jù)不刷新或看不到服務(wù)控制臺(tái)列表里遲遲看不到客戶端或者看到之后指標(biāo)曲線死的一般不動(dòng)我通常會(huì)先排查客戶端到控制臺(tái)的網(wǎng)絡(luò)連通性。Sentinel 的 dashboard 通信走的是 HTTP 接口如果中間有防火墻或者端口沒放開數(shù)據(jù)就傳不過來。然后看客戶端的project.name和dashboard.server參數(shù)是否真實(shí)生效。Spring Boot 應(yīng)用在引入相關(guān)依賴后可能會(huì)自動(dòng)注入?yún)?shù)但如果你同時(shí)指定了配置文件里的對(duì)應(yīng)項(xiàng)兩邊不一致時(shí)容易讓人困惑。啟動(dòng)時(shí)加-Dcsp.sentinel.dashboard.server...是最直接的方式。還有一個(gè)環(huán)境相關(guān)的問題服務(wù)實(shí)例注冊到控制臺(tái)會(huì)有一定的延遲并不是啟動(dòng)后立即出現(xiàn)。正常情況大約需要等 10 到 30 秒。如果等了很久還是沒有去看客戶端在logs/csp目錄下生成的sentinel-record.log里面會(huì)明確記錄注冊過程和報(bào)錯(cuò)信息。5.3 高并發(fā)下的性能損耗與取舍另一個(gè)大家最關(guān)心的問題是Sentinel 本身會(huì)吃掉多少性能從我的壓測經(jīng)驗(yàn)看常規(guī)的限流判斷在每請(qǐng)求上增加的耗時(shí)非常低通常在大幾十微秒到一百多微秒這個(gè)量級(jí)主要影響不是 CPU而是業(yè)務(wù)代碼里多了一次資源的 entry/exit 調(diào)用和統(tǒng)計(jì)更新。對(duì)于絕大多數(shù)業(yè)務(wù)系統(tǒng)這個(gè)開銷可以接受。但如果你的接口本身就是超高頻調(diào)用比如單機(jī)每秒幾萬次又想同時(shí)開啟多種規(guī)則那就要關(guān)注幾個(gè)點(diǎn)一是把不必要的規(guī)則類型關(guān)掉只保留必需的二是合理控制統(tǒng)計(jì)窗口和滑窗粒度三是避免在兜底邏輯里做耗時(shí)操作。兜底方法里如果做了遠(yuǎn)程調(diào)用或者復(fù)雜計(jì)算這個(gè)開銷反而容易掩蓋 Sentinel 本身的性能表現(xiàn)。壓測時(shí)建議單獨(dú)測兩種狀態(tài)一種是不接入 Sentinel 的裸接口性能一種是開啟限流規(guī)則后的性能。兩者對(duì)比你才能真正知道規(guī)則疊加帶來的成本而不是憑感覺懷疑它。使用 Sentinel 一年多之后我最大的感受是這類組件的難點(diǎn)不在于“怎么配置”而在于你是否真正理解流量和依賴之間的因果關(guān)系。配置只是一個(gè)出口背后的滑動(dòng)窗口、責(zé)任鏈、熔斷狀態(tài)機(jī)才是決定規(guī)則是否合理的地基。每次上線新業(yè)務(wù)、每次壓測調(diào)優(yōu)我都會(huì)回到控制臺(tái)重新看一遍資源名、閾值和規(guī)則之間的對(duì)應(yīng)關(guān)系而不是只看那一兩條報(bào)警。希望這篇文章里那些踩過的坑和調(diào)參的思路能幫你少走一段彎路。