互联网性能与容量评估的方法论和典型案例
https://www.jianshu.com/p/fbf56ccb4ebe
1 背景
本文歡迎轉載，轉載請注明原文鏈接，并附作者個人信息李艷鵬。
性能至上武林中，“天下武功出少林”指中國各門各派的武功都與少林武學有一定的淵源，技術也是相同的道理，所有的技術最終體現在計算機知識的基本功上，這些基本功是技術的易筋經，是“內功”，一些年輕的攻城獅更熱衷于追崇高大上的框架，過去在炒SSH，現在在炒Spring Cloud，這些對框架掌握的程度體現在“劍術”上，我推薦每個技術研發人員在修煉好內功的基礎上，再去練“劍術”。回頭看IT行業的發展，先有傳統行業，再有互聯網，傳統行業和互聯網是少林與武當的關系，他們的技術相輔相成，并不一定是互聯網的技術要比傳統行業的技術高深很多，而是它們有自己的側重點，傳統行業更偏向于企業級開發，項目具有業務復雜、流程豐富、中心化管理、企業級抽象度高、業務重用率高的特點，而互聯網傾向于把復雜的業務進行拆分成單一的職責，對于單一職責模塊的非功能質量進行大幅度的優化，這包括高可用性、高性能、可伸縮、可擴展、安全性、穩定性、可維護性、健壯性等。
這篇文章提供一個基本的面向互聯網技術評審的方法論，它主要論述在互聯網的行業里，如何在完成產品功能的前提下，更好的滿足非功能質量的需求，是每個互聯網程序設計人員和架構設計人員都應該掌握的一項基本技能。
本文的目的是為了初入互聯網或者有意愿踏入互聯網的研發人員起到拋磚引玉的效果，如果想全面了解互聯網非功能質量設計的方方面面，可以參考美國互聯網方法論Architecture Tradeoff Analysis Method，相關的書籍可以從這里下載ATAM: Method for Architecture Evaluation。
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 目標數據量級
選取行業內一線電商平臺的量級作為目標：
4.3 量級評估標準
通用標準
Mysql
Redis
Kafka
應用服務器
4.4 方案
方案1. 最大性能方案
由于整個電商網站剛剛上線，數據量級還無法清晰的確定，我們根據行業內知名電商當前數據量級設計最大性能方案，本方案可以應對行業內電商巨頭的各種促銷所帶來的服務請求峰值，并且擁有最快的響應時間，達到服務性能的最大化。
需求1. 會員常用地址
整體流程：
數據庫資源評估：
讀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. 物流訂單和物流記錄
整體流程：
數據庫資源評估：
讀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 總結
傾向于采用最小資源方案：
5 性能評估參考標準
以下標準是使用PC X86機器的經驗值，僅供參考，評審時應該隨著機器的不同而做調整。
通用標準
Mysql
Redis
Kafka
DB2
6 總結
本文以互聯網企業重點關注的非功能質量為主線，總結了非功能質量需求的總體目標，并針對不同的服務和資源列舉了不同的非功能質量需求，幫助讀者在做技術評審的過程整理思路，盡量窮舉評審時關注的評審點，并隨后提供了一個簡單有效的評審提綱，最后根據提綱實現一個互聯網容量和性能評估的經典案例，大家可以在案例中了解高并發互聯網系統是如何進行拆分的，以及依據哪些數據進行拆分。
由于本文的數據完全是基于筆者在某個互聯網平臺下的經驗而記錄的，并不代表可以直接應用在任何企業和平臺上，這里重點突出進行容量和性能評估的方法論，幫助大家整理實現高并發互聯網系統的思路。
根據本文的容量評估，我們需要分布式的中間件支持對數據庫、緩存和消息隊列的水平伸縮和分片，想了解分布式中間件的原理，請參考開源項目。
作者：李艷鵬
鏈接：https://www.jianshu.com/p/fbf56ccb4ebe
來源：簡書
簡書著作權歸作者所有，任何形式的轉載都請聯系作者獲得授權并注明出處。
轉載于:https://www.cnblogs.com/davidwang456/articles/9229580.html
總結
以上是生活随笔為你收集整理的互联网性能与容量评估的方法论和典型案例的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 常用的几种大数据架构剖析
- 下一篇： curl请求模拟post发送json