網際網路效能與容量評估的方法論和典型案例
1 背景
本文歡迎轉載，轉載請註明原文連結，並附作者個人資訊李豔鵬。
效能至上
武林中，“天下武功出少林”指中國各門各派的武功都與少林武學有一定的淵源，技術也是相同的道理，所有的技術最終體現在計算機知識的基本功上，這些基本功是技術的易筋經，是“內功”，一些年輕的攻城獅更熱衷於追崇高大上的框架，過去在炒SSH，現在在炒Spring Cloud，這些對框架掌握的程度體現在“劍術”上，我推薦每個技術研發人員在修煉好內功的基礎上，再去練“劍術”。回頭看IT行業的發展，先有傳統行業，再有網際網路，傳統行業和網際網路是少林與武當的關係，他們的技術相輔相成，並不一定是網際網路的技術要比傳統行業的技術高深很多，而是它們有自己的側重點，傳統行業更偏向於企業級開發，專案具有業務複雜、流程豐富、中心化管理、企業級抽象度高、業務重用率高的特點，而網際網路傾向於把複雜的業務進行拆分成單一的職責，對於單一職責模組的非功能質量進行大幅度的優化，這包括高可用性、高效能、可伸縮、可擴充套件、安全性、穩定性、可維護性、健壯性等。
這篇文章提供一個基本的面向網際網路技術評審的方法論，它主要論述在網際網路的行業裡，如何在完成產品功能的前提下，更好的滿足非功能質量的需求，是每個網際網路程式設計人員和架構設計人員都應該掌握的一項基本技能。
2 目標
2.1 非功能質量需求的概述
通過參考技術評審指標，保證系統架構設計滿足使用者和系統對非功能質量的需求：
核心非功能質量：
| 核心質量 | 描述 |
|---|---|
| 高效能 | 執行效率高，價效比高 |
| 可用性 | 持續可用性，縮短宕機時間，出錯恢復，可靠性 |
| 可伸縮 | 垂直伸縮，水平伸縮 |
| 可擴充套件 | 可插拔，元件重用 |
| 安全性 | 資料安全，加密，熔斷，防攻擊 |
其他非功能質量：
| 其他質量 | 描述 |
|---|---|
| 可監控性 | 快速發現，快速定位，快速解決 |
| 可測試性 | 可灰度，可預覽，可Mock，可拆解 |
| 魯棒性 | 容錯性，可恢復性 |
| 可維護性 | 易於維護，監控，運營，擴充套件 |
| 可重用性 | 可移植性，解耦 |
| 易用性 | 可操作性 |
2.2 非功能質量需求的具體指標
主要分為4部分：應用伺服器、資料庫、快取和訊息佇列。
2.2.1 應用伺服器
應用伺服器是服務的入口，請求流量從這裡進入系統，資料庫，快取和訊息佇列的訪問量取決於應用伺服器的訪問量，對應用伺服器的訪問量進行評估至關重要，應用伺服器主要關心每秒請求的峰值，請求響應時間等指標，通過這些指標可以評估需要的應用伺服器資源的數量。
全面考慮下列指標：
| 指標分類 | 部署結構 | 容量和效能 | 其他 |
|---|---|---|---|
| 1 | 負載均衡策略 | 每天請求量 | 請求的內容是否包含大物件 |
| 2 | 高可用策略 | 各介面訪問峰值 | GC收集器的選型和配置 |
| 3 | IO模型（NIO/BIO） | 平均請求相應時間 | |
| 4 | 執行緒池模型 | 最大請求相應時間 | |
| 5 | 執行緒池執行緒數量 | 線上使用者量 | |
| 6 | 是否多業務混布 | 請求大小 | |
| 7 | 網絡卡IO流量 | ||
| 8 | 磁碟IO負載 | ||
| 9 | 記憶體使用情況 | ||
| 10 | CPU使用情況 |
2.2.2 資料庫
根據應用層的訪問量和訪問峰值，計算出需要的資料庫資源的QPS，TPS，每天的資料總量等，由此來評估所需資料庫資源的數量和配置，部署結構等。
全面考慮下列指標：
| 指標分類 | 部署結構 | 容量和效能 | 其他 |
|---|---|---|---|
| 1 | 複製模型 | 當前資料容量 | 查詢是否走索引 |
| 2 | 失效轉移策略 | 每天資料增量（預估容量） | 有沒有大資料量的查詢 |
| 3 | 容災策略 | 每秒讀峰值 | 有沒有多表關聯，關聯是否用到索引 |
| 4 | 歸檔策略 | 每秒寫峰值 | 有沒有使用悲觀鎖，是否可以改造成樂觀鎖，或者是否可以利用資料庫內建行級鎖 |
| 5 | 讀寫分離策略 | 事務量 | 事務和一致性級別 |
| 6 | 分庫分表(分片)策略 | 使用的JDBC資料來源型別，連線數等配置 | |
| 7 | 靜態資料和半靜態資料是否使用快取 | 是否開啟JDBC診斷日誌 | |
| 8 | 有沒有考慮快取穿透壓垮資料庫的情況 | 有沒有儲存過程 | |
| 9 | 快取失效和快取資料預熱策略 | 伸縮策略（分割槽表，自然時間分表，水平分庫分表） | |
| 10 | 快取失效和快取資料預熱策略 | 水平分庫分表實現方法（客戶端，代理，Nosql） |
2.2.3 快取
根據應用層的訪問量和訪問峰值，通過評估熱資料佔比，計算出的快取資源的大小，存取快取資源的峰值，由此來計算所需快取資源的數量和配置，部署結構等。
全面考慮下列指標：
| 序號/指標分類 | 部署結構 | 容量與效能 | 其他 |
|---|---|---|---|
| 1 | 複製模型 | 快取內容的大小 | 冷熱資料比例 |
| 2 | 失效轉移 | 快取內容的數量 | 是否有可能快取穿透 |
| 3 | 持久策略 | 快取內容的過期時間 | 是否有大物件 |
| 4 | 淘汰策略 | 快取的資料結構 | 是否使用快取實現分散式鎖 |
| 5 | 執行緒模型 | 每秒讀峰值 | 是否使用快取支援的指令碼 |
| 6 | 預熱方法 | 每秒寫峰值 | 是否避免了Race Condition |
| 7 | 分片Hash策略 | 快取分片方法（客戶端，代理，叢集） |
2.2.4 訊息佇列
根據應用層的訪問量和訪問峰值，計算需要訊息佇列傳遞的資料內容和資料量，計算出的訊息佇列資源的數量和配置，部署結構等。
全面考慮下列指標：
| 指標分類 | 部署結構 | 容量與效能 | 其他 |
|---|---|---|---|
| 1 | 複製模型 | 每天平均資料增量 | 消費執行緒池模型 |
| 2 | 失效轉移 | 訊息持久的過期時間 | 分片策略 |
| 3 | 持久策略 | 每秒讀峰值 | 訊息的可靠投遞 |
| 4 | 每秒寫峰值 | ||
| 5 | 每條訊息的大小 | ||
| 6 | 平均延遲 | ||
| 7 | 最大延遲 |
3 技術評審提綱
業務專案千差萬別，沒有一個統一的方法論完成架構設計和技術評審，架構設計只需要從某些關鍵點來表達系統即可，提綱就是用來幫助大家做架構評審的工具，幫助大家整理思路並形成可實施的方案，因此在做系統設計時，可有選擇性的參考此提綱，根據業務特點來完成一個可實現的有效的架構設計。
3.1 現狀
業務背景
- 專案名稱
- 業務描述
技術背景
- 架構描述
- 當前系統容量（系統呼叫量平均值）
- 當前系統呼叫量峰值
3.2 需求
業務需求
- 要改造的內容
- 要實現的新需求
效能需求
- 預估系統容量（預估系統呼叫量平均值）
- 預估系統呼叫量峰值
- 其他非功能質量，例如：安全性、可伸縮等
3.3 方案描述
方案1
整個方案需要參考技術評審指標提出的各方面指標來考慮滿足系統的非功能質量需求。
-
概述
一句話概括方案的亮點，比如說: 雙寫，主從分離，分庫分表，擴容，歸檔等。
-
詳細說明
方案的具體描述，文字描述不清楚的話可以結合圖（任何圖：UML，概念圖，框圖等）的方式說明，如果是改造方案最好突出變動的地方，以下列舉了幾種描述的角度：
- 中介軟體架構（應用伺服器、資料庫、快取、訊息佇列等）
- 邏輯架構（模組劃分、模組通訊、資訊流、時序等）
- 資料架構（資料結構、資料分佈、拆分策略、快取策略、讀寫分離策略、查詢策略、資料一致性策略）
- 異常處理，容災策略，灰度釋出
-
效能評估
給出方案的基準資料，並按效能需求評估需要使用的資源數量。
- 單機併發量
- 單機容量
- 按照預估效能需求，預估資源數量(應用伺服器、快取、儲存、佇列等)
- 伸縮方式
-
方案優缺點
列出方案的優缺點，優缺點要具有確定性，不要有“存在一定風險”這種描述，也就是要量化。
方案2
整個方案需要參考技術評審指標提出的各方面指標來考慮滿足系統的非功能質量需求。
......
3.4 方案對比
對比可選方案，並給出選擇這種方案的理由，選擇傾向的方案，
3.5 風險評估
標識所選方案的風險，提出解決此風險發生時候的應對策略，比如：上線失敗時的回滾策略。
3.6 工作量評估
描述使用所選方案需要做的具體工作，並評估開發、測試等細化任務需要的時間，形成可實施的任務計劃表，任務計劃表推薦採用簡單的表格形式，減少工具使用和學習的成本。
4 效能和容量評估經典案例
4.1 背景
物流系統包含如下兩個質量優先需求：
- 維護會員常用地址，下單時提供會員地址列表。
- 下單時非同步產生物流訂單，物流系統後臺任務從第三方物流輪循拉取物流狀態，已經下單使用者查詢訂單的物流訂單和物流記錄。
由於會員數量較大，可能有較快的增長速度，訂單數量更是巨大，促銷期峰值的訂單產生量可能很高，這兩個業務模組的資料儲存需要分庫分表，並藉助訊息佇列和快取抗寫和讀的流量，因此，本方案主要涉及這兩個業務的容量評估。
4.2 目標資料量級
選取行業內一線電商平臺的量級作為目標：
- 會員量2億，平均增長5萬/天。
- 平時訂單量400萬/天，所有訂單下單時段集中在9:00-23:00，促銷日訂單量1400萬/天，50%訂單下單時段集中在晚上7:30-8:30和晚上22:00-23:00。
4.3 量級評估標準
通用標準
- 容量按照峰值5倍冗餘計算。
- 會員常用地址容量按照30年計算，而物流訂單時效性較強按照3年計算。
- 第三方查詢介面5000 QPS。
Mysql
- 單埠讀：1000 QPS
- 單埠寫：700 TPS
- 單表容量：5000萬條
Redis
- 單埠讀：4萬 QPS
- 單埠寫：4萬 TPS
- 單埠記憶體容量：32G
Kafka
- 單機讀：3萬 QPS
- 單機寫：5000 TPS
應用伺服器
- 請求量每秒峰值：5000 QPS
4.4 方案
方案1. 最大效能方案
由於整個電商網站剛剛上線，資料量級還無法清晰的確定，我們根據行業內知名電商當前資料量級設計最大效能方案，本方案可以應對行業內電商巨頭的各種促銷所帶來的服務請求峰值，並且擁有最快的響應時間，達到服務效能的最大化。
需求1. 會員常用地址
整體流程：
- 提供Restful服務增加會員常用地址。
- 提供Restful服務獲取會員常用地址列表。
資料庫資源評估：
讀QPS：
會員每次下單，拉取一次會員地址列表，按照促銷日訂單量1400萬/天，50%訂單下單時段集中在兩個小時內計算：
(1400萬 × 0.5) / (2 × 60 × 60) = 1000/秒
容量評估按照5倍冗餘計算，讀QPS峰值1000/秒 * 5 = 5000/秒，需要5埠資料庫服務讀。
寫TPS：
假設每天增加的會員全部新增一次常用地址，並且高峰期會員下訂單時有20%的會員會增加一條常用地址：
(1400萬 × 0.2 + 5萬) / (2 × 60 × 60) = 400/秒
容量評估按照5倍冗餘計算，400/秒 * 5 = 2000/秒，需要3埠資料庫服務寫。
資料容量：
當前有2億會員，每天增長5萬會員，平均每個會員有5個常用地址，30年會員常用地址表數量計算：
（2億 + 5萬 × 365 × 30年） × 5 = 35億
容量評估按照5倍冗餘計算，35億 * 5 = 175億，需要350張表即可容納。
根據以上讀QPS、寫TPS的評估，如果讀寫混布我們共需要8埠，可以使用8主8備，如果讀寫分離，我們需要做主從部署，需要3主6從，與2倍數對齊，使用4主8從即可。
根據表容量，需要350張表，和2的指數對齊，選擇512張表，上面計算需要主庫埠為4，考慮到將來埠擴充套件不用拆分資料庫，儘量設計更多的庫，使用32個庫。
設計結果：4埠 × 32庫 × 4表， 4主8從
快取資源評估：
為了提高使用者下單的體驗，需要使用Redis快取活躍使用者的常用地址。
定義當天下訂單的會員為活躍會員，活躍會員的地址快取24小時，假定每天下訂單的會員均為不同會員，每個會員有5個常用地址，快取大小計算如下：
1400萬 × 5 × 1k = 70G
容量評估按照5倍冗餘計算，70G×5=350G，按照每臺Redis 32G記憶體計算，需要11臺機器，根據資料庫對資料存取QPS/TPS的設計，11臺機器完全可以滿足5000/秒的讀QPS和2000/秒的寫TPS。
設計結果：11臺，主從
應用伺服器資源評估：
根據資料庫的讀QPS（5000/s）峰值和寫TPS（2000/s）峰值計算，單臺應用伺服器即可，選擇2臺避免單點。
設計結果：2臺
需求2. 物流訂單和物流記錄
整體流程：
- 訂單提交後，通過訊息佇列產生物流訂單，訊息傳入物流系統，物流系統消費物流訂單訊息然後入庫。
- 後臺任務輪循未完成物流訂單，查詢第三方物流介面狀態，填寫物流記錄資訊。按照每天1400萬的訂單，訂單平均3天到貨，第三方查詢介面5000 QPS，每次狀態查詢需要時間計算如下： 1400萬 × 3 / 5000 = 8400 / 60 / 60 = 2小時，定時任務2小時查一次。
- 提供REST服務獲取物流訂單資訊。
- 提供REST服務獲取物流記錄資訊。
- 提供REST服務獲取物流訂單和物流記錄資訊。
資料庫資源評估：
讀QPS：
會員下單三天到貨，三天內50%客戶會查詢一次物流訂單和一次物流記錄，計算如下：
(1400萬 × 3 × 0.5) / (24 × 60 × 60) = 250/秒
容量評估按照5倍冗餘計算，2 × 250/秒 × 5倍 = 2500/秒，需要3埠資料庫服務讀。
寫TPS：
會員每次下單，產生一次物流訂單，按照促銷日訂單量1400萬/天，50%訂單下單時段集中在兩個小時內計算：
(1400萬 × 0.5) / (2 × 60 × 60) = 1000/秒
按照每天1400萬的訂單，訂單平均3天到貨，每條物流訂單產生8條物流記錄，並且8條物流記錄在三天內均勻產生，物流記錄寫TPS計算如下：
1400萬 × 3 × 8 / 3 / （24 × 60 × 60） = 1200/秒
容量評估按照5倍冗餘計算，(1000/秒 + 1200/秒) * 5 = 11000/秒，需要15埠資料庫服務寫。
資料容量：
當前2億物流訂單積累，每天增長400萬訂單，30年訂單數量計算：
2億 + 400萬 × 365天 × 3年 = 46億
容量評估按照5倍冗餘計算，46億 * 5 = 230億，需要460張表即可容納, 物流記錄表是物流訂單的8倍，460 × 8 = 3680張表。
根據以上讀QPS和寫TPS，如果讀寫混布，我們共需要18埠，18主18備，如果讀寫分離，我們需要16主16從。
根據表容量，需要3680張表，和2的指數對齊，選擇4096張表，上面計算需要主庫埠為16，考慮到將來埠擴充套件不用拆分資料庫，儘量設計更多的庫，使用32個庫。
設計結果：16埠 × 32庫 × 8表，16主16從
訊息佇列資源評估：
為了讓系統能夠應對峰值的突增，採用訊息佇列Kafka接收物流訂單。
根據上面對寫TPS的計算，考慮5倍冗餘後，峰值為5000/秒，單臺Kafka和單臺處理機即可處理。
如果峰值有突增，可以增加Kafaka叢集的節點來抗寫流量，處理機根據後端入庫效能來決定。例如寫峰值增加10倍，達到5萬/秒，需要10臺Kafka，每臺Kafka讀QPS可達3萬，理論上需要2臺處理機，然而，處理機的瓶頸是後端入庫的寫TPS，根據上面計算，入庫的寫TPS峰值按照5000/秒設計，因此，單臺處理機即可，這個場景下會有訊息的堆積，但是最終會處理完畢，達到消峰的效果。
設計結果：1臺Kafka，主從，1臺處理機
應用伺服器資源評估：
根據資料庫的讀QPS（2500/s）峰值和寫TPS（11000/s）峰值計算，3臺應用伺服器即可。
用於查詢第三方介面的後臺任務伺服器，由於受到第三方介面5000/s的QPS的限制，單臺機器即可，為了避免單點，2臺處理機即可。
設計結果：2臺
方案2. 最小資源方案
由於當前系統線上資料量並不多，增長量也不大，讀QPS和寫TPS單臺機器完全可以處理，暫時不考慮使用快取和訊息佇列，但是保留使用快取和訊息佇列的介面，如果快取和訊息佇列的資源可用，可以通過開關進行切換。
當前的資料量使用單庫單表即可處理，然而，考慮到將來擴容方便，資料庫埠暫時使用一個，但是保留我們在最大效能方案中對資料庫的分庫分表，當讀QPS和寫TPS突增時，DBA可以把庫重新拆分到多個埠來抗請求流量。
因此，方案如下：
會員常用地址
設計結果：1埠 × 32庫 × 16表， 1主1從
物流訂單和物流記錄
設計結果：1埠 × 128庫 × 32表，1主1從
4.5 總結
傾向於採用最小資源方案：
- 當前線上流量並不大，使用最小資源方案節省成本。
- 最小資源方案充分的考慮了資料庫的分庫分表，當讀QPS和寫TPS突增時，DBA可以拆分庫到不同的埠，也就是增加埠來應對。
- 最小資源方案在應用層設計了開關，如果效能突增可以臨時申請和開啟快取和訊息佇列。
5 效能評估參考標準
以下標準是使用PC X86機器的經驗值，僅供參考，評審時應該隨著機器的不同而做調整。
通用標準
- 容量按照峰值5倍冗餘計算。
- 分庫分表後的容量一般可儲存30年的資料。
- 第三方查詢介面5000 QPS。
- 單條資料庫記錄佔用大約1K空間。
Mysql
- 單埠讀：1000 QPS
- 單埠寫：700 TPS
- 單表容量：5000萬條
Redis
- 單埠讀：4萬 QPS
- 單埠寫：4萬 TPS
- 單埠記憶體容量：32G
Kafka
- 單機讀：3萬 QPS
- 單機寫：5000 TPS
DB2
- 單機讀峰值：20000
- 單機寫峰值：20000
- 單表容量：1億資料
6 總結
本文以網際網路企業重點關注的非功能質量為主線，總結了非功能質量需求的總體目標，並針對不同的服務和資源列舉了不同的非功能質量需求，幫助讀者在做技術評審的過程整理思路，儘量窮舉評審時關注的評審點，並隨後提供了一個簡單有效的評審提綱，最後根據提綱實現一個網際網路容量和效能評估的經典案例，大家可以在案例中瞭解高併發網際網路系統是如何進行拆分的，以及依據哪些資料進行拆分。
由於本文的資料完全是基於筆者在某個網際網路平臺下的經驗而記錄的，並不代表可以直接應用在任何企業和平臺上，這裡重點突出進行容量和效能評估的方法論，幫助大家整理實現高併發網際網路系統的思路。
根據本文的容量評估，我們需要分散式的中介軟體支援對資料庫、快取和訊息佇列的水平伸縮和分片，想了解分散式中介軟體的原理，請參考開源專案。