互联网性能与容量评估的方法论和典型案例
https://www.jianshu.com/p/fbf56ccb4ebe
1 背景
本文歡迎轉(zhuǎn)載，轉(zhuǎn)載請注明原文鏈接，并附作者個人信息李艷鵬。
性能至上武林中，“天下武功出少林”指中國各門各派的武功都與少林武學(xué)有一定的淵源，技術(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ù)復(fù)雜、流程豐富、中心化管理、企業(yè)級抽象度高、業(yè)務(wù)重用率高的特點，而互聯(lián)網(wǎng)傾向于把復(fù)雜的業(yè)務(wù)進行拆分成單一的職責(zé)，對于單一職責(zé)模塊的非功能質(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，相關(guān)的書籍可以從這里下載ATAM: Method for Architecture Evaluation。
2 目標
2.1 非功能質(zhì)量需求的概述
通過參考技術(shù)評審指標，保證系統(tǒng)架構(gòu)設(shè)計滿足用戶和系統(tǒng)對非功能質(zhì)量的需求：
核心非功能質(zhì)量：
| 高性能 | 運行效率高，性價比高 |
| 可用性 | 持續(xù)可用性，縮短宕機時間，出錯恢復(fù)，可靠性 |
| 可伸縮 | 垂直伸縮，水平伸縮 |
| 可擴展 | 可插拔，組件重用 |
| 安全性 | 數(shù)據(jù)安全，加密，熔斷，防攻擊 |
其他非功能質(zhì)量：
| 可監(jiān)控性 | 快速發(fā)現(xiàn)，快速定位，快速解決 |
| 可測試性 | 可灰度，可預(yù)覽，可Mock，可拆解 |
| 魯棒性 | 容錯性，可恢復(fù)性 |
| 可維護性 | 易于維護，監(jiān)控，運營，擴展 |
| 可重用性 | 可移植性，解耦 |
| 易用性 | 可操作性 |
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ù)量。
全面考慮下列指標：
| 1 | 負載均衡策略 | 每天請求量 | 請求的內(nèi)容是否包含大對象 |
| 2 | 高可用策略 | 各接口訪問峰值 | GC收集器的選型和配置 |
| 3 | IO模型（NIO/BIO） | 平均請求相應(yīng)時間 | ? |
| 4 | 線程池模型 | 最大請求相應(yīng)時間 | ? |
| 5 | 線程池線程數(shù)量 | 在線用戶量 | ? |
| 6 | 是否多業(yè)務(wù)混布 | 請求大小 | ? |
| 7 | ? | 網(wǎng)卡IO流量 | ? |
| 8 | ? | 磁盤IO負載 | ? |
| 9 | ? | 內(nèi)存使用情況 | ? |
| 10 | ? | CPU使用情況 | ? |
2.2.2 數(shù)據(jù)庫
根據(jù)應(yīng)用層的訪問量和訪問峰值，計算出需要的數(shù)據(jù)庫資源的QPS，TPS，每天的數(shù)據(jù)總量等，由此來評估所需數(shù)據(jù)庫資源的數(shù)量和配置，部署結(jié)構(gòu)等。
全面考慮下列指標：
| 1 | 復(fù)制模型 | 當前數(shù)據(jù)容量 | 查詢是否走索引 |
| 2 | 失效轉(zhuǎn)移策略 | 每天數(shù)據(jù)增量（預(yù)估容量） | 有沒有大數(shù)據(jù)量的查詢 |
| 3 | 容災(zāi)策略 | 每秒讀峰值 | 有沒有多表關(guān)聯(lián)，關(guān)聯(lián)是否用到索引 |
| 4 | 歸檔策略 | 每秒寫峰值 | 有沒有使用悲觀鎖，是否可以改造成樂觀鎖，或者是否可以利用數(shù)據(jù)庫內(nèi)置行級鎖 |
| 5 | 讀寫分離策略 | 事務(wù)量 | 事務(wù)和一致性級別 |
| 6 | 分庫分表(分片)策略 | ? | 使用的JDBC數(shù)據(jù)源類型，連接數(shù)等配置 |
| 7 | 靜態(tài)數(shù)據(jù)和半靜態(tài)數(shù)據(jù)是否使用緩存 | ? | 是否開啟JDBC診斷日志 |
| 8 | 有沒有考慮緩存穿透壓垮數(shù)據(jù)庫的情況 | ? | 有沒有存儲過程 |
| 9 | 緩存失效和緩存數(shù)據(jù)預(yù)熱策略 | ? | 伸縮策略（分區(qū)表，自然時間分表，水平分庫分表） |
| 10 | 緩存失效和緩存數(shù)據(jù)預(yù)熱策略 | ? | 水平分庫分表實現(xiàn)方法（客戶端，代理，Nosql） |
2.2.3 緩存
根據(jù)應(yīng)用層的訪問量和訪問峰值，通過評估熱數(shù)據(jù)占比，計算出的緩存資源的大小，存取緩存資源的峰值，由此來計算所需緩存資源的數(shù)量和配置，部署結(jié)構(gòu)等。
全面考慮下列指標：
| 1 | 復(fù)制模型 | 緩存內(nèi)容的大小 | 冷熱數(shù)據(jù)比例 |
| 2 | 失效轉(zhuǎn)移 | 緩存內(nèi)容的數(shù)量 | 是否有可能緩存穿透 |
| 3 | 持久策略 | 緩存內(nèi)容的過期時間 | 是否有大對象 |
| 4 | 淘汰策略 | 緩存的數(shù)據(jù)結(jié)構(gòu) | 是否使用緩存實現(xiàn)分布式鎖 |
| 5 | 線程模型 | 每秒讀峰值 | 是否使用緩存支持的腳本 |
| 6 | 預(yù)熱方法 | 每秒寫峰值 | 是否避免了Race Condition |
| 7 | 分片Hash策略 | ? | 緩存分片方法（客戶端，代理，集群） |
2.2.4 消息隊列
根據(jù)應(yīng)用層的訪問量和訪問峰值，計算需要消息隊列傳遞的數(shù)據(jù)內(nèi)容和數(shù)據(jù)量，計算出的消息隊列資源的數(shù)量和配置，部署結(jié)構(gòu)等。
全面考慮下列指標：
| 1 | 復(fù)制模型 | 每天平均數(shù)據(jù)增量 | 消費線程池模型 |
| 2 | 失效轉(zhuǎn)移 | 消息持久的過期時間 | 分片策略 |
| 3 | 持久策略 | 每秒讀峰值 | 消息的可靠投遞 |
| 4 | ? | 每秒寫峰值 | ? |
| 5 | ? | 每條消息的大小 | ? |
| 6 | ? | 平均延遲 | ? |
| 7 | ? | 最大延遲 | ? |
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)的新需求
性能需求
- 預(yù)估系統(tǒng)容量（預(yù)估系統(tǒng)調(diào)用量平均值）
- 預(yù)估系統(tǒng)調(diào)用量峰值
- 其他非功能質(zhì)量，例如：安全性、可伸縮等
3.3 方案描述
方案1
整個方案需要參考技術(shù)評審指標提出的各方面指標來考慮滿足系統(tǒng)的非功能質(zhì)量需求。
-
概述
一句話概括方案的亮點，比如說: 雙寫，主從分離，分庫分表，擴容，歸檔等。
-
詳細說明
方案的具體描述，文字描述不清楚的話可以結(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ā)量
- 單機容量
- 按照預(yù)估性能需求，預(yù)估資源數(shù)量(應(yīng)用服務(wù)器、緩存、存儲、隊列等)
- 伸縮方式
-
方案優(yōu)缺點
列出方案的優(yōu)缺點，優(yōu)缺點要具有確定性，不要有“存在一定風(fēng)險”這種描述，也就是要量化。
方案2
整個方案需要參考技術(shù)評審指標提出的各方面指標來考慮滿足系統(tǒng)的非功能質(zhì)量需求。
......
3.4 方案對比
對比可選方案，并給出選擇這種方案的理由，選擇傾向的方案，
3.5 風(fēng)險評估
標識所選方案的風(fēng)險，提出解決此風(fēng)險發(fā)生時候的應(yīng)對策略，比如：上線失敗時的回滾策略。
3.6 工作量評估
描述使用所選方案需要做的具體工作，并評估開發(fā)、測試等細化任務(wù)需要的時間，形成可實施的任務(wù)計劃表，任務(wù)計劃表推薦采用簡單的表格形式，減少工具使用和學(xué)習(xí)的成本。
4 性能和容量評估經(jīng)典案例
4.1 背景
物流系統(tǒng)包含如下兩個質(zhì)量優(yōu)先需求：
由于會員數(shù)量較大，可能有較快的增長速度，訂單數(shù)量更是巨大，促銷期峰值的訂單產(chǎn)生量可能很高，這兩個業(yè)務(wù)模塊的數(shù)據(jù)存儲需要分庫分表，并借助消息隊列和緩存抗寫和讀的流量，因此，本方案主要涉及這兩個業(yè)務(wù)的容量評估。
4.2 目標數(shù)據(jù)量級
選取行業(yè)內(nèi)一線電商平臺的量級作為目標：
4.3 量級評估標準
通用標準
Mysql
Redis
Kafka
應(yīng)用服務(wù)器
4.4 方案
方案1. 最大性能方案
由于整個電商網(wǎng)站剛剛上線，數(shù)據(jù)量級還無法清晰的確定，我們根據(jù)行業(yè)內(nèi)知名電商當前數(shù)據(jù)量級設(shè)計最大性能方案，本方案可以應(yīng)對行業(yè)內(nèi)電商巨頭的各種促銷所帶來的服務(wù)請求峰值，并且擁有最快的響應(yīng)時間，達到服務(wù)性能的最大化。
需求1. 會員常用地址
整體流程：
數(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. 物流訂單和物流記錄
整體流程：
數(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é)
傾向于采用最小資源方案：
5 性能評估參考標準
以下標準是使用PC X86機器的經(jīng)驗值，僅供參考，評審時應(yīng)該隨著機器的不同而做調(diào)整。
通用標準
Mysql
Redis
Kafka
DB2
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ù)庫、緩存和消息隊列的水平伸縮和分片，想了解分布式中間件的原理，請參考開源項目。
作者：李艷鵬
鏈接：https://www.jianshu.com/p/fbf56ccb4ebe
來源：簡書
簡書著作權(quán)歸作者所有，任何形式的轉(zhuǎn)載都請聯(lián)系作者獲得授權(quán)并注明出處。
轉(zhuǎn)載于:https://www.cnblogs.com/davidwang456/articles/9229580.html
總結(jié)
以上是生活随笔為你收集整理的互联网性能与容量评估的方法论和典型案例的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 常用的几种大数据架构剖析
- 下一篇： curl请求模拟post发送json