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