互聯(lián)網(wǎng)性能與容量評估的方法論和典型案例
1 背景
武林中，“天下武功出少林”指中國各門各派的武功都與少林武學有一定的淵源，技術(shù)也是相同的道理，所有的技術(shù)最終體現(xiàn)在計算機知識的基本功上，這些基本功是技術(shù)的易筋經(jīng)，是“內(nèi)功”，一些年輕的攻城獅更熱衷于追崇高大上的框架，過去在炒SSH，現(xiàn)在在炒Spring Cloud，這些對框架掌握的程度體現(xiàn)在“劍術(shù)”上，我推薦每個技術(shù)研發(fā)人員在修煉好內(nèi)功的基礎(chǔ)上，再去練“劍術(shù)”。回頭看IT行業(yè)的發(fā)展，先有傳統(tǒng)行業(yè)，再有互聯(lián)網(wǎng)，傳統(tǒng)行業(yè)和互聯(lián)網(wǎng)是少林與武當?shù)年P(guān)系，他們的技術(shù)相輔相成，并不一定是互聯(lián)網(wǎng)的技術(shù)要比傳統(tǒng)行業(yè)的技術(shù)高深很多，而是它們有自己的側(cè)重點，傳統(tǒng)行業(yè)更偏向于企業(yè)級開發(fā)，項目具有業(yè)務(wù)復雜、流程豐富、中心化管理、企業(yè)級抽象度高、業(yè)務(wù)重用率高的特點，而互聯(lián)網(wǎng)傾向于把復雜的業(yè)務(wù)進行拆分成單一的職責，對于單一職責模塊的非功能質(zhì)量進行大幅度的優(yōu)化，這包括高可用性、高性能、可伸縮、可擴展、安全性、穩(wěn)定性、可維護性、健壯性等。
這篇文章提供一個基本的面向互聯(lián)網(wǎng)技術(shù)評審的方法論，它主要論述在互聯(lián)網(wǎng)的行業(yè)里，如何在完成產(chǎn)品功能的前提下，更好的滿足非功能質(zhì)量的需求，是每個互聯(lián)網(wǎng)程序設(shè)計人員和架構(gòu)設(shè)計人員都應(yīng)該掌握的一項基本技能。
本文的目的是為了初入互聯(lián)網(wǎng)或者有意愿踏入互聯(lián)網(wǎng)的研發(fā)人員起到拋磚引玉的效果，如果想全面了解互聯(lián)網(wǎng)非功能質(zhì)量設(shè)計的方方面面，可以參考美國互聯(lián)網(wǎng)方法論Architecture Tradeoff Analysis Method。
2 目標
2.1 非功能質(zhì)量需求的概述
通過參考技術(shù)評審指標，保證系統(tǒng)架構(gòu)設(shè)計滿足用戶和系統(tǒng)對非功能質(zhì)量的需求：
核心非功能質(zhì)量：
其他非功能質(zhì)量：
2.2 非功能質(zhì)量需求的具體指標
主要分為4部分：應(yīng)用服務(wù)器、數(shù)據(jù)庫、緩存和消息隊列。
2.2.1 應(yīng)用服務(wù)器
應(yīng)用服務(wù)器是服務(wù)的入口，請求流量從這里進入系統(tǒng)，數(shù)據(jù)庫，緩存和消息隊列的訪問量取決于應(yīng)用服務(wù)器的訪問量，對應(yīng)用服務(wù)器的訪問量進行評估至關(guān)重要，應(yīng)用服務(wù)器主要關(guān)心每秒請求的峰值，請求響應(yīng)時間等指標，通過這些指標可以評估需要的應(yīng)用服務(wù)器資源的數(shù)量。
全面考慮下列指標：
2.2.2 數(shù)據(jù)庫
根據(jù)應(yīng)用層的訪問量和訪問峰值，計算出需要的數(shù)據(jù)庫資源的QPS，TPS，每天的數(shù)據(jù)總量等，由此來評估所需數(shù)據(jù)庫資源的數(shù)量和配置，部署結(jié)構(gòu)等。
全面考慮下列指標：
2.2.3 緩存
根據(jù)應(yīng)用層的訪問量和訪問峰值，通過評估熱數(shù)據(jù)占比，計算出的緩存資源的大小，存取緩存資源的峰值，由此來計算所需緩存資源的數(shù)量和配置，部署結(jié)構(gòu)等。
全面考慮下列指標：
序號/指標分類部署結(jié)構(gòu)容量與性能其他
1復制模型緩存內(nèi)容的大小冷熱數(shù)據(jù)比例
2失效轉(zhuǎn)移緩存內(nèi)容的數(shù)量是否有可能緩存穿透
3持久策略緩存內(nèi)容的過期時間是否有大對象
4淘汰策略緩存的數(shù)據(jù)結(jié)構(gòu)是否使用緩存實現(xiàn)分布式鎖
5線程模型每秒讀峰值是否使用緩存支持的腳本
6預熱方法每秒寫峰值是否避免了Race Condition
7分片Hash策略緩存分片方法(客戶端，代理，集群)
2.2.4 消息隊列
根據(jù)應(yīng)用層的訪問量和訪問峰值，計算需要消息隊列傳遞的數(shù)據(jù)內(nèi)容和數(shù)據(jù)量，計算出的消息隊列資源的數(shù)量和配置，部署結(jié)構(gòu)等。
全面考慮下列指標：
3 技術(shù)評審提綱
業(yè)務(wù)項目千差萬別，沒有一個統(tǒng)一的方法論完成架構(gòu)設(shè)計和技術(shù)評審，架構(gòu)設(shè)計只需要從某些關(guān)鍵點來表達系統(tǒng)即可，提綱就是用來幫助大家做架構(gòu)評審的工具，幫助大家整理思路并形成可實施的方案，因此在做系統(tǒng)設(shè)計時，可有選擇性的參考此提綱，根據(jù)業(yè)務(wù)特點來完成一個可實現(xiàn)的有效的架構(gòu)設(shè)計。
3.1 現(xiàn)狀
項目名稱
- 業(yè)務(wù)背景
- 業(yè)務(wù)描述
技術(shù)背景
- 架構(gòu)描述
- 當前系統(tǒng)容量(系統(tǒng)調(diào)用量平均值)
- 當前系統(tǒng)調(diào)用量峰值
3.2 需求
業(yè)務(wù)需求
- 要改造的內(nèi)容
- 要實現(xiàn)的新需求
性能需求
- 預估系統(tǒng)容量(預估系統(tǒng)調(diào)用量平均值)
- 預估系統(tǒng)調(diào)用量峰值
- 其他非功能質(zhì)量，例如：安全性、可伸縮等
3.3 方案描述
方案1
- 概述
一句話概括方案的亮點，比如說: 雙寫，主從分離，分庫分表，擴容，歸檔等。
- 詳細說明
方案的具體描述，文字描述不清楚的話可以結(jié)合圖(任何圖：UML，概念圖，框圖等)的方式說明，如果是改造方案***突出變動的地方，以下列舉了幾種描述的角度：
中間件架構(gòu)(應(yīng)用服務(wù)器、數(shù)據(jù)庫、緩存、消息隊列等)
邏輯架構(gòu)(模塊劃分、模塊通信、信息流、時序等)
數(shù)據(jù)架構(gòu)(數(shù)據(jù)結(jié)構(gòu)、數(shù)據(jù)分布、拆分策略、緩存策略、讀寫分離策略、查詢策略、數(shù)據(jù)一致性策略)
異常處理，容災(zāi)策略，灰度發(fā)布
- 性能評估
給出方案的基準數(shù)據(jù)，并按性能需求評估需要使用的資源數(shù)量。
單機并發(fā)量
單機容量
按照預估性能需求，預估資源數(shù)量(應(yīng)用服務(wù)器、緩存、存儲、隊列等)
伸縮方式
- 方案優(yōu)缺點
列出方案的優(yōu)缺點，優(yōu)缺點要具有確定性，不要有“存在一定風險”這種描述，也就是要量化。
方案2
整個方案需要參考技術(shù)評審指標提出的各方面指標來考慮滿足系統(tǒng)的非功能質(zhì)量需求。
......
3.4 方案對比
對比可選方案，并給出選擇這種方案的理由，選擇傾向的方案，
3.5 風險評估
標識所選方案的風險，提出解決此風險發(fā)生時候的應(yīng)對策略，比如：上線失敗時的回滾策略。
3.6 工作量評估
描述使用所選方案需要做的具體工作，并評估開發(fā)、測試等細化任務(wù)需要的時間，形成可實施的任務(wù)計劃表，任務(wù)計劃表推薦采用簡單的表格形式，減少工具使用和學習的成本。
4 性能和容量評估經(jīng)典案例
4.1 背景
物流系統(tǒng)包含如下兩個質(zhì)量優(yōu)先需求：
- 維護會員常用地址，下單時提供會員地址列表。
- 下單時異步產(chǎn)生物流訂單，物流系統(tǒng)后臺任務(wù)從第三方物流輪循拉取物流狀態(tài)，已經(jīng)下單用戶查詢訂單的物流訂單和物流記錄。
由于會員數(shù)量較大，可能有較快的增長速度，訂單數(shù)量更是巨大，促銷期峰值的訂單產(chǎn)生量可能很高，這兩個業(yè)務(wù)模塊的數(shù)據(jù)存儲需要分庫分表，并借助消息隊列和緩存抗寫和讀的流量，因此，本方案主要涉及這兩個業(yè)務(wù)的容量評估。
4.2 目標數(shù)據(jù)量級
選取行業(yè)內(nèi)一線電商平臺的量級作為目標：
- 會員量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
- 單端口內(nèi)存容量：32G
Kafka
- 單機讀：3萬 QPS
- 單機寫：5000 TPS
應(yīng)用服務(wù)器
- 請求量每秒峰值：5000 QPS
4.4 方案
方案1. ***性能方案
由于整個電商網(wǎng)站剛剛上線，數(shù)據(jù)量級還無法清晰的確定，我們根據(jù)行業(yè)內(nèi)知名電商當前數(shù)據(jù)量級設(shè)計***性能方案，本方案可以應(yīng)對行業(yè)內(nèi)電商巨頭的各種促銷所帶來的服務(wù)請求峰值，并且擁有最快的響應(yīng)時間，達到服務(wù)性能的***化。
需求1. 會員常用地址
整體流程：
- 提供Restful服務(wù)增加會員常用地址。
- 提供Restful服務(wù)獲取會員常用地址列表。
數(shù)據(jù)庫資源評估：
讀QPS：
會員每次下單，拉取一次會員地址列表，按照促銷日訂單量1400萬/天，50%訂單下單時段集中在兩個小時內(nèi)計算：
(1400萬 × 0.5) / (2 × 60 × 60) = 1000/秒
容量評估按照5倍冗余計算，讀QPS峰值1000/秒 * 5 = 5000/秒，需要5端口數(shù)據(jù)庫服務(wù)讀。
寫TPS：
假設(shè)每天增加的會員全部添加一次常用地址，并且高峰期會員下訂單時有20%的會員會增加一條常用地址：
(1400萬 × 0.2 + 5萬) / (2 × 60 × 60) = 400/秒
容量評估按照5倍冗余計算，400/秒 * 5 = 2000/秒，需要3端口數(shù)據(jù)庫服務(wù)寫。
數(shù)據(jù)容量：
當前有2億會員，每天增長5萬會員，平均每個會員有5個常用地址，30年會員常用地址表數(shù)量計算：
(2億 + 5萬 × 365 × 30年) × 5 = 35億
容量評估按照5倍冗余計算，35億 * 5 = 175億，需要350張表即可容納。
根據(jù)以上讀QPS、寫TPS的評估，如果讀寫混布我們共需要8端口，可以使用8主8備，如果讀寫分離，我們需要做主從部署，需要3主6從，與2倍數(shù)對齊，使用4主8從即可。
根據(jù)表容量，需要350張表，和2的指數(shù)對齊，選擇512張表，上面計算需要主庫端口為4，考慮到將來端口擴展不用拆分數(shù)據(jù)庫，盡量設(shè)計更多的庫，使用32個庫。
設(shè)計結(jié)果：4端口 × 32庫 × 4表， 4主8從
緩存資源評估：
為了提高用戶下單的體驗，需要使用Redis緩存活躍用戶的常用地址。
定義當天下訂單的會員為活躍會員，活躍會員的地址緩存24小時，假定每天下訂單的會員均為不同會員，每個會員有5個常用地址，緩存大小計算如下：
1400萬 × 5 × 1k = 70G
容量評估按照5倍冗余計算，70G×5=350G，按照每臺Redis 32G內(nèi)存計算，需要11臺機器，根據(jù)數(shù)據(jù)庫對數(shù)據(jù)存取QPS/TPS的設(shè)計，11臺機器完全可以滿足5000/秒的讀QPS和2000/秒的寫TPS。
設(shè)計結(jié)果：11臺，主從
應(yīng)用服務(wù)器資源評估：
根據(jù)數(shù)據(jù)庫的讀QPS(5000/s)峰值和寫TPS(2000/s)峰值計算，單臺應(yīng)用服務(wù)器即可，選擇2臺避免單點。
設(shè)計結(jié)果：2臺
需求2. 物流訂單和物流記錄
整體流程：
- 訂單提交后，通過消息隊列產(chǎn)生物流訂單，消息傳入物流系統(tǒng)，物流系統(tǒng)消費物流訂單消息然后入庫。
- 后臺任務(wù)輪循未完成物流訂單，查詢第三方物流接口狀態(tài)，填寫物流記錄信息。按照每天1400萬的訂單，訂單平均3天到貨，第三方查詢接口5000 QPS，每次狀態(tài)查詢需要時間計算如下： 1400萬 × 3 / 5000 = 8400 / 60 / 60 = 2小時，定時任務(wù)2小時查一次。
- 提供REST服務(wù)獲取物流訂單信息。
- 提供REST服務(wù)獲取物流記錄信息。
- 提供REST服務(wù)獲取物流訂單和物流記錄信息。
數(shù)據(jù)庫資源評估：
讀QPS：
會員下單三天到貨，三天內(nèi)50%客戶會查詢一次物流訂單和一次物流記錄，計算如下：
(1400萬 × 3 × 0.5) / (24 × 60 × 60) = 250/秒
容量評估按照5倍冗余計算，2 × 250/秒 × 5倍 = 2500/秒，需要3端口數(shù)據(jù)庫服務(wù)讀。
寫TPS：
會員每次下單，產(chǎn)生一次物流訂單，按照促銷日訂單量1400萬/天，50%訂單下單時段集中在兩個小時內(nèi)計算：
(1400萬 × 0.5) / (2 × 60 × 60) = 1000/秒
按照每天1400萬的訂單，訂單平均3天到貨，每條物流訂單產(chǎn)生8條物流記錄，并且8條物流記錄在三天內(nèi)均勻產(chǎn)生，物流記錄寫TPS計算如下：
1400萬 × 3 × 8 / 3 / (24 × 60 × 60) = 1200/秒
容量評估按照5倍冗余計算，(1000/秒 + 1200/秒) * 5 = 11000/秒，需要15端口數(shù)據(jù)庫服務(wù)寫。
數(shù)據(jù)容量：
當前2億物流訂單積累，每天增長400萬訂單，30年訂單數(shù)量計算：
2億 + 400萬 × 365天 × 3年 = 46億
容量評估按照5倍冗余計算，46億 * 5 = 230億，需要460張表即可容納, 物流記錄表是物流訂單的8倍，460 × 8 = 3680張表。
根據(jù)以上讀QPS和寫TPS，如果讀寫混布，我們共需要18端口，18主18備，如果讀寫分離，我們需要16主16從。
根據(jù)表容量，需要3680張表，和2的指數(shù)對齊，選擇4096張表，上面計算需要主庫端口為16，考慮到將來端口擴展不用拆分數(shù)據(jù)庫，盡量設(shè)計更多的庫，使用32個庫。
設(shè)計結(jié)果：16端口 × 32庫 × 8表，16主16從
消息隊列資源評估：
為了讓系統(tǒng)能夠應(yīng)對峰值的突增，采用消息隊列Kafka接收物流訂單。
根據(jù)上面對寫TPS的計算，考慮5倍冗余后，峰值為5000/秒，單臺Kafka和單臺處理機即可處理。
如果峰值有突增，可以增加Kafaka集群的節(jié)點來抗寫流量，處理機根據(jù)后端入庫性能來決定。例如寫峰值增加10倍，達到5萬/秒，需要10臺Kafka，每臺Kafka讀QPS可達3萬，理論上需要2臺處理機，然而，處理機的瓶頸是后端入庫的寫TPS，根據(jù)上面計算，入庫的寫TPS峰值按照5000/秒設(shè)計，因此，單臺處理機即可，這個場景下會有消息的堆積，但是最終會處理完畢，達到消峰的效果。
設(shè)計結(jié)果：1臺Kafka，主從，1臺處理機
應(yīng)用服務(wù)器資源評估：
根據(jù)數(shù)據(jù)庫的讀QPS(2500/s)峰值和寫TPS(11000/s)峰值計算，3臺應(yīng)用服務(wù)器即可。
用于查詢第三方接口的后臺任務(wù)服務(wù)器，由于受到第三方接口5000/s的QPS的限制，單臺機器即可，為了避免單點，2臺處理機即可。
設(shè)計結(jié)果：2臺
方案2. 最小資源方案
由于當前系統(tǒng)線上數(shù)據(jù)量并不多，增長量也不大，讀QPS和寫TPS單臺機器完全可以處理，暫時不考慮使用緩存和消息隊列，但是保留使用緩存和消息隊列的接口，如果緩存和消息隊列的資源可用，可以通過開關(guān)進行切換。
當前的數(shù)據(jù)量使用單庫單表即可處理，然而，考慮到將來擴容方便，數(shù)據(jù)庫端口暫時使用一個，但是保留我們在***性能方案中對數(shù)據(jù)庫的分庫分表，當讀QPS和寫TPS突增時，DBA可以把庫重新拆分到多個端口來抗請求流量。
因此，方案如下：
會員常用地址
設(shè)計結(jié)果：1端口 × 32庫 × 16表， 1主1從
物流訂單和物流記錄
設(shè)計結(jié)果：1端口 × 128庫 × 32表，1主1從
4.5 總結(jié)
傾向于采用最小資源方案：
當前線上流量并不大，使用最小資源方案節(jié)省成本。
最小資源方案充分的考慮了數(shù)據(jù)庫的分庫分表，當讀QPS和寫TPS突增時，DBA可以拆分庫到不同的端口，也就是增加端口來應(yīng)對。
最小資源方案在應(yīng)用層設(shè)計了開關(guān)，如果性能突增可以臨時申請和開啟緩存和消息隊列。
5 性能評估參考標準
以下標準是使用PC X86機器的經(jīng)驗值，僅供參考，評審時應(yīng)該隨著機器的不同而做調(diào)整。
通用標準
- 容量按照峰值5倍冗余計算。
- 分庫分表后的容量一般可存儲30年的數(shù)據(jù)。
- 第三方查詢接口5000 QPS。
- 單條數(shù)據(jù)庫記錄占用大約1K空間。
Mysql
單端口讀：1000 QPS
單端口寫：700 TPS
單表容量：5000萬條
Redis
單端口讀：4萬 QPS
單端口寫：4萬 TPS
單端口內(nèi)存容量：32G
Kafka
單機讀：3萬 QPS
單機寫：5000 TPS
DB2
單機讀峰值：20000
單機寫峰值：20000
單表容量：1億數(shù)據(jù)
6 總結(jié)
本文以互聯(lián)網(wǎng)企業(yè)重點關(guān)注的非功能質(zhì)量為主線，總結(jié)了非功能質(zhì)量需求的總體目標，并針對不同的服務(wù)和資源列舉了不同的非功能質(zhì)量需求，幫助讀者在做技術(shù)評審的過程整理思路，盡量窮舉評審時關(guān)注的評審點，并隨后提供了一個簡單有效的評審提綱，***根據(jù)提綱實現(xiàn)一個互聯(lián)網(wǎng)容量和性能評估的經(jīng)典案例，大家可以在案例中了解高并發(fā)互聯(lián)網(wǎng)系統(tǒng)是如何進行拆分的，以及依據(jù)哪些數(shù)據(jù)進行拆分。
由于本文的數(shù)據(jù)完全是基于筆者在某個互聯(lián)網(wǎng)平臺下的經(jīng)驗而記錄的，并不代表可以直接應(yīng)用在任何企業(yè)和平臺上，這里重點突出進行容量和性能評估的方法論，幫助大家整理實現(xiàn)高并發(fā)互聯(lián)網(wǎng)系統(tǒng)的思路。
根據(jù)本文的容量評估，我們需要分布式的中間件支持對數(shù)據(jù)庫、緩存和消息隊列的水平伸縮和分片。
點擊《互聯(lián)網(wǎng)性能與容量評估的方法論和典型案例》閱讀原文。
【本文為51CTO專欄作者“李艷鵬”的原創(chuàng)稿件，轉(zhuǎn)載可通過作者簡書號(李艷鵬)或51CTO專欄獲取聯(lián)系】
