典型服務架構介紹
典型的互聯網服務訪問鏈路都是分層結構的，從流量入口，到應用層，到后端資源層；其中流量入口可能會有4層負載均衡、7層負載均衡，負載均衡也可能有多層；流量打到應用層之后，就要看具體的業務場景了，不同的業務可能會有不同的依賴請求，包括對第三方服務的或者對緩存、數據庫、隊列等資源的訪問。
┌──────────────────┐
│ LB - layer 4 │
└─────────┬────────┘
│
▼
┌──────────────────┐
│ LB - layer 7 │
└──────────────────┘
│
│
......
│
▼
┌──────────┐ ┌──────────┐
│ App │───────▶│Resources │
└──────────┘ └──────────┘
預案適用場景
此預案的應用場景並不是很多，在一般情況下我們不會啟用這個預案。但是對Nginx入口(上圖LB-layer 7處1)做限流的操作作為一項特殊場景下的預案還是有必要簡單整理下的。
針對合適啟動這個預案需要經過一系列的人工判斷，並且具體是否要啟用這個預案一般是需要經過業務方、運維、依賴方進行討論確認的。
很多時候是否啟動這個預案可能需要依賴一定的經驗來判斷，需要通過多項監控指標來綜合考慮，沒有某一個單一的監控指標可以指導啟用這個方案。
下面簡單描述幾個適用此預案的場景：
- 疑似被刷量，需要配合業務QPS、訪問日志中的來源IP、訪問接口統計來甄別；
- 正常訪問量增長，業務層代理、后端APP、后端資源等無法支撐，並且也沒有可用的擴容資源、或者無法快速擴容；
- 基於極端場景下資源池資源不足，需要舍棄部分非核心業務來保障核心業務的時候，可能會對非核心業務做縮容，此時可能需要配合Nginx入口層的限流策略，避免因為后端縮容導致(非核心)業務完全不可用；
- 異常訪問量，訪問量大幅突增，后端無法支撐，並且無法快速定位、解決異常問題的時候；
監控指標
因為此預案的開啟無法通過單一的監控指標來做判斷，用於輔助判斷是否啟用此預案的監控指標列舉如下：
- 域名QPS歷史趨勢
- 域名訪問日志
- 容器LB、APP層機器(Pod)負載、后端資源負載
操作手冊
相關文檔
- http://nginx.org/en/docs/http/ngx_http_limit_req_module.html#limit_req
- https://www.centos.bz/2017/03/using-nginx-limit_req-limit-user-request-rate/
操作方法
啟用限流需要兩個步驟：
- 在http配置區段中聲明一個limit_req_zone
- 在需要做限流的http、server、location配置區段內部啟用limit_req指令進行限速
配置語法
- limit_req_zone
Syntax:
limit_req_zone key zone=name:size rate=rate [sync];
Default:
—
Context:
http
- limit_req
Syntax:
limit_req zone=name [burst=number] [nodelay | delay=number];
Default:
—
Context:
http, server, location
配置樣例
http {
limit_req_zone $upstream_addr zone=thatsit:100m rate=4000r/s;
server {
server_name thatsit.com；
location / {
limit_req zone=thatsit burst=300 nodelay;
}
}
}
配置解釋
- limit_req_zone
limit_req_zone $upstream_addr zone=thatsit:100m rate=4000r/s;`
聲明一個大小為100M名稱為thatsit的limit_req_zone(會申請一塊共享內存來鍵值的狀態)；
使用$upstream_addr變量來作為存儲鍵值對用的鍵
限制到同一個upstream($upstream_addr)的平均請求頻率為每秒4000 requests；
- limit_req
limit_req zone=thatsit burst=300 nodelay;
在
location /中啟動請求限制，使用名為thatsit的共享內存空間來存儲限流中用到的鍵值對
限制並發數300
請求超過限制之后不做延遲處理，直接響應錯誤，默認的錯誤狀態碼為503，這個狀態碼可以通過limit_req_status指令進行修改
注意事項
- 配置的時候需要綜合考慮請求的平均處理時間來配置請求並發數(burst)和頻率(rates)；
- 需要綜合評估
nodelay參數的影響，默認配置都是開啟delay的，即所有超過限制頻率的請求都會被延遲處理，在請求量高的情況下可能會超過Nginxbacklog的限制； - 我們一般會把這個限制做在LB層，LB層一般都會包含多台機器，在做限制的時候需要做好計算(總的rates限制需要乘以LB服務器的數量)；
limit_req_zone參數支持配置多個變量作為key，可以根據實際需求合理配置；
-
之所以將限流操作放到7層代理來做，是因為7層上可以更方便的基於業務來做配置，會更靈活。針對下文中描述的場景，這個預案是一個棄車保帥的方案，是為了避免特定的業務對整體業務造成影響，或者被迫放棄部分業務流量。 ↩