Sentinel 系統(tǒng)規(guī)則實(shí)戰(zhàn)讓 JVM 的 CPU 使用率直接參與限流決策先扯個(gè)實(shí)際場(chǎng)景。你有沒(méi)有遇到過(guò)這種詭異情況線上服務(wù) QPS 明明還在可接受范圍接口 RT 卻開始直線飆高緊接著整個(gè)應(yīng)用像被什么東西掐住脖子一樣卡頓、超時(shí)、批量報(bào)錯(cuò)最后連著數(shù)據(jù)庫(kù)一起拖垮。我早期做高并發(fā)服務(wù)時(shí)就栽過(guò)一回流量洪峰到來(lái)前業(yè)務(wù)團(tuán)隊(duì)粗估了一個(gè) QPS 閾值辛辛苦苦配好了單機(jī)限流結(jié)果流量真的沖上來(lái)時(shí)單機(jī) QPS 還沒(méi)到預(yù)設(shè)值機(jī)器 CPU 先被打滿了限流規(guī)則根本沒(méi)機(jī)會(huì)觸發(fā)服務(wù)照樣雪崩。這事逼著我重新想一個(gè)問(wèn)題限流到底應(yīng)該限什么是數(shù)字上的 QPS還是背后真正決定系統(tǒng)吞吐能力的資源后來(lái)我把目光放到了阿里開源的 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ù)、但對(duì)系統(tǒng)規(guī)則模塊還不太熟的讀者也適合那些和我一樣被“誤傷型限流”坑過(guò)的同學(xué)。1. 系統(tǒng)規(guī)則的核心思路為什么不用固定 QPS反而盯 CPU1.1 單機(jī) QPS 限流的局限在哪里先拆一下固定 QPS 限流的邏輯。它的核心假設(shè)是單機(jī)能扛 2000 QPS超過(guò)就攔。這個(gè)假設(shè)有兩個(gè)脆弱點(diǎn)。第一QPS 閾值是拍腦袋定的。上線前壓測(cè)得出 2000 QPS上線后業(yè)務(wù)代碼加了一段耗時(shí)邏輯或者 JVM 堆內(nèi)存調(diào)小了實(shí)際扛 1500 QPS 就喘不過(guò)氣。你原來(lái)的 2000 閾值不但沒(méi)保護(hù)服務(wù)反而成了幫兇因?yàn)檎?qǐng)求放進(jìn)來(lái)之后線程在瘋狂堆積RT 指數(shù)級(jí)惡化這就是經(jīng)典的請(qǐ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ù)測(cè)代替感知”而分布式系統(tǒng)的突發(fā)負(fù)載、Full GC、宿主機(jī)搶占都不是你提前能預(yù)測(cè)準(zhǔn)的。這也是我后來(lái)堅(jiān)定轉(zhuǎn)向系統(tǒng)規(guī)則的原因——它不做預(yù)測(cè)只做響應(yīng)。1.2 系統(tǒng)規(guī)則的運(yùn)行邏輯自適應(yīng)保護(hù)Sentinel 的系統(tǒng)規(guī)則官方叫 SystemRule核心思想是讓入口流量自適應(yīng)系統(tǒng)承載能力。它的保護(hù)對(duì)象是整臺(tái) JVM 所在的機(jī)器節(jié)點(diǎn)不是某個(gè)接口。具體實(shí)現(xiàn)上Sentinel 會(huì)周期性采樣當(dāng)前系統(tǒng)的幾個(gè)核心指標(biāo)指標(biāo)說(shuō)明觸發(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)程的超過(guò)閾值后拒絕所有新請(qǐng)求進(jìn)入RT所有入口流量的平均響應(yīng)時(shí)間超過(guò)閾值后拒絕新請(qǐng)求線程數(shù)入口流量的并發(fā)線程數(shù)超過(guò)閾值后拒絕新請(qǐng)求入口 QPS所有入口流量的聚合 QPS一般配合負(fù)載策略使用注意上表里兩個(gè)容易混淆的點(diǎn)。一是 CPU 使用率指標(biāo)和系統(tǒng)負(fù)載指標(biāo)是兩套獨(dú)立邏輯CPU 使用率一旦超閾值是直接把后續(xù)請(qǐng)求全部拒絕根本沒(méi)有協(xié)商余地系統(tǒng)負(fù)載則是動(dòng)態(tài)調(diào)整入口 QPS負(fù)載越高允許進(jìn)來(lái)的請(qǐng)求越少控制更柔和。二是 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對(duì)象里面保存著當(dāng)前負(fù)載、CPU、RT、線程數(shù)。每個(gè)請(qǐng)求進(jìn)入 Sentinel 的 slot 鏈路時(shí)SystemSlot會(huì)讀取這些指標(biāo)和規(guī)則閾值比較決定放行還是拒絕。整個(gè)鏈路是典型的“異步采樣 同步判斷”實(shí)時(shí)性依賴采樣頻率這也是后面排查問(wèn)題時(shí)一個(gè)關(guān)鍵切入點(diǎn)。2. 核心實(shí)操CPU 閾值與負(fù)載參數(shù)的配置全流程2.1 系統(tǒng)規(guī)則有哪些參數(shù)該怎么定初始值我直接給你一套我在生產(chǎn)環(huán)境驗(yàn)證過(guò)的基礎(chǔ)配置思路。參數(shù)配置入口我的生產(chǎn)建議備注CPU 使用率閾值SystemRule的highestCpuUsage80%85%超過(guò)后直接拒絕所有新請(qǐng)求系統(tǒng)負(fù)載閾值SystemRule的highestSystemLoad等于 CPU 核心數(shù)如 4 核設(shè) 4.0動(dòng)態(tài)調(diào)整入口 QPS平均 RT 閾值SystemRule的avgRt根據(jù)業(yè)務(wù)壓測(cè)結(jié)果比如 300ms超過(guò)后拒絕新請(qǐng)求線程數(shù)閾值SystemRule的maxThread核心線程數(shù) * 2 附近防線程堆積為什么 CPU 使用率閾值選 80%85%因?yàn)?CPU 超過(guò)這個(gè)值后系統(tǒng)可能還有一點(diǎn)緩沖余量但 RT 已經(jīng)開始出現(xiàn)明顯毛刺。如果設(shè)到 95%設(shè)備長(zhǎng)時(shí)間滿負(fù)荷運(yùn)行JVM 的 GC 線程和業(yè)務(wù)線程互相搶 CPU服務(wù)已經(jīng)處在崩潰邊緣保護(hù)動(dòng)作來(lái)得太晚。如果設(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 接近飽和但還沒(méi)過(guò)載。負(fù)載超過(guò)核心數(shù)說(shuō)明有線程在排隊(duì)這時(shí)候再繼續(xù)放流量進(jìn)來(lái)排隊(duì)只會(huì)越來(lái)越嚴(yán)重。2.2 Sentinel 的負(fù)載閾值是怎么換算成 QPS 的這里值得多說(shuō)一句因?yàn)楹芏嗳伺渲猛曦?fù)載閾值后發(fā)現(xiàn)實(shí)際生效的 QPS 數(shù)字和預(yù)期完全對(duì)不上。Sentinel 沒(méi)有拿負(fù)載閾值直接限流它參考了 TCP BBR 的帶寬延遲積思想做了一個(gè)換算公式。核心邏輯是當(dāng)前系統(tǒng)能承受的最大 QPS約等于“并發(fā)線程數(shù)當(dāng)前值 / 平均 RT”。我拆解一下這個(gè)過(guò)程。Sentinel 在DefaultNode里維護(hù)了入口流量的統(tǒng)計(jì)包含當(dāng)前并發(fā)線程數(shù)curThreadNum和平均 RT。系統(tǒng)負(fù)載超過(guò)閾值后它按 BBR 風(fēng)格帶寬評(pí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); }簡(jiǎn)單理解就是系統(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ī)則方式一硬編碼適合測(cè)試環(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)); }方式二通過(guò)控制臺(tái)動(dòng)態(tài)推送。在 Sentinel 控制臺(tái)的“系統(tǒng)規(guī)則”菜單里新增填好閾值后直接發(fā)布。這種方式適合生產(chǎn)環(huán)境動(dòng)態(tài)調(diào)整但要注意控制臺(tái)版本和服務(wù)端版本要匹配否則推送不生效。方式三通過(guò)FlowRule的grade參數(shù)指定為RuleConstant.SYSTEM_LOAD或RuleConstant.SYSTEM_CPU在流控規(guī)則里單獨(dú)配置 CPU 維度。這種方式相對(duì)少見但從命名上能看出 Sentinel 把系統(tǒng)保護(hù)規(guī)則也納入到了統(tǒng)一規(guī)則體系里。我實(shí)踐下來(lái)最推薦的方式是代碼初始化兜底 控制臺(tái)動(dòng)態(tài)調(diào)參。代碼里寫一套保守閾值做啟動(dòng)保護(hù)控制臺(tái)再根據(jù)壓測(cè)數(shù)據(jù)調(diào)優(yōu)到合理值。不然線上機(jī)器配置變更或者業(yè)務(wù)擴(kuò)容后硬編碼的閾值就成了定時(shí)炸彈。2.4 如何驗(yàn)證規(guī)則真的生效了配置完了不代表它就會(huì)按下你想象的方式工作。我見過(guò)不少人配完規(guī)則壓測(cè)半天沒(méi)觸發(fā)懷疑規(guī)則沒(méi)用。其實(shí)很大概率是壓測(cè)姿勢(shì)不對(duì)。驗(yàn)證要分三步走。第一步確認(rèn)機(jī)器的 CPU 使用率確實(shí)能通過(guò) Sentinel 采集到。打開日志看sentinel-record.log里面會(huì)周期性打印系統(tǒng)指標(biāo)采樣值確認(rèn)不是 0也不是空。第二步制造壓力。用壓測(cè)工具我常用 wrk 或 JMeter直接打入口服務(wù)觀察控制臺(tái)或日志里有沒(méi)有出現(xiàn)一個(gè)關(guān)鍵日志[Sentinel] Blocked by system protection: SystemRule或類似字樣。只要出現(xiàn)這條日志說(shuō)明系統(tǒng)規(guī)則真正參與攔截了。第三步驗(yàn)證恢復(fù)。停掉壓測(cè)流量觀察系統(tǒng)指標(biāo)回落后請(qǐng)求是否自動(dòng)恢復(fù)放行。有時(shí)候規(guī)則觸發(fā)后一直不恢復(fù)多半是采樣線程被 GC 或線程池饑餓影響了這個(gè)后面排查章節(jié)會(huì)細(xì)說(shuō)。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ù)對(duì)閾值調(diào)整的柔性修正。這兩個(gè)結(jié)合起來(lái)才是完整的“系統(tǒng)規(guī)則 JVM 指標(biāo)聯(lián)動(dòng)”。3.1 為什么 CPU 使用率高時(shí)先要看是不是 Full GC 在搗鬼有一次線上服務(wù) CPU 使用率飆到 90% 以上系統(tǒng)規(guī)則觸發(fā)后大量請(qǐng)求被攔截但業(yè)務(wù)團(tuán)隊(duì)說(shuō)沒(méi)看到明顯的流量增長(zhǎng)。最后查了半天是堆內(nèi)存里有一個(gè)本地緩存實(shí)現(xiàn)有誤數(shù)據(jù)無(wú)限增長(zhǎng)導(dǎo)致 Full GC 頻繁觸發(fā)。Full GC 是多線程并行回收階段會(huì)吃滿所有 CPU 核心表現(xiàn)為“系統(tǒng)負(fù)載高、CPU 使用率高”而業(yè)務(wù)線程其實(shí)沒(méi)有干多少活。這個(gè)案例說(shuō)明CPU 使用率高只是一個(gè)結(jié)果不一定是業(yè)務(wù)流量導(dǎo)致的。如果直接把 CPU 閾值當(dāng)成唯一限流依據(jù)那么一次頻繁的 GC 就會(huì)引發(fā)全站“無(wú)差別限流”甚至把正常流量也擋在門外。所以我在實(shí)踐里會(huì)做一層過(guò)濾當(dāng) CPU 使用率觸發(fā)系統(tǒng)規(guī)則后先通過(guò) JMX 拉取 JVM 的 GC 頻次數(shù)據(jù)判斷 CPU 是被業(yè)務(wù)線程消耗還是被 GC 線程消耗。// 通過(guò) 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)大幅上升 → 如果是說(shuō)明系統(tǒng)進(jìn)入“GC 抖動(dòng)狀態(tài)”此時(shí)不應(yīng)該簡(jiǎn)單拒絕所有請(qǐng)求因?yàn)榱髁勘旧頉](méi)有超載真正的問(wèn)題是內(nèi)存或 GC 參數(shù)不合理。這時(shí)候最優(yōu)動(dòng)作是保底攔截一部分請(qǐng)求給 GC 喘息時(shí)間同時(shí)觸發(fā)內(nèi)存 dump 或擴(kuò)容而不是讓正常用戶在無(wú)感知情況下全部被攔截。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ù)做過(guò)一個(gè)動(dòng)態(tài)修正器每 10 秒采集一次 JVM GC 和內(nèi)存指標(biāo)動(dòng)態(tài)調(diào)整 Sentinel 的 CPU 閾值。核心思路是正常情況下 CPU 閾值保持 85%如果監(jiān)測(cè)到 Full GC 頻繁自動(dòng)把 CPU 閾值下調(diào)到 70%讓系統(tǒng)更早進(jìn)入保護(hù)狀態(tài)減少因 GC 造成的請(qǐng)求堆積。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)超過(guò) 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 超過(guò) 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í)是針對(duì)“入口并發(fā)線程數(shù)”的而不是 JVM 全部線程。但生產(chǎn)環(huán)境里一個(gè)比入口線程數(shù)更危險(xiǎn)的信號(hào)是 JVM 整體的活線程數(shù)逼近線程池上限。當(dāng) Tomcat 或業(yè)務(wù)線程池的線程全部處于RUNNABLE狀態(tài)并且大量阻塞在遠(yuǎn)程調(diào)用或鎖等待上時(shí)JVM 線程數(shù)這個(gè)指標(biāo)比 CPU 使用率更早反映問(wèn)題。我在壓測(cè)中遇到過(guò)CPU 使用率才 40%但線程池已經(jīng)被占滿RT 狂飆此時(shí)系統(tǒng)規(guī)則根本沒(méi)觸發(fā)因?yàn)?CPU 還沒(méi)到閾值。對(duì)這種場(chǎng)景我把 JVM 線程數(shù)也納入聯(lián)動(dòng)判斷定期檢查ThreadMXBean.getThreadCount()如果超過(guò)預(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)過(guò)期避免長(zhǎng)時(shí)間誤傷 SystemRuleManager.loadRules(Collections.singletonList(systemRule)); }3.4 JVM 參數(shù)調(diào)優(yōu)對(duì)系統(tǒng)規(guī)則效果的影響聊到這里必須提一嘴 JVM 參數(shù)因?yàn)楹芏嗳税l(fā)現(xiàn)系統(tǒng)規(guī)則“該觸發(fā)時(shí)沒(méi)觸發(fā)”問(wèn)題不在 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 對(duì)外表現(xiàn)的 RT 可能還沒(méi)有明顯惡化。這時(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 使用率才有資格作為限流信號(hào)。否則你限的是“GC 引發(fā)的 CPU 毛刺”而不是真正的業(yè)務(wù)負(fù)載整個(gè)聯(lián)動(dòng)邏輯就失真了。4. 常見問(wèn)題排查與避坑實(shí)錄這部分全是真金白銀的踩坑記錄。我按出現(xiàn)頻率排個(gè)序把典型問(wèn)題和排查思路整理成一張速查表再展開講幾個(gè)最坑的。問(wèn)題現(xiàn)象可能原因排查步驟系統(tǒng)規(guī)則配置了但不生效控制臺(tái)版本不匹配未引入sentinel-parameter-flow-control或系統(tǒng)規(guī)則模塊檢查依賴查看控制臺(tái)是否展示規(guī)則用代碼加載規(guī)則做對(duì)照一臺(tái)機(jī)器限流另一臺(tái)不限流單機(jī)采樣差異宿主機(jī) CPU 爭(zhēng)搶負(fù)載不均衡對(duì)比各節(jié)點(diǎn)日志中的系統(tǒng)指標(biāo)檢查是否在同一宿主機(jī)CPU 閾值很明顯超了但還是放行采樣頻率是 1s秒級(jí)數(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)先級(jí)控制臺(tái)推送規(guī)則成功但服務(wù)端不生效服務(wù)端未接入數(shù)據(jù)庫(kù)/配置中心推送給應(yīng)用但應(yīng)用未注冊(cè)監(jiān)聽檢查應(yīng)用側(cè)日志確認(rèn)是否包含SentinelAutoConfiguration負(fù)載閾值換算出來(lái)的 QPS 不直觀對(duì) BBR 換算公式不理解看calculateAllowedQps邏輯在日志看動(dòng)態(tài) QPS 值4.1 系統(tǒng)規(guī)則“不生效”的經(jīng)典坑版本與控制臺(tái)不匹配這個(gè)問(wèn)題排查成本最高。有些團(tuán)隊(duì)的 Sentinel 控制臺(tái)是早期版本應(yīng)用內(nèi)嵌的sentinel-core卻升級(jí)到了較新版本兩個(gè)版本之間規(guī)則推送協(xié)議不一致控制臺(tái)上配置了系統(tǒng)規(guī)則應(yīng)用端完全沒(méi)有感知。我的排查習(xí)慣是三步走。第一直接跑一個(gè)本地 Java 進(jìn)程用官方控制臺(tái)同版本對(duì)接把同樣的規(guī)則推一遍看本地是否觸發(fā)。第二檢查服務(wù)的sentinel-record.log里面有沒(méi)有Receive new config from command center之類的記錄。第三用最原始的辦法驗(yàn)證代碼里手動(dòng)寫死一條 CPU 閾值規(guī)則來(lái)測(cè)試排除一切外部依賴先確認(rèn)基礎(chǔ)鏈路通不通。4.2 CPU 使用率采集偏差別忽略宿主機(jī)的影響Sentinel 讀取 CPU 使用率是通過(guò)OperatingSystemMXBean.getSystemLoadAverage()和自定義的 CPU 采樣器來(lái)實(shí)現(xiàn)的。注意getSystemLoadAverage()返回的是系統(tǒng) 1 分鐘平均負(fù)載而 CPU 使用率是通過(guò)com.sun.management.OperatingSystemMXBean.getSystemCpuLoad()獲取。在容器化部署比如 Docker 或 K8s場(chǎng)景下這個(gè)采集有一個(gè)天坑容器默認(rèn)讀取的是宿主機(jī)整體 CPU 狀態(tài)。假如宿主機(jī) 32 核你的 Pod 被限制只用 2 核Pod 計(jì)算密集型業(yè)務(wù)能把 2 核打滿但getSystemCpuLoad()看到的是 32 核里只有 2 核忙整體算下來(lái) CPU 使用率可能只有 6%系統(tǒng)規(guī)則永遠(yuǎn)觸發(fā)不了。這是我在容器化落地中遇到的最頭疼的問(wèn)題。目前可用的解決方案是引入容器 CPU 感知的采集器或者干脆繞過(guò)系統(tǒng)整體 CPU直接用 cgroup 文件計(jì)算容器 CPU 使用率。雖然 Sentinel 自身沒(méi)有提供完美的容器適配但你可以通過(guò)定時(shí)任務(wù)讀取/sys/fs/cgroup/cpu/cpuacct.usage或cpu.stat計(jì)算容器級(jí)別的 CPU 使用率再手動(dòng)調(diào)用SystemRuleManager的規(guī)則觸發(fā)邏輯。// 通過(guò) cgroup 計(jì)算容器 CPU 使用率替代系統(tǒng)級(jí) 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è)值超過(guò) 50%說(shuō)明容器長(zhǎng)期處于 CPU 饑餓狀態(tài)比宿主機(jī)級(jí)別指標(biāo)準(zhǔn)確得多。4.3 閾值觸發(fā)后一直不恢復(fù)這個(gè)坑也很有代表性。系統(tǒng)規(guī)則在 CPU 使用率下降后理論上應(yīng)該自動(dòng)恢復(fù)放行。但實(shí)際中如果觸發(fā)限流時(shí)有很多請(qǐng)求在被拒絕前已經(jīng)進(jìn)入了業(yè)務(wù)線程池它們會(huì)繼續(xù)在后臺(tái)處理一段時(shí)間導(dǎo)致系統(tǒng)負(fù)載和 CPU 在限流生效后依然高居不下。然后規(guī)則就不停觸發(fā)形成死鎖感。解決方案是給系統(tǒng)規(guī)則加一個(gè)“冷卻期”概念也就是連續(xù) N 次采樣都低于閾值才恢復(fù)放行而不是一次采樣低于閾值就立刻放行。這個(gè)邏輯 Sentinel 原生沒(méi)有需要自己包一層。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í)間消化存量請(qǐng)求恢復(fù)過(guò)程更平滑。代價(jià)是誤傷時(shí)間變長(zhǎng)但比起在臨界點(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 沒(méi)有大量被拒絕那個(gè)點(diǎn)就是當(dāng)前版本的“甜點(diǎn)區(qū)間”。這套方法的原理是在閾值高位時(shí)系統(tǒng)規(guī)則的介入少能觀察到底層數(shù)據(jù)逐步下調(diào)找到“攔截最陡曲線”的拐點(diǎn)。這比直接拍腦袋設(shè) 80% 要科學(xué)因?yàn)椴煌?wù)對(duì) CPU 的敏感度完全不同——純 IO 型服務(wù) CPU 到 90% 可能都沒(méi)影響計(jì)算密集的服務(wù) 70% 就得限制。5. 生產(chǎn)落地的擴(kuò)展動(dòng)態(tài)數(shù)據(jù)源與多節(jié)點(diǎn)一致性5.1 把規(guī)則遷移到配置中心別讓控制臺(tái)背鍋使用控制臺(tái)推送規(guī)則有個(gè)隱患控制臺(tái)本身是獨(dú)立進(jìn)程一旦它掛了或者規(guī)則推送通道斷了服務(wù)端的規(guī)則還停留在最后一次推送的狀態(tài)。生產(chǎn)環(huán)境最好把規(guī)則持久化到配置中心比如 Nacos 或 ApolloSentinel 通過(guò)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ī)則版本一致?？刂婆_(tái)手動(dòng)推規(guī)則是推給單個(gè) IP配置中心推給的是所有訂閱節(jié)點(diǎn)不會(huì)出現(xiàn)一臺(tái)機(jī)器限流一臺(tái)不限流的“半抬起半落下”狀態(tài)。熱詞里有人搜spring cloud sentinel datasource redis集群其實(shí)也是這個(gè)思路——規(guī)則源的存儲(chǔ)無(wú)所謂Redis、數(shù)據(jù)庫(kù)還是 Nacos只要能保證一致性和實(shí)時(shí)性就行。5.2 多節(jié)點(diǎn)限流的公平性問(wèn)題集群部署下還有一個(gè)注意點(diǎn)每臺(tái)機(jī)器獨(dú)立運(yùn)行系統(tǒng)規(guī)則而系統(tǒng)負(fù)載是單機(jī)指標(biāo)。如果負(fù)載均衡算法不完美可能出現(xiàn)一臺(tái)機(jī)器 CPU 爆掉觸發(fā)限流另一臺(tái)還很空閑。這不算 Sentinel 的 bug而是“自適應(yīng)保護(hù)”天然沒(méi)有全局視角的體現(xiàn)。如果業(yè)務(wù)對(duì)全局一致性要求高可以把系統(tǒng)規(guī)則和集群流控配合使用。集群流控負(fù)責(zé)全局流量分配系統(tǒng)規(guī)則負(fù)責(zé)單機(jī)兜底。一個(gè)簡(jiǎn)單的組合集群流控把總流量控制在整個(gè)集群容量的 70%剩下 30% 留給單機(jī)系統(tǒng)規(guī)則動(dòng)態(tài)消化。這樣 CPU 使用率監(jiān)控在單機(jī)層面繼續(xù)生效但全局流量不會(huì)因?yàn)橐慌_(tái)機(jī)器抖動(dòng)就大面積受限。最后分享一個(gè)我堅(jiān)持在生產(chǎn)環(huán)境使用的驗(yàn)證腳本每次調(diào)完系統(tǒng)規(guī)則參數(shù)我會(huì)用一段腳本做煙霧測(cè)試確認(rèn)限流不是“紙面配置”。# 用 wrk 制造持續(xù) 30 秒的并發(fā)壓力觀察系統(tǒng)規(guī)則觸發(fā)后 QPS 是否被壓低 wrk -t8 -c200 -d30s http://your-service/api/test # 同時(shí)從 sentinel-record.log 里過(guò)濾系統(tǒng)保護(hù)記錄 grep System protection /data/logs/sentinel-record.log | tail -20確認(rèn)輸出里有連續(xù)的“Blocked”記錄同時(shí)服務(wù)依然能返回部分成功請(qǐng)求而不是完全 502說(shuō)明規(guī)則有效且系統(tǒng)仍在兜底運(yùn)行。這套“邊壓邊驗(yàn)”的流程我堅(jiān)持了很久每次調(diào)參心里都有底。系統(tǒng)規(guī)則 JVM 指標(biāo)聯(lián)動(dòng)這件事核心不在于 Sentinel 配置本身多復(fù)雜而是想明白“到底拿什么信號(hào)來(lái)代表系統(tǒng)過(guò)載”。CPU 使用率是一個(gè)好信號(hào)但它必須結(jié)合 JVM 的 GC、線程、內(nèi)存一起看才能區(qū)分“流量過(guò)載”和“系統(tǒng)自身抖動(dòng)”。希望這篇實(shí)戰(zhàn)記錄能幫你把限流從“拍數(shù)字”進(jìn)化到“看體征”。