AHAS 應用防護可以根據服務提供方的能力和服務消費方的分配能力進行流量控制。其中服務提供方(Service Provider)是指對外提供請求的服務或應用;服務消費方(Service Consumer)是指調用該服務的下游應用。
根據服務提供方限流
為了保護服務提供方不被激增的流量拖垮影響穩定性,您可以為其配置 QPS 模式的流控規則。當每秒的請求量超過設定的閾值時,AHAS 將拒絕多余的請求。提供方限流可以分為服務接口限流和服務方法限流。
- 服務接口限流:適用于整個服務接口的 QPS 不超過一定數值的情況。例如:為對應服務接口資源配置 QPS 閾值。
- 服務方法限流:適用于服務的某個方法的 QPS 不超過一定數值的情況。例如:為對應服務方法資源配置 QPS 閾值。
示例:
若應用 A 為服務提供方,其 Web 接口 /queryData
對應的方法是queryData(java.lang.String)
。假設應用 A 最多每秒只能承受 10 次調用。若調用次數超過,則應用 A 宕機。
針對此類場景,可以對應用 A 按服務方法粒度設置流控規則,限制 queryData(java.lang.String)
方法每秒最多只能被調用 10 次,具體操作步驟,參見新建流控規則。若超過閾值,消費方將會收到一個 BlockException
異常,并且快速返回。
根據服務消費方限流
根據消費方限流是指根據調用方的需求來分配服務提供方的處理能力。
示例:
有兩個服務消費者 A 和 B 都向服務提供方發起調用請求,我們希望優先服務消費方 A,而只對來自消費方 B 的請求進行限流。通過對消費方 B 設置限流規則(limitApp)來實現這個目的。
對于默認框架例如 Dubbo,AHAS 會自動解析 Dubbo 消費方的 application name
作為調用方名稱(origin),在進行資源保護的時候都會帶上調用方名稱。而對于非默認框架,只需要在 Sentinel 原有的代碼中加入 ContextUtil.enter(resourceName, origin)
和ContextUtil.exit()
即可。示例代碼如下:
Entry entry = null;
//這里代表消費者 A 的調用
ContextUtil.enter(queryData, "A");
try {
// 資源名可使用任意有業務語義的字符串
entry = SphU.entry("queryData");
// 被保護的業務邏輯
// do something...
} catch (BlockException e1) {
// 資源訪問阻止,被限流或被降級
// 進行相應的處理操作
} finally {
if (entry != null) {
entry.exit();
}
}
//調用結束
ContextUtil.exit();
ContextUtil.enter(xxx)
方法僅在初次調用鏈路入口時才生效,可參考相關 API 文檔。更多設置
限流規則中的 limitApp
(針對來源)支持以下三種選項,分別對應不同的場景:
default
:適用于不區分消費者的場景。來自任何調用者的請求都將進行限流統計。如果這個資源名的調用總和超過了這條規則定義的閾值,則觸發限流。{some_origin_name}
:適用于對特定的消費者限流的場景。只有來自這個調用者的請求才會進行流量控制。例如,資源 A 配置了一條針對消費者 caller1 的規則,那么當且僅當來自消費者 caller1 對資源 A 的請求才會觸發流量控制。
other
:表示針對除{some_origin_name}
以外的其余調用方的流量進行流量控制。這個場景適用于資源對大部分消費者都有一個通用的閾值,對特定消費者有不一樣的閾值的場景。例如,資源 A 可以對大部分消費者可以每秒提供 10 個請求,但是對于消費者 caller1 是個例外,對 caller1 ,每秒可以提供 200 個請求。需配置兩條規則,說明如下:- 為消費者 caller1 配置一條
limitApp
為 caller1 的限流規則,這條規則每秒的最大請求量設置為 200。 - 同時,配置一條
limitApp
為 other 的規則,這條規則每秒的最大請求量設置為 10,那么任意來自非 caller1 對該 resource 的調用,都不能超過 10。
- 為消費者 caller1 配置一條