1、前言

我們?cè)谶M(jìn)行分布式系統(tǒng)的開(kāi)發(fā)中，無(wú)論是在開(kāi)發(fā)環(huán)境還是發(fā)布環(huán)境，配置一定不能是內(nèi)存形式的，因?yàn)橄到y(tǒng)可能會(huì)在中途宕機(jī)或者重啟，所以如果放在內(nèi)存中，那么配置在服務(wù)停到就是就會(huì)消失，那么此時(shí)就需要重新再進(jìn)行配置，一個(gè)兩個(gè)服務(wù)還好，如果服務(wù)一多，那就是一件很費(fèi)時(shí)費(fèi)力的事情了。
所以我們還是需要把我們的配置信息持久化到配置中心，這也是目前主流的方式。

分布式系統(tǒng)中常見(jiàn)的配置中心有Nacos、ZooKeeper、Apollo、Consul等等，
本文中使用Nacos作為配置中心和服務(wù)中心。

配置持久化主要有以下原因：

1. 數(shù)據(jù)安全性：持久化配置可以保證在系統(tǒng)或者應(yīng)用重啟后，重要的配置數(shù)據(jù)不會(huì)丟失，可以確保數(shù)據(jù)的安全性和穩(wěn)定性。
2. 數(shù)據(jù)可恢復(fù)性：持久化配置可以在數(shù)據(jù)丟失或者損壞時(shí)進(jìn)行恢復(fù)，保證系統(tǒng)的正常運(yùn)行。
3. 支持分布式系統(tǒng)：對(duì)于分布式系統(tǒng)來(lái)說(shuō)，配置的持久化可以確保各個(gè)節(jié)點(diǎn)的一致性，避免因?yàn)楣?jié)點(diǎn)的臨時(shí)變動(dòng)導(dǎo)致的問(wèn)題。
4. 可擴(kuò)展性：持久化配置易于進(jìn)行擴(kuò)展和修改，可以適應(yīng)不同的應(yīng)用場(chǎng)景和業(yè)務(wù)需求。
5. 提高系統(tǒng)性能：通過(guò)實(shí)現(xiàn)配置的持久化，可以有效減少讀取配置文件的次數(shù)，提高系統(tǒng)的運(yùn)行效率。
6. 降低耦合性：持久化配置可以使得應(yīng)用和配置之間松散耦合，方便系統(tǒng)的維護(hù)和升級(jí)。

2、微服務(wù)整合Sentinel和Nacos

在分布式的系統(tǒng)中，微服務(wù)是最基本的要求，所以我們就需要對(duì)微服務(wù)進(jìn)行服務(wù)注冊(cè)發(fā)現(xiàn)、配置和流控。

2.1、引入依賴

在微服務(wù)整合sentinel和Nacos是需要父pom中已經(jīng)引入了spring-cloud-alibaba-dependencies這個(gè)依賴，這個(gè)依賴中管理里當(dāng)前版本中所有組件的版本信息。切記：在微服務(wù)中要特別注意各種依賴的版本。

<!--nacos服務(wù)注冊(cè)與發(fā)現(xiàn)-->
<dependency><groupId>com.alibaba.cloud</groupId><artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
</dependency><!--nacos配置中心-->
<dependency><groupId>com.alibaba.cloud</groupId><artifactId>spring-cloud-starter-alibaba-nacos-config</artifactId>
</dependency><!--sentinel依賴-->
<dependency><groupId>com.alibaba.cloud</groupId><artifactId>spring-cloud-starter-alibaba-sentinel</artifactId>
</dependency><!--以nacos作為sentinel數(shù)據(jù)源的依賴-->
<dependency><groupId>com.alibaba.csp</groupId><artifactId>sentinel-datasource-nacos</artifactId>
</dependency>

2.2、application.yaml文件的編寫(xiě)

spring:application:name: ${application_name}main:banner-mode: offlazy-initialization: truecloud:nacos: # 配置nacos信息discovery:server-addr: ${nacos_server}config:server-addr: ${nacos_server}file-extension: yaml

因?yàn)槲覀冇胣acos作為了配置中心，我們可以將sentinel的基本配置放入到nacos中就可以了，所以當(dāng)前服務(wù)的yaml配置文件中只需要寫(xiě)一些基本的配置就可以了。

2.3、在Nacos中配置sentinel信息

spring:cloud:sentinel:transport:dashboard: localhost:8080 ##sentinel的控制面板地址datasource: # sentinel用nacos作為數(shù)據(jù)源的配置flux-control: # 流控管理（這個(gè)名稱可以自定義）nacos: # 告訴sentinel用nacos作為數(shù)據(jù)源data-id: feign-test_flux-control_config.json # 配置中心里執(zhí)行文件的dataIdserver-addr: ${nacos_server} # nacos的地址rule-type: flow # 指定文件配置的是那種規(guī)則degrade-control: # 熔斷管理（這個(gè)名稱可以自定義）nacos:data-id: feign-test_degrade-control_config.jsonserver-addr: ${nacos_server}rule-type: degradeparam-flow-control: # 熱點(diǎn)參數(shù)管理（這個(gè)名稱可以自定義）nacos:data-id: feign_test-hot_flux-config.jsonserver-addr: ${nacos_server}rule-type: param-flow

我們使用nacos配置文件來(lái)對(duì)服務(wù)進(jìn)行流控、熔斷等操作，所以就需要有以下幾個(gè)必須的參數(shù)：

1. data-id：需要告訴sentinel讀取配置中心中的哪個(gè)配置文件。
2. rule-type：告訴sentinel配置文件配置的控制規(guī)則，flow：流控、degrade：熔斷、param-flow熱點(diǎn)參數(shù)，想看有哪些規(guī)則參數(shù)可以查看com.alibaba.cloud.sentinel.datasource包下的枚舉類：RuleType。

public enum RuleType {FLOW("flow", FlowRule.class),DEGRADE("degrade", DegradeRule.class),PARAM_FLOW("param-flow", ParamFlowRule.class),SYSTEM("system", SystemRule.class),AUTHORITY("authority", AuthorityRule.class),GW_FLOW("gw-flow", "com.alibaba.csp.sentinel.adapter.gateway.common.rule.GatewayFlowRule"),GW_API_GROUP("gw-api-group", "com.alibaba.csp.sentinel.adapter.gateway.common.api.ApiDefinition");//省略部分代碼
}

2.4、配置信息

我們這里使用的是配置文件的形式對(duì)sentinel的控制信息進(jìn)行持久化，所以會(huì)存在一個(gè)問(wèn)題：nacos中的配置文件對(duì)于sentinel來(lái)講是單項(xiàng)數(shù)據(jù)讀入，sentinel能監(jiān)聽(tīng)到nacos中配置的變化，但是我們?cè)趕entinel中修改了配置，nacos是不會(huì)監(jiān)聽(tīng)到并進(jìn)行修改。
如果想進(jìn)行雙向綁定，就需要對(duì)sentinel的代碼進(jìn)行修改。

2.4.1、流控配置

流控指的是流量控制，也稱作限流。它主要是用來(lái)限制每單位時(shí)間進(jìn)入系統(tǒng)的請(qǐng)求數(shù)量，主要用來(lái)保證系統(tǒng)的可用性，防止大流量把系統(tǒng)壓死。

[{"resource": "/test", // 資源名"limitApp": "default", // // 針對(duì)來(lái)源，若為 default 則不區(qū)分調(diào)用來(lái)源"grade": 1, // 限流閾值類型(1:QPS;  0:并發(fā)線程數(shù)）"count": 1, // 閾值"clusterMode": false, // 是否是集群模式"controlBehavior": 0, // 流控效果 (0:快速失敗;  1:Warm Up(預(yù)熱模式);  2:排隊(duì)等待)"strategy": 0,  // 流控模式(0:直接； 1:關(guān)聯(lián); 2:鏈路)"warmUpPeriodSec": 10, // 預(yù)熱時(shí)間（秒，預(yù)熱模式需要此參數(shù)）"maxQueueingTimeMs": 500, // 超時(shí)時(shí)間（排隊(duì)等待模式需要此參數(shù)）"refResource": "rrr" // 關(guān)聯(lián)資源、入口資源(關(guān)聯(lián)、鏈路模式)}
]

2.4.2、熔斷降級(jí)配置

在微服務(wù)中，熔斷降級(jí)是一種保障服務(wù)穩(wěn)定性的策略。
熔斷降級(jí)可以簡(jiǎn)單理解為一個(gè)“保險(xiǎn)絲”的作用。當(dāng)某個(gè)服務(wù)發(fā)生嚴(yán)重故障（例如超時(shí)、異常等），為了防止整個(gè)系統(tǒng)的崩潰，會(huì)切斷對(duì)這個(gè)服務(wù)的調(diào)用。這就像電流過(guò)大，保險(xiǎn)絲會(huì)熔斷以保護(hù)電路。

具體來(lái)說(shuō)，熔斷降級(jí)有兩個(gè)目的：

防止應(yīng)用程序不斷地嘗試執(zhí)行可能會(huì)失敗的操作給系統(tǒng)造成“雪崩”。
當(dāng)某個(gè)服務(wù)提供者發(fā)生故障的時(shí)候，向調(diào)用方返回一個(gè)錯(cuò)誤響應(yīng)或者替代響應(yīng)，而不是讓調(diào)用方等待超時(shí)。
這樣，即使個(gè)別服務(wù)出現(xiàn)問(wèn)題，整個(gè)系統(tǒng)的運(yùn)行也不會(huì)受到影響，這就是熔斷降級(jí)的作用。

[{"resource": "/degrade","grade": 0, // 熔斷策略，支持慢調(diào)用比例（0），異常比例（1），異常數(shù)（2）策略"count": 1000, // 慢調(diào)用比例模式下為慢調(diào)用臨界 RT（超出該值計(jì)為慢調(diào)用，單位ms）；異常比例/異常數(shù)模式下為對(duì)應(yīng)的閾值"slowRatioThreshold": 0.1,// 慢調(diào)用比例閾值，僅慢調(diào)用比例模式有效（1.8.0 引入）"minRequestAmount":  10, //熔斷觸發(fā)的最小請(qǐng)求數(shù)，請(qǐng)求數(shù)小于該值時(shí)即使異常比率超出閾值也不會(huì)熔斷"timeWindow": 10, // 熔斷時(shí)長(zhǎng)，單位為 s"statIntervalMs": 1000 // 統(tǒng)計(jì)時(shí)長(zhǎng)（單位為 ms），如 60*1000 代表分鐘級(jí)}
]	

2.4.3、熱點(diǎn)參數(shù)配置

在微服務(wù)中，熱點(diǎn)參數(shù)限流是一種特殊的限流方法。

熱點(diǎn)參數(shù)限流主要是對(duì)參數(shù)值相同的請(qǐng)求進(jìn)行分別統(tǒng)計(jì)，判斷是否超過(guò)每秒事務(wù)處理量（QPS）的閾值。這種方法相較于傳統(tǒng)的限流方式，更精細(xì)化和個(gè)性化，可以針對(duì)具體的應(yīng)用和服務(wù)的瓶頸進(jìn)行限流。

例如，在一個(gè)微服務(wù)系統(tǒng)中，“查詢用戶信息”這個(gè)服務(wù)可能存在一個(gè)熱點(diǎn)參數(shù)“用戶ID”，我們可以通過(guò)熱點(diǎn)參數(shù)限流來(lái)控制單位時(shí)間內(nèi)對(duì)同一個(gè)用戶ID的查詢請(qǐng)求數(shù)量，防止因?yàn)槟硞€(gè)熱點(diǎn)的參數(shù)導(dǎo)致整體服務(wù)的故障。

[{"resource": "/test1","grade": 1, // 限流模式（QPS 模式，不可更改）"paramIdx": 0, // 參數(shù)索引"count": 13, // 單機(jī)閾值"durationInSec": 6, // 統(tǒng)計(jì)窗口時(shí)長(zhǎng)"clusterMode": false, // 是否集群 默認(rèn)false"controlBehavior": 0, // 流控效果（支持快速失敗和勻速排隊(duì)模式）"limitApp": "default",// 高級(jí)選項(xiàng)"paramFlowItemList": [{"classType": "int", // 參數(shù)類型"count": 222, // 限流閾值"object": "2" // 參數(shù)值}]}
]

2.4.4、系統(tǒng)規(guī)則配置

系統(tǒng)規(guī)則是用于定義和配置分布式系統(tǒng)的流量控制和防護(hù)的一種策略。

可以根據(jù)不同的維度（如Load、CPU使用率、總體平均RT、入口QPS和并發(fā)線程數(shù)等）來(lái)設(shè)定系統(tǒng)保護(hù)規(guī)則，以保證系統(tǒng)的入口流量和系統(tǒng)的負(fù)載達(dá)到一個(gè)平衡，讓系統(tǒng)盡可能跑在最大吞吐量的同時(shí)保證系統(tǒng)整體的穩(wěn)定性。

[{"avgRt": 1, // RT"highestCpuUsage": -1, // CPU 使用率"highestSystemLoad": -1, // LOAD"maxThread": -1, // 線程數(shù)"qps": -1, // 入口 QPS"count": 55, // 閾值，在CPU使用率中是百分比}
]

2.4.5、授權(quán)規(guī)則配置

授權(quán)規(guī)則是用于控制服務(wù)請(qǐng)求者訪問(wèn)受保護(hù)資源的一種權(quán)限判斷。它可以基于請(qǐng)求的來(lái)源或其他因素，對(duì)請(qǐng)求進(jìn)行授權(quán)或者拒絕。

授權(quán)規(guī)則有多種實(shí)現(xiàn)方式，例如白名單和黑名單。白名單是允許來(lái)源在白名單內(nèi)的調(diào)用者訪問(wèn)受保護(hù)資源，而黑名單則是禁止來(lái)源在黑名單內(nèi)的調(diào)用者訪問(wèn)受保護(hù)資源。

在Sentinel中，可以通過(guò)自定義RequestOriginParser接口，從請(qǐng)求對(duì)象中獲取請(qǐng)求者的來(lái)源，并按照白名單或黑名單的規(guī)則進(jìn)行授權(quán)判斷。

[{"resource": "sentinel_spring_web_context","limitApp": "/test","strategy": 0 // 授權(quán)類型(0代表白名單；1代表黑名單。)}
]

3、Gateway整合Sentinel和Nacos

在分布式系統(tǒng)中，一般使用Gateway網(wǎng)關(guān)來(lái)作為系統(tǒng)的入口，整合了網(wǎng)關(guān)后，請(qǐng)求會(huì)通過(guò)Gateway進(jìn)行轉(zhuǎn)發(fā)，就相當(dāng)于Servlet中的forward，轉(zhuǎn)發(fā)過(guò)程不會(huì)在瀏覽器中進(jìn)行記錄。
所以當(dāng)我們?yōu)橄到y(tǒng)添加了Gateway之后，我們就可以不為每一個(gè)微服務(wù)添加流控效果了，只需要在Gateway中設(shè)置流控就可以了。

我們?cè)贕ateway中進(jìn)行流控、熔斷等操作，resource指的就是我們的服務(wù)名稱。

3.1、流控配置

Gateway的流控配置和普通的流控配置不一樣。

[{"resource": "feign-test",  // 資源名"resourceMode": 0, // API類型, 0: ROUTE ID區(qū)分, 1: API"count": 1, // 閾值，QPS類型就是限制時(shí)間間隔的請(qǐng)求數(shù)，線程數(shù)類型就是指并行的線程數(shù)"grade": 1, // 閾值類型，0：線程數(shù)，1：QPS"controlBehavior": 2, // 流控方式，0：快速失敗，2：勻速排隊(duì)"intervalSec": 10, // 間隔，單位是秒"burst": 0, // burst，只有在快速失敗時(shí)才有效"maxQueueingTimeoutMs": 1000 // 超時(shí)時(shí)間，單位是毫秒}
]

3.1.1、網(wǎng)關(guān)流控的所有配置參數(shù)

參數(shù)名	參數(shù)描述
resourceMode	API類型，0：ROUTE ID，1：API
resource	資源名
grade	閾值類型，0：線程數(shù)，1：QPS
count	閾值，QPS類型就是限制時(shí)間間隔的請(qǐng)求數(shù)，線程數(shù)類型就是指并行的線程數(shù)
intervalSec	間隔 ，單位是秒
controlBehavior	流控方式，0：快速失敗，2：勻速排隊(duì)
burst	額外流量，快速失敗流控方式下，允許突出的流量數(shù)
maxQueueingTimeoutMs	排隊(duì)時(shí)間，單位是毫秒，勻速排隊(duì)流控方式下，允許排隊(duì)的時(shí)間
paramItem	請(qǐng)求屬性key，json對(duì)象，為配置的json key，value就是余下的配置項(xiàng)
parseStrategy	參數(shù)屬性，0 ：ClientIP，1：RemoteHost，2：Header ，3：URL參數(shù)，4 Cookie
fieldName	參數(shù)名稱，若參數(shù)屬性選擇 Header 模式或 URL 參數(shù)模式，則需要指定對(duì)應(yīng)的 header 名稱或 URL 參數(shù)名稱
matchStrategy	參數(shù)值匹配策略，0： 精確匹配，1：子串查詢匹配，2：正則表達(dá)式匹配
pattern	參數(shù)值匹配內(nèi)容，按匹配策略來(lái)配置的值，只有匹配該模式的請(qǐng)求屬性值會(huì)納入統(tǒng)計(jì)和流控；若為空則統(tǒng)計(jì)該請(qǐng)求屬性的所有值。

3.1.2、注意事項(xiàng)

1. 參數(shù)值如果是數(shù)字，那么字符串和數(shù)字都可以。
2. 當(dāng)Gateway使用了流控配置的持久化，那么sentinel中datasource配置下的rule-type參數(shù)值就得是gw_flow, 不能是flow，但也不是一定不能。

spring:cloud:sentinel:transport:dashboard: http://localhost:8080datasource:flow-control:nacos:server-addr: ${nacos_server}data-id: gateway_flux-control_config.json
#            rule-type: flowrule-type: gw_flow

1、如果配置的是flow，那么在sentinle中就不會(huì)顯示處Gateway的流控配置，但是不影響功能。
2、如果配置的是gw_flow，才會(huì)在sentinel中顯示Gateway的流控配置，同時(shí)也不影響功能。

3.2、熔斷降級(jí)配置

Gateway的熔斷降級(jí)配置和之前的配置是一樣的。

[{"resource": "feign-test", // 資源名"count": 1000, // 當(dāng)熔斷策略是慢調(diào)用時(shí)，此值為最大RT，單位是毫秒。當(dāng)熔斷是策略是異常比例時(shí)，此值為異常比例。當(dāng)熔斷策略是異常數(shù)時(shí)，此值為異常數(shù)目"timeWindow": 5, // 熔斷時(shí)長(zhǎng)，單位是秒"grade": 0, // 0: 慢調(diào)用， 1: 異常比例，2:異常數(shù)"minRequestAmount": 2,  // 最小請(qǐng)求數(shù)"slowRatioThreshold": 0.2, // 比例閾值"statIntervalMs": 10000 // 統(tǒng)計(jì)時(shí)長(zhǎng)，單位毫秒}
]