Sentinel 系統(tǒng)規(guī)則實(shí)戰(zhàn)讓 JVM 的 CPU 使用率直接參與限流決策先扯個(gè)實(shí)際場景。你有沒有遇到過這種詭異情況線上服務(wù) QPS 明明還在可接受范圍接口 RT 卻開始直線飆高緊接著整個(gè)應(yīng)用像被什么東西掐住脖子一樣卡頓、超時(shí)、批量報(bào)錯(cuò)最后連著數(shù)據(jù)庫一起拖垮。我早期做高并發(fā)服務(wù)時(shí)就栽過一回流量洪峰到來前業(yè)務(wù)團(tuán)隊(duì)粗估了一個(gè) QPS 閾值辛辛苦苦配好了單機(jī)限流結(jié)果流量真的沖上來時(shí)單機(jī) QPS 還沒到預(yù)設(shè)值機(jī)器 CPU 先被打滿了限流規(guī)則根本沒機(jī)會(huì)觸發(fā)服務(wù)照樣雪崩。這事逼著我重新想一個(gè)問題限流到底應(yīng)該限什么是數(shù)字上的 QPS還是背后真正決定系統(tǒng)吞吐能力的資源后來我把目光放到了阿里開源的 Sentinel 上。Sentinel 的系統(tǒng)規(guī)則不按調(diào)用次數(shù)卡你而是直接盯 JVM 所在節(jié)點(diǎn)的系統(tǒng)負(fù)載、CPU 使用率這類硬指標(biāo)把限流決策和機(jī)器真實(shí)狀態(tài)綁在一起。今天這篇就圍繞“Sentinel 系統(tǒng)規(guī)則 JVM 指標(biāo)聯(lián)動(dòng)靠 CPU 使用率觸發(fā)限流”展開把原理、配置、實(shí)戰(zhàn)參數(shù)、踩坑記錄全盤托出。適合正在用 Sentinel 做服務(wù)保護(hù)、但對系統(tǒng)規(guī)則模塊還不太熟的讀者也適合那些和我一樣被“誤傷型限流”坑過的同學(xué)。1. 系統(tǒng)規(guī)則的核心思路為什么不用固定 QPS反而盯 CPU1.1 單機(jī) QPS 限流的局限在哪里先拆一下固定 QPS 限流的邏輯。它的核心假設(shè)是單機(jī)能扛 2000 QPS超過就攔。這個(gè)假設(shè)有兩個(gè)脆弱點(diǎn)。第一QPS 閾值是拍腦袋定的。上線前壓測得出 2000 QPS上線后業(yè)務(wù)代碼加了一段耗時(shí)邏輯或者 JVM 堆內(nèi)存調(diào)小了實(shí)際扛 1500 QPS 就喘不過氣。你原來的 2000 閾值不但沒保護(hù)服務(wù)反而成了幫兇因?yàn)檎埱蠓胚M(jìn)來之后線程在瘋狂堆積RT 指數(shù)級惡化這就是經(jīng)典的請求堆積 → 線程饑餓 → 服務(wù)假死鏈路。第二固定 QPS 限流只能看到調(diào)用量看不到系統(tǒng)真實(shí)健康度。舉個(gè)極端例子一個(gè)接口 CPU 密集計(jì)算 50ms另一個(gè)接口只查了一次緩存耗時(shí) 2ms。兩個(gè)接口配同樣的 QPS 閾值顯然不合理但如果分別配又很難預(yù)先算準(zhǔn)每種業(yè)務(wù)的資源開銷。所以固定 QPS 本質(zhì)上是“以預(yù)測代替感知”而分布式系統(tǒng)的突發(fā)負(fù)載、Full GC、宿主機(jī)搶占都不是你提前能預(yù)測準(zhǔn)的。這也是我后來堅(jiān)定轉(zhuǎn)向系統(tǒng)規(guī)則的原因——它不做預(yù)測只做響應(yīng)。1.2 系統(tǒng)規(guī)則的運(yùn)行邏輯自適應(yīng)保護(hù)Sentinel 的系統(tǒng)規(guī)則官方叫 SystemRule核心思想是讓入口流量自適應(yīng)系統(tǒng)承載能力。它的保護(hù)對象是整臺 JVM 所在的機(jī)器節(jié)點(diǎn)不是某個(gè)接口。具體實(shí)現(xiàn)上Sentinel 會(huì)周期性采樣當(dāng)前系統(tǒng)的幾個(gè)核心指標(biāo)指標(biāo)說明觸發(fā)保護(hù)的動(dòng)作系統(tǒng)負(fù)載Load基于操作系統(tǒng) 1 分鐘負(fù)載平均值做 BBR 風(fēng)格換算根據(jù)系統(tǒng)負(fù)載和當(dāng)前 RT 計(jì)算最大允許 QPS超出即攔截CPU 使用率本機(jī)所有核心的平均使用率不是單個(gè)進(jìn)程的超過閾值后拒絕所有新請求進(jìn)入RT所有入口流量的平均響應(yīng)時(shí)間超過閾值后拒絕新請求線程數(shù)入口流量的并發(fā)線程數(shù)超過閾值后拒絕新請求入口 QPS所有入口流量的聚合 QPS一般配合負(fù)載策略使用注意上表里兩個(gè)容易混淆的點(diǎn)。一是 CPU 使用率指標(biāo)和系統(tǒng)負(fù)載指標(biāo)是兩套獨(dú)立邏輯CPU 使用率一旦超閾值是直接把后續(xù)請求全部拒絕根本沒有協(xié)商余地系統(tǒng)負(fù)載則是動(dòng)態(tài)調(diào)整入口 QPS負(fù)載越高允許進(jìn)來的請求越少控制更柔和。二是 CPU 使用率采樣的是整個(gè)操作系統(tǒng)層面不是 JVM 進(jìn)程本身。這點(diǎn)后面還會(huì)展開講它直接影響你的規(guī)則能不能觸發(fā)。1.3 系統(tǒng)規(guī)則的代碼結(jié)構(gòu)看一眼核心類你會(huì)更清楚它的運(yùn)作方式。Sentinel 里系統(tǒng)規(guī)則入口是SystemRuleManager它內(nèi)部有個(gè)定時(shí)任務(wù)默認(rèn)每秒執(zhí)行一次采樣。// Sentinel 核心系統(tǒng)狀態(tài)采樣與規(guī)則檢查入口 public class SystemRuleManager { // 負(fù)載閾值-1 表示不限制 private static double highestSystemLoad Double.MAX_VALUE; // CPU 使用率閾值-1 表示不限制 private static double highestCpuUsage Double.MAX_VALUE; // 定時(shí)采樣任務(wù)線程池固定頻率執(zhí)行 static { ScheduledExecutorService scheduler Executors.newScheduledThreadPool(1); scheduler.scheduleAtFixedRate(() - { try { currentSystemLoad SystemStatusListener.getSystemLoad(); currentCpuUsage SystemStatusListener.getCpuUsage(); // 計(jì)算當(dāng)前允許的最大入口 QPS calculateAllowedQps(); } catch (Throwable e) { RecordLog.warn([SystemRuleManager] Error when computing system metrics, e); } }, 1, 1, TimeUnit.SECONDS); } }這個(gè)定時(shí)任務(wù)會(huì)刷新維護(hù)一個(gè)SystemMetric對象里面保存著當(dāng)前負(fù)載、CPU、RT、線程數(shù)。每個(gè)請求進(jìn)入 Sentinel 的 slot 鏈路時(shí)SystemSlot會(huì)讀取這些指標(biāo)和規(guī)則閾值比較決定放行還是拒絕。整個(gè)鏈路是典型的“異步采樣 同步判斷”實(shí)時(shí)性依賴采樣頻率這也是后面排查問題時(shí)一個(gè)關(guān)鍵切入點(diǎn)。2. 核心實(shí)操CPU 閾值與負(fù)載參數(shù)的配置全流程2.1 系統(tǒng)規(guī)則有哪些參數(shù)該怎么定初始值我直接給你一套我在生產(chǎn)環(huán)境驗(yàn)證過的基礎(chǔ)配置思路。參數(shù)配置入口我的生產(chǎn)建議備注CPU 使用率閾值SystemRule的highestCpuUsage80%85%超過后直接拒絕所有新請求系統(tǒng)負(fù)載閾值SystemRule的highestSystemLoad等于 CPU 核心數(shù)如 4 核設(shè) 4.0動(dòng)態(tài)調(diào)整入口 QPS平均 RT 閾值SystemRule的avgRt根據(jù)業(yè)務(wù)壓測結(jié)果比如 300ms超過后拒絕新請求線程數(shù)閾值SystemRule的maxThread核心線程數(shù) * 2 附近防線程堆積為什么 CPU 使用率閾值選 80%85%因?yàn)?CPU 超過這個(gè)值后系統(tǒng)可能還有一點(diǎn)緩沖余量但 RT 已經(jīng)開始出現(xiàn)明顯毛刺。如果設(shè)到 95%設(shè)備長時(shí)間滿負(fù)荷運(yùn)行JVM 的 GC 線程和業(yè)務(wù)線程互相搶 CPU服務(wù)已經(jīng)處在崩潰邊緣保護(hù)動(dòng)作來得太晚。如果設(shè)到 50%機(jī)器經(jīng)常因?yàn)橐淮尾凰銍?yán)重的毛刺就整體拒絕流量可用性受損。系統(tǒng)負(fù)載閾值我建議直接等于 CPU 核心數(shù)。這里需要解釋一下“系統(tǒng)負(fù)載”和 CPU 使用率的區(qū)別。系統(tǒng)負(fù)載是“當(dāng)前正在運(yùn)行 等待 CPU 的線程平均數(shù)量”4 核機(jī)器負(fù)載 4.0意味著每個(gè)核正好有一個(gè)任務(wù)在跑CPU 接近飽和但還沒過載。負(fù)載超過核心數(shù)說明有線程在排隊(duì)這時(shí)候再繼續(xù)放流量進(jìn)來排隊(duì)只會(huì)越來越嚴(yán)重。2.2 Sentinel 的負(fù)載閾值是怎么換算成 QPS 的這里值得多說一句因?yàn)楹芏嗳伺渲猛曦?fù)載閾值后發(fā)現(xiàn)實(shí)際生效的 QPS 數(shù)字和預(yù)期完全對不上。Sentinel 沒有拿負(fù)載閾值直接限流它參考了 TCP BBR 的帶寬延遲積思想做了一個(gè)換算公式。核心邏輯是當(dāng)前系統(tǒng)能承受的最大 QPS約等于“并發(fā)線程數(shù)當(dāng)前值 / 平均 RT”。我拆解一下這個(gè)過程。Sentinel 在DefaultNode里維護(hù)了入口流量的統(tǒng)計(jì)包含當(dāng)前并發(fā)線程數(shù)curThreadNum和平均 RT。系統(tǒng)負(fù)載超過閾值后它按 BBR 風(fēng)格帶寬評估公式計(jì)算出一個(gè)新的最大 QPSprivate static double calculateAllowedQps() { double avgRt SystemStatusListener.getCurrentMetric().avgRt(); double maxQps maxThread / avgRt; // 再根據(jù)當(dāng)前負(fù)載和臨界負(fù)載的比例做平滑調(diào)整 return maxQps * (highestSystemLoad / currentSystemLoad); }簡單理解就是系統(tǒng)負(fù)載越高可放行的 QPS 越低但不是直接跌到 0而是按比例平滑下降。這個(gè)設(shè)計(jì)比一刀切拒絕要合理得多能消化掉一些突發(fā)毛刺又不至于把系統(tǒng)壓垮。所以你在配置負(fù)載規(guī)則時(shí)心里要有個(gè)預(yù)期規(guī)則控制的不是某個(gè)固定 QPS 數(shù)值而是一條動(dòng)態(tài)曲線它會(huì)根據(jù) RT 和線程數(shù)實(shí)時(shí)變化。如果接口 RT 漲了一倍系統(tǒng)允許進(jìn)入的 QPS 自動(dòng)減半這是自適應(yīng)保護(hù)最明顯的價(jià)值。2.3 實(shí)操三種方式配置系統(tǒng)規(guī)則方式一硬編碼適合測試環(huán)境和快速驗(yàn)證。// 加載系統(tǒng)規(guī)則以下參數(shù)按實(shí)際機(jī)器配置調(diào)整 private void initSystemRule() { SystemRule rule new SystemRule(); rule.setHighestCpuUsage(0.85); // CPU 使用率閾值 85% rule.setHighestSystemLoad(4.0); // 4 核機(jī)器負(fù)載閾值 4.0 rule.setAvgRt(300); // 平均 RT 閾值 300ms rule.setMaxThread(16); // 最大并發(fā)線程數(shù) 16 SystemRuleManager.loadRules(Collections.singletonList(rule)); }方式二通過控制臺動(dòng)態(tài)推送。在 Sentinel 控制臺的“系統(tǒng)規(guī)則”菜單里新增填好閾值后直接發(fā)布。這種方式適合生產(chǎn)環(huán)境動(dòng)態(tài)調(diào)整但要注意控制臺版本和服務(wù)端版本要匹配否則推送不生效。方式三通過FlowRule的grade參數(shù)指定為RuleConstant.SYSTEM_LOAD或RuleConstant.SYSTEM_CPU在流控規(guī)則里單獨(dú)配置 CPU 維度。這種方式相對少見但從命名上能看出 Sentinel 把系統(tǒng)保護(hù)規(guī)則也納入到了統(tǒng)一規(guī)則體系里。我實(shí)踐下來最推薦的方式是代碼初始化兜底 控制臺動(dòng)態(tài)調(diào)參。代碼里寫一套保守閾值做啟動(dòng)保護(hù)控制臺再根據(jù)壓測數(shù)據(jù)調(diào)優(yōu)到合理值。不然線上機(jī)器配置變更或者業(yè)務(wù)擴(kuò)容后硬編碼的閾值就成了定時(shí)炸彈。2.4 如何驗(yàn)證規(guī)則真的生效了配置完了不代表它就會(huì)按下你想象的方式工作。我見過不少人配完規(guī)則壓測半天沒觸發(fā)懷疑規(guī)則沒用。其實(shí)很大概率是壓測姿勢不對。驗(yàn)證要分三步走。第一步確認(rèn)機(jī)器的 CPU 使用率確實(shí)能通過 Sentinel 采集到。打開日志看sentinel-record.log里面會(huì)周期性打印系統(tǒng)指標(biāo)采樣值確認(rèn)不是 0也不是空。第二步制造壓力。用壓測工具我常用 wrk 或 JMeter直接打入口服務(wù)觀察控制臺或日志里有沒有出現(xiàn)一個(gè)關(guān)鍵日志[Sentinel] Blocked by system protection: SystemRule或類似字樣。只要出現(xiàn)這條日志說明系統(tǒng)規(guī)則真正參與攔截了。第三步驗(yàn)證恢復(fù)。停掉壓測流量觀察系統(tǒng)指標(biāo)回落后請求是否自動(dòng)恢復(fù)放行。有時(shí)候規(guī)則觸發(fā)后一直不恢復(fù)多半是采樣線程被 GC 或線程池饑餓影響了這個(gè)后面排查章節(jié)會(huì)細(xì)說。3. JVM 指標(biāo)聯(lián)動(dòng)的進(jìn)階玩法不只盯 CPU 使用率還要看 GC 和內(nèi)存標(biāo)題里專門提到“JVM 指標(biāo)聯(lián)動(dòng)”很多人會(huì)理解為直接讀取 JVM 的 CPU 使用率。但實(shí)際做生產(chǎn)監(jiān)控時(shí)我會(huì)把聯(lián)動(dòng)拆成兩個(gè)層面一是 CPU 使用率觸發(fā)的剛性攔截一是 JVM 內(nèi)部指標(biāo)Full GC 頻次、堆內(nèi)存占用、線程數(shù)對閾值調(diào)整的柔性修正。這兩個(gè)結(jié)合起來才是完整的“系統(tǒng)規(guī)則 JVM 指標(biāo)聯(lián)動(dòng)”。3.1 為什么 CPU 使用率高時(shí)先要看是不是 Full GC 在搗鬼有一次線上服務(wù) CPU 使用率飆到 90% 以上系統(tǒng)規(guī)則觸發(fā)后大量請求被攔截但業(yè)務(wù)團(tuán)隊(duì)說沒看到明顯的流量增長。最后查了半天是堆內(nèi)存里有一個(gè)本地緩存實(shí)現(xiàn)有誤數(shù)據(jù)無限增長導(dǎo)致 Full GC 頻繁觸發(fā)。Full GC 是多線程并行回收階段會(huì)吃滿所有 CPU 核心表現(xiàn)為“系統(tǒng)負(fù)載高、CPU 使用率高”而業(yè)務(wù)線程其實(shí)沒有干多少活。這個(gè)案例說明CPU 使用率高只是一個(gè)結(jié)果不一定是業(yè)務(wù)流量導(dǎo)致的。如果直接把 CPU 閾值當(dāng)成唯一限流依據(jù)那么一次頻繁的 GC 就會(huì)引發(fā)全站“無差別限流”甚至把正常流量也擋在門外。所以我在實(shí)踐里會(huì)做一層過濾當(dāng) CPU 使用率觸發(fā)系統(tǒng)規(guī)則后先通過 JMX 拉取 JVM 的 GC 頻次數(shù)據(jù)判斷 CPU 是被業(yè)務(wù)線程消耗還是被 GC 線程消耗。// 通過 JMX 獲取 Full GC 次數(shù)輔助判斷 CPU 飆高的原因 public long getFullGcCount() { ListGarbageCollectorMXBean gcBeans ManagementFactory.getGarbageCollectorMXBeans(); long fullGcCount 0L; for (GarbageCollectorMXBean bean : gcBeans) { // 老年代回收器名稱通常包含 Old 或 MarkSweep if (bean.getName().contains(Old) || bean.getName().contains(MarkSweep)) { fullGcCount bean.getCollectionCount(); } } return fullGcCount; }完整的決策邏輯是這樣的CPU 使用率觸發(fā)限流 → 檢查 Full GC 頻次是否在短時(shí)間內(nèi)大幅上升 → 如果是說明系統(tǒng)進(jìn)入“GC 抖動(dòng)狀態(tài)”此時(shí)不應(yīng)該簡單拒絕所有請求因?yàn)榱髁勘旧頉]有超載真正的問題是內(nèi)存或 GC 參數(shù)不合理。這時(shí)候最優(yōu)動(dòng)作是保底攔截一部分請求給 GC 喘息時(shí)間同時(shí)觸發(fā)內(nèi)存 dump 或擴(kuò)容而不是讓正常用戶在無感知情況下全部被攔截。3.2 聯(lián)動(dòng)方案一根據(jù) JVM 指標(biāo)動(dòng)態(tài)調(diào)整系統(tǒng)規(guī)則閾值系統(tǒng)規(guī)則的閾值不應(yīng)該是靜態(tài)寫死的。我基于 Spring Boot 的Scheduled任務(wù)做過一個(gè)動(dòng)態(tài)修正器每 10 秒采集一次 JVM GC 和內(nèi)存指標(biāo)動(dòng)態(tài)調(diào)整 Sentinel 的 CPU 閾值。核心思路是正常情況下 CPU 閾值保持 85%如果監(jiān)測到 Full GC 頻繁自動(dòng)把 CPU 閾值下調(diào)到 70%讓系統(tǒng)更早進(jìn)入保護(hù)狀態(tài)減少因 GC 造成的請求堆積。Component public class SentinelDynamicRuleAdjuster { private static final double DEFAULT_CPU_THRESHOLD 0.85; private static final double GC_PRESSURE_CPU_THRESHOLD 0.70; Scheduled(fixedDelay 10000) public void adjustSystemRule() { long currentFullGcCount getFullGcCount(); long delta currentFullGcCount - lastFullGcCount; // 10 秒內(nèi)超過 2 次 Full GC認(rèn)為 GC 壓力大 if (delta 2) { updateCpuThreshold(GC_PRESSURE_CPU_THRESHOLD); } else { updateCpuThreshold(DEFAULT_CPU_THRESHOLD); } lastFullGcCount currentFullGcCount; } }這么做的好處是把“限流保護(hù)”和“系統(tǒng)自治”綁在了一起。流量高峰時(shí) CPU 超過 85%限流先兜住JVM 內(nèi)存異常時(shí) GC 頻繁閾值自動(dòng)前移到 70%兜得更早。兩條防線互相配合而不是只靠一個(gè)靜態(tài)閾值硬扛。3.3 聯(lián)動(dòng)方案二把 JVM 線程數(shù)指標(biāo)納入限流判斷很多人只盯著 CPU 和負(fù)載忽略了線程數(shù)。Sentinel 的線程數(shù)閾值其實(shí)是針對“入口并發(fā)線程數(shù)”的而不是 JVM 全部線程。但生產(chǎn)環(huán)境里一個(gè)比入口線程數(shù)更危險(xiǎn)的信號是 JVM 整體的活線程數(shù)逼近線程池上限。當(dāng) Tomcat 或業(yè)務(wù)線程池的線程全部處于RUNNABLE狀態(tài)并且大量阻塞在遠(yuǎn)程調(diào)用或鎖等待上時(shí)JVM 線程數(shù)這個(gè)指標(biāo)比 CPU 使用率更早反映問題。我在壓測中遇到過CPU 使用率才 40%但線程池已經(jīng)被占滿RT 狂飆此時(shí)系統(tǒng)規(guī)則根本沒觸發(fā)因?yàn)?CPU 還沒到閾值。對這種場景我把 JVM 線程數(shù)也納入聯(lián)動(dòng)判斷定期檢查ThreadMXBean.getThreadCount()如果超過預(yù)設(shè)水位比如核心線程數(shù) 150水位設(shè)在 120就自動(dòng)加載一條臨時(shí)系統(tǒng)規(guī)則把入口 QPS 壓低或者直接把線程數(shù)閾值調(diào)低。long threadCount ManagementFactory.getThreadMXBean().getThreadCount(); if (threadCount threadPoolHighWatermark) { SystemRule systemRule new SystemRule(); systemRule.setMaxThread(currentAllowedThreadCount); systemRule.setHighestCpuUsage(0.8); // 讓規(guī)則在 30 秒內(nèi)自動(dòng)過期避免長時(shí)間誤傷 SystemRuleManager.loadRules(Collections.singletonList(systemRule)); }3.4 JVM 參數(shù)調(diào)優(yōu)對系統(tǒng)規(guī)則效果的影響聊到這里必須提一嘴 JVM 參數(shù)因?yàn)楹芏嗳税l(fā)現(xiàn)系統(tǒng)規(guī)則“該觸發(fā)時(shí)沒觸發(fā)”問題不在 Sentinel而是 JVM 本身的機(jī)制掩蓋了真實(shí)壓力。以 Tomcat 啟動(dòng)設(shè)置 JVM 參數(shù)為例如果你的堆內(nèi)存和 GC 策略不合理那么系統(tǒng)在 CPU 高負(fù)載之前很早就會(huì)進(jìn)入頻繁 GC 的狀態(tài)CPU 時(shí)間大半被 GC 吃掉但 JVM 對外表現(xiàn)的 RT 可能還沒有明顯惡化。這時(shí)候系統(tǒng)規(guī)則以為系統(tǒng)“還行”等 RT 真正惡化時(shí)其實(shí)已經(jīng)晚了。我常用的生產(chǎn) JVM 參數(shù)組合是這樣-Xms4g -Xmx4g -XX:UseG1GC -XX:MaxGCPauseMillis200 -XX:HeapDumpOnOutOfMemoryError -XX:HeapDumpPath/data/logs/jvm -XX:PrintGCDetails -XX:PrintGCDateStamps -Xloggc:/data/logs/gc.log核心原則是堆內(nèi)存初始值和最大值保持一致避免運(yùn)行時(shí)動(dòng)態(tài)擴(kuò)容造成 CPU 尖峰用 G1 回收器并設(shè)置 GC 停頓目標(biāo)讓 GC 造成的 CPU 消耗可控。這幾點(diǎn)直接影響系統(tǒng)規(guī)則采樣的“體感”GC 平穩(wěn)了CPU 使用率才有資格作為限流信號。否則你限的是“GC 引發(fā)的 CPU 毛刺”而不是真正的業(yè)務(wù)負(fù)載整個(gè)聯(lián)動(dòng)邏輯就失真了。4. 常見問題排查與避坑實(shí)錄這部分全是真金白銀的踩坑記錄。我按出現(xiàn)頻率排個(gè)序把典型問題和排查思路整理成一張速查表再展開講幾個(gè)最坑的。問題現(xiàn)象可能原因排查步驟系統(tǒng)規(guī)則配置了但不生效控制臺版本不匹配未引入sentinel-parameter-flow-control或系統(tǒng)規(guī)則模塊檢查依賴查看控制臺是否展示規(guī)則用代碼加載規(guī)則做對照一臺機(jī)器限流另一臺不限流單機(jī)采樣差異宿主機(jī) CPU 爭搶負(fù)載不均衡對比各節(jié)點(diǎn)日志中的系統(tǒng)指標(biāo)檢查是否在同一宿主機(jī)CPU 閾值很明顯超了但還是放行采樣頻率是 1s秒級數(shù)據(jù)存在窗口判斷用的是上一秒指標(biāo)降低觸發(fā)窗口連續(xù)多秒超標(biāo)才攔截增強(qiáng)采樣日志觸發(fā)后不恢復(fù)采樣線程卡死GC 導(dǎo)致采樣線程調(diào)度延遲檢查 GC 日志優(yōu)化 JVM 參數(shù)確認(rèn)采樣線程優(yōu)先級控制臺推送規(guī)則成功但服務(wù)端不生效服務(wù)端未接入數(shù)據(jù)庫/配置中心推送給應(yīng)用但應(yīng)用未注冊監(jiān)聽檢查應(yīng)用側(cè)日志確認(rèn)是否包含SentinelAutoConfiguration負(fù)載閾值換算出來的 QPS 不直觀對 BBR 換算公式不理解看calculateAllowedQps邏輯在日志看動(dòng)態(tài) QPS 值4.1 系統(tǒng)規(guī)則“不生效”的經(jīng)典坑版本與控制臺不匹配這個(gè)問題排查成本最高。有些團(tuán)隊(duì)的 Sentinel 控制臺是早期版本應(yīng)用內(nèi)嵌的sentinel-core卻升級到了較新版本兩個(gè)版本之間規(guī)則推送協(xié)議不一致控制臺上配置了系統(tǒng)規(guī)則應(yīng)用端完全沒有感知。我的排查習(xí)慣是三步走。第一直接跑一個(gè)本地 Java 進(jìn)程用官方控制臺同版本對接把同樣的規(guī)則推一遍看本地是否觸發(fā)。第二檢查服務(wù)的sentinel-record.log里面有沒有Receive new config from command center之類的記錄。第三用最原始的辦法驗(yàn)證代碼里手動(dòng)寫死一條 CPU 閾值規(guī)則來測試排除一切外部依賴先確認(rèn)基礎(chǔ)鏈路通不通。4.2 CPU 使用率采集偏差別忽略宿主機(jī)的影響Sentinel 讀取 CPU 使用率是通過OperatingSystemMXBean.getSystemLoadAverage()和自定義的 CPU 采樣器來實(shí)現(xiàn)的。注意getSystemLoadAverage()返回的是系統(tǒng) 1 分鐘平均負(fù)載而 CPU 使用率是通過com.sun.management.OperatingSystemMXBean.getSystemCpuLoad()獲取。在容器化部署比如 Docker 或 K8s場景下這個(gè)采集有一個(gè)天坑容器默認(rèn)讀取的是宿主機(jī)整體 CPU 狀態(tài)。假如宿主機(jī) 32 核你的 Pod 被限制只用 2 核Pod 計(jì)算密集型業(yè)務(wù)能把 2 核打滿但getSystemCpuLoad()看到的是 32 核里只有 2 核忙整體算下來 CPU 使用率可能只有 6%系統(tǒng)規(guī)則永遠(yuǎn)觸發(fā)不了。這是我在容器化落地中遇到的最頭疼的問題。目前可用的解決方案是引入容器 CPU 感知的采集器或者干脆繞過系統(tǒng)整體 CPU直接用 cgroup 文件計(jì)算容器 CPU 使用率。雖然 Sentinel 自身沒有提供完美的容器適配但你可以通過定時(shí)任務(wù)讀取/sys/fs/cgroup/cpu/cpuacct.usage或cpu.stat計(jì)算容器級別的 CPU 使用率再手動(dòng)調(diào)用SystemRuleManager的規(guī)則觸發(fā)邏輯。// 通過 cgroup 計(jì)算容器 CPU 使用率替代系統(tǒng)級 CPU 使用率 private double getContainerCpuUsage() throws IOException { Path cpuStatPath Paths.get(/sys/fs/cgroup/cpu/cpu.stat); if (!Files.exists(cpuStatPath)) { return -1; } // nr_periods 為周期數(shù)nr_throttled 為被限制周期數(shù) ListString lines Files.readAllLines(cpuStatPath); long nrPeriods 0, nrThrottled 0; for (String line : lines) { if (line.startsWith(nr_periods)) { nrPeriods Long.parseLong(line.split(\\s)[1]); } else if (line.startsWith(nr_throttled)) { nrThrottled Long.parseLong(line.split(\\s)[1]); } } if (nrPeriods 0) { return -1; } return (double) nrThrottled / nrPeriods; }這段代碼的思路是容器被 CPU 限流的時(shí)間占比本質(zhì)上就是容器能夠使用的 CPU 配額被打滿的占比。如果這個(gè)值超過 50%說明容器長期處于 CPU 饑餓狀態(tài)比宿主機(jī)級別指標(biāo)準(zhǔn)確得多。4.3 閾值觸發(fā)后一直不恢復(fù)這個(gè)坑也很有代表性。系統(tǒng)規(guī)則在 CPU 使用率下降后理論上應(yīng)該自動(dòng)恢復(fù)放行。但實(shí)際中如果觸發(fā)限流時(shí)有很多請求在被拒絕前已經(jīng)進(jìn)入了業(yè)務(wù)線程池它們會(huì)繼續(xù)在后臺處理一段時(shí)間導(dǎo)致系統(tǒng)負(fù)載和 CPU 在限流生效后依然高居不下。然后規(guī)則就不停觸發(fā)形成死鎖感。解決方案是給系統(tǒng)規(guī)則加一個(gè)“冷卻期”概念也就是連續(xù) N 次采樣都低于閾值才恢復(fù)放行而不是一次采樣低于閾值就立刻放行。這個(gè)邏輯 Sentinel 原生沒有需要自己包一層。private int consecutiveHealthyCount 0; private static final int HEALTHY_THRESHOLD 5; public boolean shouldBlock(boolean isCpuOverThreshold) { if (isCpuOverThreshold) { consecutiveHealthyCount 0; return true; } // 連續(xù) 5 次采樣健康才恢復(fù) if (consecutiveHealthyCount HEALTHY_THRESHOLD) { return false; } consecutiveHealthyCount; return true; }從效果看這個(gè)冷卻期避免了規(guī)則在臨界閾值附近快速抖動(dòng)讓系統(tǒng)有足夠時(shí)間消化存量請求恢復(fù)過程更平滑。代價(jià)是誤傷時(shí)間變長但比起在臨界點(diǎn)反復(fù)抖動(dòng)造成的不穩(wěn)定體驗(yàn)這點(diǎn)代價(jià)完全值得。4.4 閾值設(shè)多少才合理給一套可復(fù)用的“試探法”我推薦用灰度試探法。具體操作先配一個(gè)高閾值比如 CPU 使用率 95%系統(tǒng)負(fù)載 2 倍核數(shù)同時(shí)觀察線上 RT 和錯(cuò)誤率。每隔 15 分鐘下調(diào)一次閾值每次下調(diào) 5% 或 0.5 倍核數(shù)直到你發(fā)現(xiàn) RT 毛刺明顯減少、而業(yè)務(wù) QPS 沒有大量被拒絕那個(gè)點(diǎn)就是當(dāng)前版本的“甜點(diǎn)區(qū)間”。這套方法的原理是在閾值高位時(shí)系統(tǒng)規(guī)則的介入少能觀察到底層數(shù)據(jù)逐步下調(diào)找到“攔截最陡曲線”的拐點(diǎn)。這比直接拍腦袋設(shè) 80% 要科學(xué)因?yàn)椴煌?wù)對 CPU 的敏感度完全不同——純 IO 型服務(wù) CPU 到 90% 可能都沒影響計(jì)算密集的服務(wù) 70% 就得限制。5. 生產(chǎn)落地的擴(kuò)展動(dòng)態(tài)數(shù)據(jù)源與多節(jié)點(diǎn)一致性5.1 把規(guī)則遷移到配置中心別讓控制臺背鍋使用控制臺推送規(guī)則有個(gè)隱患控制臺本身是獨(dú)立進(jìn)程一旦它掛了或者規(guī)則推送通道斷了服務(wù)端的規(guī)則還停留在最后一次推送的狀態(tài)。生產(chǎn)環(huán)境最好把規(guī)則持久化到配置中心比如 Nacos 或 ApolloSentinel 通過DataSource接口監(jiān)聽配置變化。// 使用 Nacos 作為 Sentinel 規(guī)則數(shù)據(jù)源的偽代碼 ReadableDataSourceString, ListSystemRule systemRuleDataSource new NacosDataSource(nacosAddr, groupId, dataId, source - JSON.parseObject(source, new TypeReferenceListSystemRule() {})); SystemRuleManager.register2Property(systemRuleDataSource.getProperty());這樣做還有一個(gè)額外的好處多實(shí)例的規(guī)則版本一致。控制臺手動(dòng)推規(guī)則是推給單個(gè) IP配置中心推給的是所有訂閱節(jié)點(diǎn)不會(huì)出現(xiàn)一臺機(jī)器限流一臺不限流的“半抬起半落下”狀態(tài)。熱詞里有人搜spring cloud sentinel datasource redis集群其實(shí)也是這個(gè)思路——規(guī)則源的存儲無所謂Redis、數(shù)據(jù)庫還是 Nacos只要能保證一致性和實(shí)時(shí)性就行。5.2 多節(jié)點(diǎn)限流的公平性問題集群部署下還有一個(gè)注意點(diǎn)每臺機(jī)器獨(dú)立運(yùn)行系統(tǒng)規(guī)則而系統(tǒng)負(fù)載是單機(jī)指標(biāo)。如果負(fù)載均衡算法不完美可能出現(xiàn)一臺機(jī)器 CPU 爆掉觸發(fā)限流另一臺還很空閑。這不算 Sentinel 的 bug而是“自適應(yīng)保護(hù)”天然沒有全局視角的體現(xiàn)。如果業(yè)務(wù)對全局一致性要求高可以把系統(tǒng)規(guī)則和集群流控配合使用。集群流控負(fù)責(zé)全局流量分配系統(tǒng)規(guī)則負(fù)責(zé)單機(jī)兜底。一個(gè)簡單的組合集群流控把總流量控制在整個(gè)集群容量的 70%剩下 30% 留給單機(jī)系統(tǒng)規(guī)則動(dòng)態(tài)消化。這樣 CPU 使用率監(jiān)控在單機(jī)層面繼續(xù)生效但全局流量不會(huì)因?yàn)橐慌_機(jī)器抖動(dòng)就大面積受限。最后分享一個(gè)我堅(jiān)持在生產(chǎn)環(huán)境使用的驗(yàn)證腳本每次調(diào)完系統(tǒng)規(guī)則參數(shù)我會(huì)用一段腳本做煙霧測試確認(rèn)限流不是“紙面配置”。# 用 wrk 制造持續(xù) 30 秒的并發(fā)壓力觀察系統(tǒng)規(guī)則觸發(fā)后 QPS 是否被壓低 wrk -t8 -c200 -d30s http://your-service/api/test # 同時(shí)從 sentinel-record.log 里過濾系統(tǒng)保護(hù)記錄 grep System protection /data/logs/sentinel-record.log | tail -20確認(rèn)輸出里有連續(xù)的“Blocked”記錄同時(shí)服務(wù)依然能返回部分成功請求而不是完全 502說明規(guī)則有效且系統(tǒng)仍在兜底運(yùn)行。這套“邊壓邊驗(yàn)”的流程我堅(jiān)持了很久每次調(diào)參心里都有底。系統(tǒng)規(guī)則 JVM 指標(biāo)聯(lián)動(dòng)這件事核心不在于 Sentinel 配置本身多復(fù)雜而是想明白“到底拿什么信號來代表系統(tǒng)過載”。CPU 使用率是一個(gè)好信號但它必須結(jié)合 JVM 的 GC、線程、內(nèi)存一起看才能區(qū)分“流量過載”和“系統(tǒng)自身抖動(dòng)”。希望這篇實(shí)戰(zhàn)記錄能幫你把限流從“拍數(shù)字”進(jìn)化到“看體征”。