提到Sentinel很多同學(xué)第一反應(yīng)是限流熔斷組件但真正到要接入項(xiàng)目的時(shí)候又容易被一堆概念繞暈資源、規(guī)則、Slot鏈、滑動窗口、控制臺推送……這套東西要是沒搞懂底層機(jī)制配置半天不生效生產(chǎn)環(huán)境一壓測就原形畢露。這篇文章把我自己從“會用注解”到“能看懂源碼鏈路”這段時(shí)間踩過的坑、梳理清楚的關(guān)鍵點(diǎn)完整整理出來。適用的讀者比較明確已經(jīng)在用或者準(zhǔn)備用Sentinel做流量治理的Java后端開發(fā)尤其是微服務(wù)架構(gòu)剛起步、接口偶發(fā)性抖動、想引入限流但不知道從哪下手的團(tuán)隊(duì)。我會先從配置流程講起再深入到底層實(shí)現(xiàn)原理這一次盡量把“為什么這樣配置”和“運(yùn)行時(shí)到底發(fā)生了什么”串起來講而不是貼一堆官方文檔。1. 先搞清楚Sentinel解決什么問題1.1 三個(gè)核心場景直擊痛點(diǎn)Sentinel的核心能力概括起來就三塊流量控制、熔斷降級、系統(tǒng)負(fù)載保護(hù)。聽起來很抽象實(shí)際遇到的問題是具體的。流量控制對應(yīng)的是突發(fā)流量把服務(wù)打掛的問題。比如某個(gè)活動頁面零點(diǎn)上線瞬間涌入的請求是平時(shí)的幾十倍數(shù)據(jù)庫連接池和下游服務(wù)根本沒有喘息機(jī)會。Sentinel做的不是單純限制QPS數(shù)字而是根據(jù)你定義好的閾值和策略把超過閾值的流量擋在業(yè)務(wù)邏輯之前保護(hù)入口鏈路不被打穿。熔斷降級對應(yīng)的是下游依賴出問題時(shí)的“雪崩”傳導(dǎo)。比如訂單服務(wù)調(diào)用了庫存服務(wù)庫存服務(wù)GC停頓三秒訂單服務(wù)的線程就大批堆積堆積的線程又占滿Tomcat線程池緊接著整個(gè)訂單服務(wù)也假死。Sentinel通過慢調(diào)用比例、異常比例這些指標(biāo)判斷下游是否處于不健康狀態(tài)一旦觸發(fā)就快速返回兜底結(jié)果不再去請求異常的依賴。系統(tǒng)負(fù)載保護(hù)更偏向整機(jī)維度不是只看單個(gè)接口的QPS而是結(jié)合CPU使用率、系統(tǒng)Load、平均RT這些機(jī)器級指標(biāo)做兜底。這一點(diǎn)在很多網(wǎng)關(guān)場景特別有用后端機(jī)器已經(jīng)高負(fù)載了即使每個(gè)接口都沒達(dá)到流控閾值也應(yīng)該主動削峰。三條能力各有適用場景但它們的底層都是“統(tǒng)計(jì) 規(guī)則判斷”理解這一點(diǎn)后面的機(jī)制就好懂很多。1.2 資源和規(guī)則理解配置的最小單元Sentinel整個(gè)模型可以壓縮成兩個(gè)詞資源和規(guī)則。資源是你要保護(hù)的目標(biāo)規(guī)則是定義怎么保護(hù)。資源在代碼里通常是一個(gè)方法、一個(gè)接口、或者一段業(yè)務(wù)邏輯。手動埋點(diǎn)時(shí)用SphU.entry(someResource)創(chuàng)建入口用注解SentinelResource(someResource)也可以起到類似效果。規(guī)則則通過Rule對象描述比如FlowRule描述流控規(guī)則、DegradeRule描述熔斷規(guī)則、AuthorityRule描述黑白名單規(guī)則。配置規(guī)則的本質(zhì)就是把“資源”和“限制條件”關(guān)聯(lián)起來。我剛開始接觸時(shí)有個(gè)誤區(qū)以為只要在控制臺配了規(guī)則代碼里不用做任何改動就自動生效。實(shí)際上資源埋點(diǎn)才是前提控制臺規(guī)則只是告訴Sentinel“對這個(gè)已埋點(diǎn)的資源做什么限制”。如果代碼里根本沒對某接口埋點(diǎn)控制臺配再多規(guī)則也是空轉(zhuǎn)。1.3 Sentinel和其他限流組件的本質(zhì)差異和Hystrix這類線程隔離方案比Sentinel的差異很直觀。Hystrix用線程池隔離來保護(hù)依賴每個(gè)依賴分配固定線程數(shù)超了直接拒絕代價(jià)是每一個(gè)下游調(diào)用都要跨線程切換線程開銷很大。Sentinel走的是統(tǒng)計(jì)流量再加規(guī)則判斷的路線不額外創(chuàng)建線程池請求仍然走原始調(diào)用線程只是在入口處做了計(jì)數(shù)器判斷性能開銷要小得多。Resilience4j是另一種輕量級方案它的滑動窗口和熔斷器也做得不錯(cuò)但規(guī)則管理和控制臺體驗(yàn)比Sentinel弱一些。實(shí)際業(yè)務(wù)中Sentinel的優(yōu)勢主要體現(xiàn)在幾方面細(xì)粒度的實(shí)時(shí)監(jiān)控?cái)?shù)據(jù)、豐富的流控效果快速失敗、Warm Up、排隊(duì)等待、與微服務(wù)體系的控制臺聯(lián)動。這些不是單純一個(gè)算法庫能提供的屬于完整的治理方案。2. 最小可用配置十分鐘接入哨兵2.1 引入依賴和初始化接入Sentinel的第一步是引入依賴。以最常見的Spring Boot項(xiàng)目為例Maven里加上對應(yīng)依賴即可。如果你是Spring Cloud Alibaba體系可以直接引spring-cloud-starter-alibaba-sentinel會連自動配置一起帶進(jìn)來如果是純Spring Boot項(xiàng)目引sentinel-core和sentinel-transport-simple-http也夠用。dependency groupIdcom.alibaba.csp/groupId artifactIdsentinel-core/artifactId version1.8.6/version /dependency !-- 控制臺通信依賴接入dashboard時(shí)需要 -- dependency groupIdcom.alibaba.csp/groupId artifactIdsentinel-transport-simple-http/artifactId version1.8.6/version /dependency初始化代碼很少Sentinel提供了SPI機(jī)制大多數(shù)組件會自動加載。如果是在非Spring環(huán)境里使用手動調(diào)用一下InitExecutor.doInit()也可以強(qiáng)制觸發(fā)初始化。這個(gè)階段最容易忽略的是配置project.name所有接入控制臺的客戶端都會用這個(gè)名字上報(bào)不設(shè)置的話控制臺的“機(jī)器列表”里會看到一個(gè)默認(rèn)名多個(gè)應(yīng)用混在一起很難排查。2.2 用注解和API手動埋點(diǎn)接入后第一件事不是配規(guī)則而是決定在哪里做資源埋點(diǎn)。注解方式最推薦在關(guān)鍵業(yè)務(wù)方法上使用直觀同時(shí)便于維護(hù)SentinelResource(value createOrder, blockHandler handleBlock) public Order createOrder(OrderRequest request) { // 核心業(yè)務(wù)邏輯 } public Order handleBlock(OrderRequest request, BlockException ex) { // 被限流或熔斷后的兜底邏輯 return Order.fallback(); }注意blockHandler方法的簽名必須和原方法一致且多一個(gè)BlockException參數(shù)。這里有個(gè)很容易踩的坑如果不寫blockHandler接口被限流后直接把異常拋給上層用戶看到的就是500錯(cuò)誤而不是一個(gè)優(yōu)雅的降級提示。平時(shí)我看到不少項(xiàng)目過度依賴SentinelResource所有方法都加注解。其實(shí)有些場景適合手動埋點(diǎn)比如被調(diào)用的第三方SDK方法不好加注解時(shí)可以用SphU直接包一層try (Entry entry SphU.entry(cacheGet)) { return cache.get(key); } catch (BlockException ex) { return getFromBackup(key); }埋點(diǎn)要在真實(shí)的熱點(diǎn)路徑上比如查詢接口入口、秒殺下單入口、數(shù)據(jù)庫寫入前而不是在鏈路末端打個(gè)沒意義的標(biāo)記。2.3 三種規(guī)則配置方式規(guī)則配置有硬編碼、通過控制臺推送、通過外部數(shù)據(jù)源拉取三種常見方式。硬編碼方式適合本地驗(yàn)證和測試直接代碼里創(chuàng)建FlowRuleFlowRule rule new FlowRule(); rule.setResource(createOrder); rule.setGrade(RuleConstant.FLOW_GRADE_QPS); rule.setCount(100); FlowRuleManager.loadRules(Collections.singletonList(rule));loadRules一調(diào)用規(guī)則立刻內(nèi)存生效不需要重啟。但生產(chǎn)環(huán)境千萬別這么做每次發(fā)版改規(guī)則都要改代碼而且規(guī)則只存在本地內(nèi)存應(yīng)用重啟規(guī)則就沒了這是硬編碼最大的局限?？刂婆_推送方式指在Dashboard頁面新增流控規(guī)則通過簡單HTTP接口下發(fā)到客戶端內(nèi)存里。好處是可視化壞處是同樣不持久化應(yīng)用重啟后規(guī)則丟失需要重新推一遍。更致命的是多臺實(shí)例時(shí)控制臺會向每臺客戶端分別推送如果有一臺實(shí)例網(wǎng)絡(luò)抖動沒收到該實(shí)例規(guī)則就跟其他實(shí)例不一致。所以生產(chǎn)環(huán)境只用控制臺推規(guī)則等于給自己埋雷。外部數(shù)據(jù)源方式是把規(guī)則放到注冊中心或配置中心客戶端通過DataSource自動監(jiān)聽變化。這是生產(chǎn)環(huán)境推薦方案具體做法下一章展開。2.4 控制臺的安裝與客戶端接入Sentinel控制臺是個(gè)獨(dú)立的Web應(yīng)用官方給出的啟動方式很直接java -Dserver.port8080 \ -Dcsp.sentinel.dashboard.serverlocalhost:8080 \ -Dproject.namesentinel-dashboard \ -jar sentinel-dashboard.jarcsp.sentinel.dashboard.server對控制臺本身來說是注冊到哪個(gè)服務(wù)端默認(rèn)指向自己即可。啟動成功后訪問localhost:8080默認(rèn)賬號密碼都是sentinel?？蛻舳私尤肟刂婆_時(shí)必須指定控制臺地址和應(yīng)用名java -Dcsp.sentinel.dashboard.serverlocalhost:8080 \ -Dproject.nameorder-service \ -jar order-service.jar如果是在Spring Boot的application.properties里配置對應(yīng)是這樣spring.cloud.sentinel.transport.dashboardlocalhost:8080 spring.application.nameorder-service客戶端接入后不會立即出現(xiàn)在控制臺必須等某個(gè)Sentinel資源第一次被訪問產(chǎn)生了統(tǒng)計(jì)數(shù)據(jù)客戶端才會上報(bào)心跳和指標(biāo)。我第一次部署時(shí)在控制臺等機(jī)器列表一直不出現(xiàn)后來臨時(shí)調(diào)了一下接口才發(fā)現(xiàn)是“懶加載”機(jī)制。3. 規(guī)則持久化與動態(tài)推送3.1 為啥規(guī)則老丟很多團(tuán)隊(duì)用控制臺配置完規(guī)則后遇到過一個(gè)詭異現(xiàn)象規(guī)則當(dāng)時(shí)是生效的但應(yīng)用一重啟規(guī)則全部消失還得重新配置。原因就是上一章說的控制臺默認(rèn)模式是把規(guī)則推給客戶端內(nèi)存并沒有落到任何持久化存儲。Sentinel的FlowRuleManager.loadRules只負(fù)責(zé)更新內(nèi)存中的規(guī)則集合它本身沒有“保存到數(shù)據(jù)庫”的邏輯。這種設(shè)計(jì)在線上的問題不止重啟丟規(guī)則。假設(shè)訂單服務(wù)部署了10臺機(jī)器你在控制臺把下單接口的閾值從100改到200控制臺會向每臺機(jī)器的內(nèi)存分別推送新規(guī)則。只要其中一臺推送失敗它留在舊值整個(gè)集群的流控閾值就是不均勻的流量調(diào)度隨機(jī)到這臺機(jī)器時(shí)表現(xiàn)會和別的不一樣。3.2 DataSource機(jī)制解析Sentinel為了解決規(guī)則來源問題抽象出了DataSource接口它負(fù)責(zé)從外部存儲讀取規(guī)則并把變更推送給對應(yīng)RuleManager。核心流程是一個(gè)外部源配置中心或數(shù)據(jù)庫保存規(guī)則內(nèi)容格式通常是JSON字符串。DataSource定時(shí)拉取或者訂閱變更事件。拿到內(nèi)容后通過Converter轉(zhuǎn)換成規(guī)則列表。調(diào)用FlowRuleManager.register2Property(property)或DegradeRuleManager.register2Property(property)把規(guī)則送入對應(yīng)的規(guī)則管理器。讀到這里你會發(fā)現(xiàn)DataSource只是解決了“規(guī)則從哪里加載”的問題至于你怎么往配置中心寫規(guī)則可以手動寫、可以用控制臺改造后寫、也可以寫個(gè)腳本定時(shí)同步。常見可用的數(shù)據(jù)源有Nacos、Zookeeper、Apollo、Etcd核心思想都一樣配置中心是規(guī)則唯一權(quán)威來源。3.3 基于Nacos的規(guī)則持久化實(shí)例以Nacos作為配置中心做一個(gè)最簡單的流控規(guī)則持久化。先引入擴(kuò)展依賴dependency groupIdcom.alibaba.csp/groupId artifactIdsentinel-datasource-nacos/artifactId version1.8.6/version /dependencySpring Boot項(xiàng)目里配置數(shù)據(jù)源BeanConfiguration public class SentinelNacosConfig { Bean public FlowRuleDataSource flowRuleDataSource() { String rule [\n {\n \resource\: \createOrder\,\n \grade\: 1,\n \count\: 100,\n \limitApp\: \default\\n }\n ]; return new FlowRuleDataSource(localhost:8848, sentinel-group, order-create-flow-rules, new NacosConverter()); } private static class NacosConverter implements ConverterString, ListFlowRule { Override public ListFlowRule convert(String source) { return JSON.parseArray(source, FlowRule.class); } } }配置完之后應(yīng)用啟動時(shí)會自動從Nacos拉取規(guī)則后續(xù)Nacos配置變更也會被監(jiān)聽并熱更新。注意幾個(gè)參數(shù)dataId對應(yīng)Nacos配置IDgroup對應(yīng)Nacos分組grade為1表示QPS維度0表示并發(fā)線程數(shù)維度容易配反。實(shí)際生產(chǎn)環(huán)境里我建議把規(guī)則配置放在獨(dú)立的配置文件中不同環(huán)境用不同dataId分段例如order-service-flow-dev、order-service-flow-prod避免測試環(huán)境改閾值影響到生產(chǎn)。3.4 生產(chǎn)環(huán)境規(guī)則治理建議規(guī)則持久化只是第一步規(guī)則治理牽扯到更細(xì)的問題。規(guī)則變更要遵循可追溯原則。每一次修改閾值都算一次變更最好有記錄誰改的、什么時(shí)候改的、從多少改到多少。控制臺本身日志比較弱可以通過改造數(shù)據(jù)源的寫入端統(tǒng)一走公司的配置中心變更審計(jì)這樣出問題時(shí)能查得到。規(guī)則發(fā)布要關(guān)注生效范圍。Nacos配置更新后所有客戶端實(shí)例會同時(shí)收到新規(guī)則。如果新閾值設(shè)置得太激進(jìn)比如從1000改成100全量實(shí)例瞬間收緊流量接口可用性可能大幅下降。穩(wěn)妥的做法是先改一臺實(shí)例的規(guī)則做灰度驗(yàn)證穩(wěn)定后再推全局。還要區(qū)分“業(yè)務(wù)規(guī)則”和“治理規(guī)則”。限流閾值往往和業(yè)務(wù)容量評估、壓測結(jié)果強(qiáng)相關(guān)不是運(yùn)維憑空填一個(gè)數(shù)。每隔一段時(shí)間需要根據(jù)峰值流量回放壓測看當(dāng)前閾值是否合理避免閾值定得太高起不到保護(hù)作用或者定得太低誤傷正常流量。4. 底層原理資源與Slot鏈的協(xié)作4.1 默認(rèn)鏈路從入口到最終攔截Sentinel的底層核心是一個(gè)責(zé)任鏈模式叫ProcessorSlotChain。每個(gè)資源在第一次訪問時(shí)會構(gòu)建一條獨(dú)立的Slot鏈后續(xù)所有經(jīng)過該資源的流量都會在這條鏈上依次過一遍。一條默認(rèn)鏈路包含的主要Slot按順序是NodeSelectorSlot負(fù)責(zé)為當(dāng)前資源創(chuàng)建DefaultNode并把調(diào)用樹上下文綁到當(dāng)前入口。ClusterBuilderSlot負(fù)責(zé)創(chuàng)建ClusterNode用于統(tǒng)計(jì)整個(gè)資源粒度的全局?jǐn)?shù)據(jù)。StatisticSlot最核心的統(tǒng)計(jì)實(shí)例負(fù)責(zé)把請求的通過數(shù)、拒絕數(shù)、RT數(shù)據(jù)寫入滑動窗口。AuthoritySlot做黑白名單校驗(yàn)。SystemSlot做系統(tǒng)負(fù)載保護(hù)。FlowSlot根據(jù)限流規(guī)則判斷是否需要拒絕。DegradeSlot根據(jù)熔斷規(guī)則判斷當(dāng)前資源是否處于熔斷狀態(tài)。我最早看這個(gè)鏈時(shí)很疑惑為什么統(tǒng)計(jì)放在最前面規(guī)則判斷放在后面。后來一想就通了規(guī)則判斷需要依賴統(tǒng)計(jì)數(shù)據(jù)所以先讓StatisticSlot把本次請求寫入統(tǒng)計(jì)窗口隨后FlowSlot讀取窗口數(shù)據(jù)時(shí)就能計(jì)算當(dāng)前QPS是否超限。如果超限拋出BlockException請求在鏈上被攔截如果正常請求繼續(xù)向下走最終進(jìn)入真實(shí)業(yè)務(wù)邏輯。這個(gè)設(shè)計(jì)還有一個(gè)精妙之處StatisticSlot在任何規(guī)則判斷之前都會把原始數(shù)據(jù)采集下來所以即使某個(gè)規(guī)則沒觸發(fā)控制臺依然能看到實(shí)時(shí)指標(biāo)。整個(gè)鏈路像流水線上的傳感器加閘機(jī)傳感器先記錄流量閘機(jī)再決定放不放行。4.2 統(tǒng)計(jì)數(shù)據(jù)的滑動窗口實(shí)現(xiàn)Sentinel統(tǒng)計(jì)的核心不是簡單計(jì)數(shù)器而是一個(gè)滑動窗口。具體實(shí)現(xiàn)類是LeapArray它內(nèi)部維護(hù)一個(gè)環(huán)形數(shù)組數(shù)組每個(gè)元素就是一個(gè)窗口桶WindowWrap。每個(gè)窗口桶里保存了該時(shí)間窗口內(nèi)統(tǒng)計(jì)到的總請求數(shù)、總RT、成功數(shù)、異常數(shù)等指標(biāo)。在默認(rèn)秒級統(tǒng)計(jì)場景下Sentinel把1秒劃分成2個(gè)500毫秒的桶數(shù)組長度也按這個(gè)粒度初始化。當(dāng)時(shí)間推進(jìn)到新的桶周期時(shí)會復(fù)用或覆蓋舊桶數(shù)據(jù)。這樣做的直接好處是QPS計(jì)算不需要額外加鎖讀當(dāng)前時(shí)間所在桶的計(jì)數(shù)除以窗口跨度即可。相比傳統(tǒng)的整秒固定窗口滑動窗口能明顯緩解臨界問題——固定窗口在秒邊界切換瞬間可能出現(xiàn)兩倍流量穿透滑動窗口把粒度細(xì)化統(tǒng)計(jì)更連續(xù)。值得注意的是規(guī)則里的閾值比較是通過ClusterNode的指標(biāo)計(jì)算的不是單機(jī)DefaultNode。這意味著即使在多線程并發(fā)下統(tǒng)計(jì)也能拿到整個(gè)應(yīng)用內(nèi)該資源的總流量。int windowLength 500; // 500ms一個(gè)桶 int sampleCount 2; // 1s內(nèi)2個(gè)桶 long currentQps node.passQps(); // 統(tǒng)計(jì)通過QPS4.3 節(jié)點(diǎn)模型DefaultNode與ClusterNode節(jié)點(diǎn)模型是理解Sentinel統(tǒng)計(jì)隔離性的關(guān)鍵。每個(gè)資源在每次請求入口處會創(chuàng)建DefaultNode它歸屬于當(dāng)前調(diào)用鏈上下文。更準(zhǔn)確地說同一個(gè)資源的DefaultNode在相同Context下是同一個(gè)實(shí)例在不同Context下是不同的實(shí)例。ClusterNode則是資源維度的全局節(jié)點(diǎn)和應(yīng)用入口無關(guān)。FlowSlot做限流判斷時(shí)用的是ClusterNode的統(tǒng)計(jì)值因?yàn)橄蘖麝P(guān)心的是這個(gè)資源總共過來了多少流量而不是某個(gè)上游或某個(gè)調(diào)用關(guān)系單獨(dú)給了多少流量。我自己寫代碼時(shí)有一個(gè)習(xí)慣如果發(fā)現(xiàn)需要對某個(gè)上游來源單獨(dú)限流比如只限制某個(gè)內(nèi)部系統(tǒng)請求這個(gè)接口的頻率那就需要配合AuthoritySlot或者自定義origin白名單邏輯而不是單純依賴默認(rèn)的ClusterNode統(tǒng)計(jì)。5. 限流算法的內(nèi)核與配置取舍5.1 滑動窗口計(jì)數(shù)模型Sentinel的默認(rèn)限流基于滑動窗口計(jì)數(shù)它的判斷邏輯很簡單讀取當(dāng)前滑動窗口內(nèi)已經(jīng)通過的請求數(shù)如果加上當(dāng)前這個(gè)請求會超過閾值就拒絕。舉個(gè)例子閾值QPS100當(dāng)前500ms桶里已經(jīng)通過80個(gè)請求這時(shí)新請求進(jìn)來判斷通過總數(shù)如果即將超過100就攔截。但注意讀到的不是嚴(yán)格的1秒整窗口而是最近若干個(gè)桶的區(qū)間。窗口劃分得越細(xì)統(tǒng)計(jì)越平滑但計(jì)算也越重。Sentinel秒級統(tǒng)計(jì)默認(rèn)2個(gè)桶分鐘級統(tǒng)計(jì)默認(rèn)60個(gè)桶各有各的用途?；瑒哟翱诘膯栴}在于它不是一個(gè)基于排隊(duì)論的平滑算法流量短時(shí)脈沖仍可能瞬時(shí)超過閾值只是不會像固定窗口那樣在窗口翻新瞬間出現(xiàn)雙倍量級的問題。對于絕大多數(shù)接口限流場景這個(gè)精度已經(jīng)足夠。5.2 三種流控效果怎么選配置FlowRule時(shí)controlBehavior字段決定了流量超過閾值后的行為。快速失敗是默認(rèn)模式超過閾值直接拋出BlockException在注解場景下進(jìn)入blockHandler。適合大多數(shù)業(yè)務(wù)接口對調(diào)用方來說語義清晰服務(wù)忙請重試。Warm Up模式適合處理冷系統(tǒng)啟動場景。比如配置了1000 QPS系統(tǒng)剛剛啟動時(shí)不會讓流量一下子全上來而是從一個(gè)較小的值默認(rèn)是閾值的1/3逐漸增長到1000 QPS。我經(jīng)常用在需要預(yù)熱的場景比如頻繁使用Java JIT、連接池剛建立等這個(gè)模式能有效避免冷啟動瞬間被打滿。排隊(duì)等待模式本質(zhì)上是漏桶算法的實(shí)現(xiàn)。請求超閾值后不直接拒絕而是讓它在隊(duì)列里等待以固定的速率放行。適合應(yīng)對突發(fā)性質(zhì)的流量比如消息任務(wù)偶發(fā)大批量執(zhí)行、定時(shí)任務(wù)集中跑批不適合實(shí)時(shí)在線接口請求延遲會明顯變大。FlowRule rule new FlowRule(); rule.setResource(batchJob); rule.setGrade(RuleConstant.FLOW_GRADE_QPS); rule.setCount(50); rule.setControlBehavior(RuleConstant.CONTROL_BEHAVIOR_RATE_LIMITER); rule.setMaxQueueingTimeMs(500);這個(gè)例子里超出的請求最多等500毫秒如果等待超時(shí)還是沒獲得放行直接拒絕。5.3 熔斷降級的狀態(tài)機(jī)與恢復(fù)策略熔斷降級和限流最大區(qū)別在于它關(guān)注的是“被調(diào)用方是否健康”而不是“調(diào)用方有多少流量”。Sentinel的熔斷狀態(tài)有三個(gè)CLOSED關(guān)閉、OPEN打開、HALF_OPEN半開。初始狀態(tài)是CLOSED一切正常。當(dāng)統(tǒng)計(jì)周期內(nèi)慢調(diào)用比例或異常比例達(dá)到閾值熔斷器切換到OPEN接下來所有請求直接走降級邏輯不再真實(shí)調(diào)用下游。OPEN狀態(tài)持續(xù)timeWindow毫秒后自動進(jìn)入HALF_OPEN半開狀態(tài)此時(shí)放行少量探測請求如果探測請求成功熔斷器回到CLOSED如果還失敗重新回到OPEN。我這里有一個(gè)配置經(jīng)驗(yàn)慢調(diào)用比例閾值不能只看平均值要結(jié)合TP99來定。假如TP99本身是200ms你把最大RT定成100ms那幾乎所有請求都會被判成慢調(diào)用接口稍微波動一下直接熔斷恢復(fù)后馬上又熔斷像個(gè)開關(guān)一樣反復(fù)橫跳。初始配置寧愿寬松一點(diǎn)先觸發(fā)了再逐步收緊。DegradeRule degradeRule new DegradeRule(); degradeRule.setResource(getUserInfo); degradeRule.setGrade(RuleConstant.DEGRADE_GRADE_RT); degradeRule.setCount(200); // 最大RT 200ms degradeRule.setTimeWindow(10); // 熔斷10秒 degradeRule.setMinRequestAmount(5); // 至少5個(gè)請求才觸發(fā)統(tǒng)計(jì) degradeRule.setStatIntervalMs(1000);minRequestAmount這個(gè)參數(shù)容易忽略但非常重要。請求量太少的時(shí)候統(tǒng)計(jì)樣本沒有統(tǒng)計(jì)意義可能一個(gè)慢請求就讓整個(gè)接口熔斷。加這個(gè)參數(shù)等于要求“至少積累這么多樣本才能下結(jié)論”。5.4 熱點(diǎn)參數(shù)與系統(tǒng)自適應(yīng)限流常規(guī)流控只針對資源整體熱點(diǎn)參數(shù)限流則細(xì)化到參數(shù)值維度。比如同一個(gè)商品查詢接口全網(wǎng)熱賣商品和普通商品的流量天差地別你希望針對商品ID做精細(xì)化限流某個(gè)熱門商品ID最多每秒查20次其他商品最多每秒查200次。這時(shí)需要用ParamFlowRule指定參數(shù)索引位置。系統(tǒng)自適應(yīng)規(guī)則相對更“大而全”它不會去區(qū)分具體資源而是全局生效。典型配置包括CPU使用率閾值、系統(tǒng)Load閾值、平均RT閾值、入口總QPS閾值、線程數(shù)閾值。其中系統(tǒng)Load的保護(hù)在Linux下才真正可靠因?yàn)橐x系統(tǒng)負(fù)載文件Windows下會退化為不生效。這套規(guī)則特別適合做入口網(wǎng)關(guān)的兜底保護(hù)比如整個(gè)網(wǎng)關(guān)的入口QPS先設(shè)置一個(gè)總量閾值其次再通過每條業(yè)務(wù)線自己的流控規(guī)則細(xì)化形成兩層保護(hù)。優(yōu)先級上系統(tǒng)規(guī)則在最前面防止整機(jī)資源被打滿業(yè)務(wù)規(guī)則在后面做更精準(zhǔn)的接口級控制。6. 常見問題速查與踩坑排雷6.1 規(guī)則不生效怎么查這是出現(xiàn)頻率最高的問題。第一步先確認(rèn)資源名是否一致?？刂婆_配置里寫的資源名必須和代碼埋點(diǎn)里的value一模一樣一個(gè)字符差都不行。很多人控制臺里寫的是接口路徑/order/create代碼里注解寫的是createOrder看起來像是同一個(gè)接口但Sentinel只認(rèn)字符串字面量對不上就是不生效。第二步確認(rèn)是否真的訪問了資源。Sentinel是懶加載的沒有流量經(jīng)過埋點(diǎn)控制臺就不會有該資源的統(tǒng)計(jì)信息規(guī)則自然不會被觸發(fā)。檢查機(jī)器列表里是否能看到應(yīng)用如果看不到說明客戶端跟控制臺心跳都不通更談不上規(guī)則下發(fā)了。第三步看是否有異常被吞掉。比如SentinelResource搭配了兜底方法但兜底方法內(nèi)部被try-catch吃掉了你看到的可能就是接口正常返回掩蓋了限流發(fā)生的事實(shí)。最好在兜底方法里加日志把BlockException的類型打出來快速定位是流控、熔斷、還是系統(tǒng)保護(hù)觸發(fā)的。6.2 監(jiān)控?cái)?shù)據(jù)與預(yù)期不符常見表現(xiàn)是控制臺看到的QPS和壓測工具統(tǒng)計(jì)的TPS對不上。一方面Sentinel控制臺顯示的QPS是經(jīng)過埋點(diǎn)資源統(tǒng)計(jì)的如果埋點(diǎn)位置在網(wǎng)關(guān)之后那就統(tǒng)計(jì)不到網(wǎng)關(guān)前的流量另一方面控制臺指標(biāo)是客戶端定時(shí)上報(bào)的本身有秒級延遲不是實(shí)時(shí)精確值。更隱蔽的一個(gè)坑是多個(gè)實(shí)例的統(tǒng)計(jì)隔離。如果應(yīng)用部署了多臺機(jī)器控制臺上顯示的是單臺機(jī)器的指標(biāo)不是說所有實(shí)例聚合后的總量。你給單機(jī)配額100 QPS兩臺機(jī)器就是200 QPS總?cè)肟诹髁窟@在容量規(guī)劃時(shí)要算清楚。如果發(fā)現(xiàn)壓測流量被限流了但指標(biāo)沒明顯異?？梢钥紤]是不是有Warm Up規(guī)則存在一開始流量被壓低一段時(shí)間后才恢復(fù)也可能是maxQueueingTimeMs設(shè)置過小大量請求排無可排直接拒絕但統(tǒng)計(jì)數(shù)據(jù)里排隊(duì)時(shí)間看著正常。6.3 性能開銷和依賴沖突Sentinel本身的性能開銷主要集中在統(tǒng)計(jì)寫入上由于滑動窗口數(shù)據(jù)結(jié)構(gòu)是預(yù)分配數(shù)組加原子更新正常情況下單次統(tǒng)計(jì)耗時(shí)很短暫不會成為瓶頸。但如果你的業(yè)務(wù)本身QPS已經(jīng)特別高每個(gè)請求又埋了非常多資源點(diǎn)統(tǒng)計(jì)和Slot鏈遍歷的開銷會成倍增加。這種時(shí)候要合理控制埋點(diǎn)粒度盡量在入口處和關(guān)鍵依賴處埋點(diǎn)不要層層埋點(diǎn)。依賴沖突常見于同時(shí)引入老版本Sentinel和應(yīng)用自帶的fastjson或jackson版本不一致導(dǎo)致反序列化規(guī)則JSON報(bào)錯(cuò)。排查方法很簡單看到Converter轉(zhuǎn)ListFlowRule異常時(shí)多數(shù)是JSON庫沖突調(diào)整版本或者用自定義轉(zhuǎn)換器處理。還有一類問題是控制臺版本和客戶端版本不一致。Dashboard版本過舊客戶端用新版本注冊時(shí)可能出現(xiàn)協(xié)議不兼容反饋到現(xiàn)象上是機(jī)器列表不顯示、規(guī)則推不進(jìn)去。我建議客戶端和Dashboard盡量保持同一個(gè)主版本升級時(shí)先升控制臺再升客戶端。6.4 一套推薦的配置落地順序根據(jù)我接入多個(gè)項(xiàng)目的經(jīng)驗(yàn)生產(chǎn)落地不要一上來就堆規(guī)則。建議按這個(gè)順序推進(jìn)先做好資源埋點(diǎn)梳理核心接口和熱點(diǎn)場景保證所有需要治理的入口都有明確的資源名。然后部署控制臺拿到基礎(chǔ)監(jiān)控?cái)?shù)據(jù)搞清每個(gè)接口的真實(shí)QPS、RT、異常率基線。有了基線之后再配限流規(guī)則閾值設(shè)為基線峰值的1.2到1.5倍先寬松后收緊。最后再逐步補(bǔ)充熔斷規(guī)則、熱點(diǎn)參數(shù)規(guī)則和系統(tǒng)規(guī)則每加一條規(guī)則都要觀察一段時(shí)間看觸發(fā)頻率和業(yè)務(wù)影響。規(guī)則之間也會互相作用比如入口QPS規(guī)則和慢調(diào)用熔斷規(guī)則同時(shí)存在時(shí)出現(xiàn)流量突增入口限流先攔掉一批熔斷統(tǒng)計(jì)到的請求數(shù)可能不足以觸發(fā)熔斷。這種時(shí)候要結(jié)合監(jiān)控日志看整個(gè)鏈路而不是盯著某一條規(guī)則調(diào)參。接入Sentinel這件事難點(diǎn)從來不在寫幾行配置而在于你能否回答出“每個(gè)閾值為什么是這個(gè)數(shù)”“每一類規(guī)則到底在保護(hù)哪個(gè)薄弱點(diǎn)”。先把底層原理摸清楚配置只是順?biāo)浦鄣氖?。最后提個(gè)建議所有限流規(guī)則定義完畢之后花半天時(shí)間做一輪全鏈路壓測讓規(guī)則在真實(shí)流量下多跑一會兒這會暴露很多控制臺圖表看不出來的問題。