系統部署架構
降級設計
系統壓測
系統部署架構
非設計架構
- 必須使用SLB
- 不能出現單點
- RDS高可用，支持主備
- 業務日誌統一分析
降級設計
步驟：
- 梳理功能模塊，按照功能重要程度，用戶側更重要
- 實現時儘量不要和業務耦合，確保開關高可用
- 對優先級低的增加開關，可隨時關閉低優先級功能，確保高優先級可用，因爲往往低優先級會連帶高優先級發生雪崩效應
- 開關演練，要確保開關生效，要對生產環境下進行演練
系統壓測
- QPS：服務器每秒收到的請求次數
- RT：接口的整體平均響應時間，峯值<=100ms
- 總CPU利用率<=70%
- 內存利用率<=80%
- 峯值錯誤率（統計非200）<=0.1%
- load：CPU負載，linux特有的指標，要求峯值load1（1分鐘內）<CPU總核數-0.5，假設CPU 1s能處理100個請求，CPU隊列有50個請求，則CPU負載爲0.5，CPU隊列有100個請求，則CPU負載爲1。
步驟：
- 梳理重要接口，重要場景，大流量接口
- 制定測試方法，構造測試數據，如模擬的用戶，評估壓測流量，要求歷史峯值的3倍
- 執行壓測，晚間低谷10：00以後，必須壓線上環境，同時觀察監控
- 整理壓測報告，QPS，RT等
系統常見問題梳理
1.慢SQL原因
錯誤：
SQL包含業務邏輯
多表聯合查詢，
索引設計不合理，where條件要加索引
使用like跳過索引
查詢儘量精簡，一個sql一張表
2.Redis，讀寫比高的場景多用，全局分佈式鎖，因爲redis天然是單進程的
3.系統內部調用使用RPC，不要用HTTP
4.靜態資源使用nginx，不要用tomcat
5.ECS比數據庫更容易擴容，多用ECS（應用層）計算數據，比如排序
6.HTTP也是可以用連接池的，比如Aapche-HttpClient