〇、背景：
各種秒殺大促
天貓雙11電商大促（現象級）
需要保證平臺穩定
穩定性體系的範疇
- 機房佈線
- 網絡通信
- 硬件部署
- 應用架構
- 數據容災
- ……
阿里的技術創新和成果
| 針對方面 | 工具或方法 |
|---|---|
| 限流和降級 | TMD(Taobao Missile Defense) / http_sysguard / Sentinel |
| 流量調度 | 流量調度平臺 |
| 業務開關 | |
| 容量壓測和評估 | 單機最大能力估測方法 |
| 全鏈路壓測 | 全鏈路壓測平臺 |
| 業務一致性 | BCP(Business Check Platform) |
一、限流和降級
原因：由於bug或設計不合理或者業務層次帶來的浪涌（大促）
現象：服務方，服務很忙，節點佔滿，處理緩慢；應用方，響應時間過長
結果：實際上服務方沒有給應用方提供有效服務
結論：服務方需要做好自衛——對於“不受控”的應用方調用應該加以控制
思想：Never half ass 2 things, whole ass 1 thing.
eg：設計容量100w用戶，可實際來了1000w，可以正常處理100w，剩下900w排隊或阻擋
解決步驟
1、服務能力預估
預估服務實例的部署量到底最大能滿足多少業務請求的處理要求
一般選取服務的QPS作爲限流的關鍵判斷指標
不選擇CPU、內存、磁盤IO等資源指標作爲負載判斷依據，是因爲很多情況下系統本身的處理能力處於什麼樣的水位跟這些操作系統資源的使用情況沒有一個清晰地對應關係
2、服務資源監控
從Nginx統一接入流量
3、平臺接入層限流
阿里巴巴在Nginx上擴展組件TMD（Taobao Missile Defense，淘寶導彈防禦系統）
實現限流的同時很好的兼顧安全問題
配置參考：
server {
sysguard on;
sysguard_mode or;
sysguard_load load=10.5 action=/loadlimit;
sysguard_cpu usage=20 period=3s action=/cpulimit;
sysguard_mem swapratio=20% action=/swaplimit;
sysguard_mem free=100M action=/freelimit;
sysguard_rt rt=0.01 period=5s action=/rtlimit;
location /loadlimit {
return 503;
}
location /swaplimit {
return 503;
}
location /freelimit {
return 503;
}
location /rtlimit {
return 503;
}
location /cpulimit {
return 503;
}
}cpu_usage = [(cur.usr + cur.nice + cur.sys) - (pre.usr + pre.nice + pre.sys)]/
[(cur.usr + cur.nice + cur.sys + cur.iowait + cur.irq
+ cur.softirq + cur.idle)
- (pre.usr + pre.nice + pre.sys + pre.iowait + pre.irq
+ pre.softirq + pre.idle)] * 100
4、服務層限流
傳統方法：通過Spring的AOP機制，定義一個advice攔截器，重寫before方法
傳統方法存在的問題
重複工作：100個接口限流需要配置100個advice和編寫100個攔截器
硬編碼：沒有統一管理和配置
手段單一：僅能對上游過載做限制，需要結合服務調用上下游進行更靈活的配置
無全局管控：缺乏統一的監控平臺
算法粗糙：對於“雙十一”這種特殊場景，會看到毛刺現象，需要更平滑的限流算法
阿里的服務層限流平臺Sentinel
二、流量調度
局部問題影響整體的原因
（1）分佈式服務環境調用鏈局部問題會被放大到整個鏈路
（2）單點、局部問題會被放大成面
三、容量壓測與評估規劃
服務實例單機最大處理能力的估測方法的考量
（1）實用性
（2）準確性
（3）高效性
容量壓測
容量分析預測
四、全鏈路壓測
（1）基礎數據抽取
（2）鏈路與模型構造
（3）鏈路驗證
（4）業務改造
（5）數據平臺
（6）流量平臺
（7）影子表（數據隔離）
（8）中間件改造
（9）安全機制
