CTO眼中系統容量的評估

1. 用戶訪問網站的過程

DNS解析->防火牆->WAF->代理服務器->應用服務器

• 用戶在瀏覽器上輸入網址域名或者打開APP

• DNS解析域名獲取到服務器的IP

• 發起TCP鏈接請求，創建TCP鏈接

• 發送HTTP請求

• 代理服務器（Nginx）轉發HTTP請求

• WEB服務器接收HTTP請求，處理後返回響應

• 客戶端收到響應數據，渲染頁面，展現給用戶

https請求過程稍微有點不一樣，它會請求服務器的443端口，服務器端要安裝SSL證書，在客戶端和服務器之間創建起一條SSL安全加密通道，使得請求在傳輸過程當中將不會被查看、竊取和修改。

爲了提升網站/APP響應速度和成功率，大部分都採用了CDN，CDN解決了地區分佈、帶寬、服務器性能帶來的訪問延遲問題，適用於靜態文件加速、點播、直播等場景，用戶可就近取得所需內容。

CDN使用了DNS的CNAME技術，在用戶訪問某網頁、視頻等資源時，會將域名指向另外一個CDN中定義的域名，再解析成另外一個IP地址來供客戶端進行訪問，使客戶端訪問時進行加速。

2.爲了評估系統的總體性能，先看一下經常使用指標的基本定義

• 併發數：系統同時處理的請求數。

• 響應時間（RT）：Response Time：客戶端發一個請求開始計時，到客戶端接收到從服務器端返回的響應結果結束所經歷的時間，響應時間由請求發送時間、網絡傳輸時間和服務器處理時間三部分組成。

• TPS：Transactions Per Second，指服務器每秒處理的事務次數，例以下單、支付的性能。

• QPS：Queries Per Second，指服務器每秒處理的查詢次數，例如瀏覽商品，查詢訂單的性能。

• QPS（TPS） = 併發數  /  平均響應時間，假設1秒鐘200個請求，處理每一個請求平均須要2秒，那麼QPS = 200 / 2 = 100

• PV（Page View）：頁面訪問量，即頁面瀏覽量或點擊量，用戶每次刷新即被計算一次

• UV（Unique Visitor）：獨立訪客，統計1天內訪問某站點的用戶數(以cookie爲依據)

• 峯值QPS：天天80%的訪問集中在20%的時間裏，這20%時間叫作峯值時間，公式：( 總PV數 * 80% ) / ( 天天秒數 * 20% ) = 峯值時間每秒請求數（QPS）

3.電商大促狀況下，系統是否能夠撐得住，咱們如何來評估？

• 流量來源：小程序、H五、APP

• 大促流量預估：根據歷史經驗值，以及推廣力度，預估出大促期間的PV，UV

• 當前各鏈路容量統計：網絡接入層—DNS/防火牆/WAF/F5，應用接入層—Nginx，Web應用層—tomcat，服務層—dubbo，消息層—mq，數據層—db/redis，主要考察服務器配置（CPU+內存），單機容量

• 核心鏈路梳理：交易，風控，基礎服務等核心系統

• 核心鏈路監控：服務器監控zabbix、業務監控平臺ump，參考技術（六），設置好監控閾值

• 壓測：線上/線下、讀寫/仿真/引流/集羣隔離/縮容壓測、單機/集羣/全鏈路（最關鍵的就是壓測）

• 預案，參考個人另一篇CTO眼中的系統高可用

舉例：

若是促銷10分鐘內，預估100萬PV，那麼它的峯值QPS = 1000000  / （10 * 60）≈ 1667，若是A服務單機容量在50%水位時(以單機的50%資源使用率做爲擴容依據)，QPS = 500，爲保障服務高可用，預留30%機器資源作擴容buffer，那麼A服務線上須要部署的機器數爲：(1 + 30%)  * (1667/500）= 4.3 ，取整5，因此最終A服務線上須要部署5臺服務器。

以上只是一個基本的預估算法，實際上要複雜的多，由於涉及到整個鏈路以及互相依賴的服務，最關鍵的一點是梳理清楚全部的依賴關係，哪些能夠降級，哪些是強依賴，相對於的服務器也須要擴容，因此平時作好壓測，是保證服務高可用的收效手段，同時應急預案也要完善。

當年設計的一個支持100萬用戶同時在線、20萬併發的直播答題系統的容量預估，上線後，最高80萬以上用戶同時在線，系統平穩運營，沒出現故障。

容量評估準確與否，直接影響到大促的效果，以及用戶對平臺的信任，因此做爲技術決策者，務必要了解基本的方法論。