[[187759]]

1 背景

武林中，“天下武功出少林”指中國各門各派的武功都與少林武學有一定的淵源，技術也是相同的道理，所有的技術最終體現(xiàn)在計算機知識的基本功上，這些基本功是技術的易筋經(jīng)，是“內功”，一些年輕的攻城獅更熱衷于追崇高大上的框架，過去在炒SSH，現(xiàn)在在炒Spring Cloud，這些對框架掌握的程度體現(xiàn)在“劍術”上，我推薦每個技術研發(fā)人員在修煉好內功的基礎上，再去練“劍術”。回頭看IT行業(yè)的發(fā)展，先有傳統(tǒng)行業(yè)，再有互聯(lián)網(wǎng)，傳統(tǒng)行業(yè)和互聯(lián)網(wǎng)是少林與武當?shù)年P系，他們的技術相輔相成，并不一定是互聯(lián)網(wǎng)的技術要比傳統(tǒng)行業(yè)的技術高深很多，而是它們有自己的側重點，傳統(tǒng)行業(yè)更偏向于企業(yè)級開發(fā)，項目具有業(yè)務復雜、流程豐富、中心化管理、企業(yè)級抽象度高、業(yè)務重用率高的特點，而互聯(lián)網(wǎng)傾向于把復雜的業(yè)務進行拆分成單一的職責，對于單一職責模塊的非功能質量進行大幅度的優(yōu)化，這包括高可用性、高性能、可伸縮、可擴展、安全性、穩(wěn)定性、可維護性、健壯性等。

這篇文章提供一個基本的面向互聯(lián)網(wǎng)技術評審的方法論，它主要論述在互聯(lián)網(wǎng)的行業(yè)里，如何在完成產(chǎn)品功能的前提下，更好的滿足非功能質量的需求，是每個互聯(lián)網(wǎng)程序設計人員和架構設計人員都應該掌握的一項基本技能。

本文的目的是為了初入互聯(lián)網(wǎng)或者有意愿踏入互聯(lián)網(wǎng)的研發(fā)人員起到拋磚引玉的效果，如果想全面了解互聯(lián)網(wǎng)非功能質量設計的方方面面，可以參考美國互聯(lián)網(wǎng)方法論Architecture Tradeoff Analysis Method。

2 目標

2.1 非功能質量需求的概述

通過參考技術評審指標，保證系統(tǒng)架構設計滿足用戶和系統(tǒng)對非功能質量的需求：

核心非功能質量：

其他非功能質量：

2.2 非功能質量需求的具體指標

主要分為4部分：應用服務器、數(shù)據(jù)庫、緩存和消息隊列。

2.2.1 應用服務器

應用服務器是服務的入口，請求流量從這里進入系統(tǒng)，數(shù)據(jù)庫，緩存和消息隊列的訪問量取決于應用服務器的訪問量，對應用服務器的訪問量進行評估至關重要，應用服務器主要關心每秒請求的峰值，請求響應時間等指標，通過這些指標可以評估需要的應用服務器資源的數(shù)量。

全面考慮下列指標：

2.2.2 數(shù)據(jù)庫

根據(jù)應用層的訪問量和訪問峰值，計算出需要的數(shù)據(jù)庫資源的QPS，TPS，每天的數(shù)據(jù)總量等，由此來評估所需數(shù)據(jù)庫資源的數(shù)量和配置，部署結構等。

全面考慮下列指標：

2.2.3 緩存

根據(jù)應用層的訪問量和訪問峰值，通過評估熱數(shù)據(jù)占比，計算出的緩存資源的大小，存取緩存資源的峰值，由此來計算所需緩存資源的數(shù)量和配置，部署結構等。

全面考慮下列指標：

序號/指標分類部署結構容量與性能其他

1復制模型緩存內容的大小冷熱數(shù)據(jù)比例

2失效轉移緩存內容的數(shù)量是否有可能緩存穿透

3持久策略緩存內容的過期時間是否有大對象

4淘汰策略緩存的數(shù)據(jù)結構是否使用緩存實現(xiàn)分布式鎖

5線程模型每秒讀峰值是否使用緩存支持的腳本

6預熱方法每秒寫峰值是否避免了Race Condition

7分片Hash策略緩存分片方法(客戶端，代理，集群)

2.2.4 消息隊列

根據(jù)應用層的訪問量和訪問峰值，計算需要消息隊列傳遞的數(shù)據(jù)內容和數(shù)據(jù)量，計算出的消息隊列資源的數(shù)量和配置，部署結構等。

全面考慮下列指標：

3 技術評審提綱

業(yè)務項目千差萬別，沒有一個統(tǒng)一的方法論完成架構設計和技術評審，架構設計只需要從某些關鍵點來表達系統(tǒng)即可，提綱就是用來幫助大家做架構評審的工具，幫助大家整理思路并形成可實施的方案，因此在做系統(tǒng)設計時，可有選擇性的參考此提綱，根據(jù)業(yè)務特點來完成一個可實現(xiàn)的有效的架構設計。

3.1 現(xiàn)狀

項目名稱

• 業(yè)務背景
• 業(yè)務描述

技術背景

• 架構描述
• 當前系統(tǒng)容量(系統(tǒng)調用量平均值)
• 當前系統(tǒng)調用量峰值

3.2 需求

業(yè)務需求

• 要改造的內容
• 要實現(xiàn)的新需求

性能需求

• 預估系統(tǒng)容量(預估系統(tǒng)調用量平均值)
• 預估系統(tǒng)調用量峰值
• 其他非功能質量，例如：安全性、可伸縮等

3.3 方案描述

方案1

• 概述

一句話概括方案的亮點，比如說: 雙寫，主從分離，分庫分表，擴容，歸檔等。

• 詳細說明

方案的具體描述，文字描述不清楚的話可以結合圖(任何圖：UML，概念圖，框圖等)的方式說明，如果是改造方案***突出變動的地方，以下列舉了幾種描述的角度：

中間件架構(應用服務器、數(shù)據(jù)庫、緩存、消息隊列等)

邏輯架構(模塊劃分、模塊通信、信息流、時序等)

數(shù)據(jù)架構(數(shù)據(jù)結構、數(shù)據(jù)分布、拆分策略、緩存策略、讀寫分離策略、查詢策略、數(shù)據(jù)一致性策略)

異常處理，容災策略，灰度發(fā)布

• 性能評估

給出方案的基準數(shù)據(jù)，并按性能需求評估需要使用的資源數(shù)量。

單機并發(fā)量

單機容量

按照預估性能需求，預估資源數(shù)量(應用服務器、緩存、存儲、隊列等)

伸縮方式

• 方案優(yōu)缺點

列出方案的優(yōu)缺點，優(yōu)缺點要具有確定性，不要有“存在一定風險”這種描述，也就是要量化。

方案2

整個方案需要參考技術評審指標提出的各方面指標來考慮滿足系統(tǒng)的非功能質量需求。

......

3.4 方案對比

對比可選方案，并給出選擇這種方案的理由，選擇傾向的方案，

3.5 風險評估

標識所選方案的風險，提出解決此風險發(fā)生時候的應對策略，比如：上線失敗時的回滾策略。

3.6 工作量評估

描述使用所選方案需要做的具體工作，并評估開發(fā)、測試等細化任務需要的時間，形成可實施的任務計劃表，任務計劃表推薦采用簡單的表格形式，減少工具使用和學習的成本。

4 性能和容量評估經(jīng)典案例

4.1 背景

物流系統(tǒng)包含如下兩個質量優(yōu)先需求：

1. 維護會員常用地址，下單時提供會員地址列表。
2. 下單時異步產(chǎn)生物流訂單，物流系統(tǒng)后臺任務從第三方物流輪循拉取物流狀態(tài)，已經(jīng)下單用戶查詢訂單的物流訂單和物流記錄。

由于會員數(shù)量較大，可能有較快的增長速度，訂單數(shù)量更是巨大，促銷期峰值的訂單產(chǎn)生量可能很高，這兩個業(yè)務模塊的數(shù)據(jù)存儲需要分庫分表，并借助消息隊列和緩存抗寫和讀的流量，因此，本方案主要涉及這兩個業(yè)務的容量評估。

4.2 目標數(shù)據(jù)量級

選取行業(yè)內一線電商平臺的量級作為目標：

1. 會員量2億，平均增長5萬/天。
2. 平時訂單量400萬/天，所有訂單下單時段集中在9:00-23:00，促銷日訂單量1400萬/天，50%訂單下單時段集中在晚上7:30-8:30和晚上22:00-23:00。

4.3 量級評估標準

通用標準

1. 容量按照峰值5倍冗余計算。
2. 會員常用地址容量按照30年計算，而物流訂單時效性較強按照3年計算。
3. 第三方查詢接口5000 QPS。

Mysql

1. 單端口讀：1000 QPS
2. 單端口寫：700 TPS
3. 單表容量：5000萬條

Redis

1. 單端口讀：4萬 QPS
2. 單端口寫：4萬 TPS
3. 單端口內存容量：32G

Kafka

1. 單機讀：3萬 QPS
2. 單機寫：5000 TPS

應用服務器

1. 請求量每秒峰值：5000 QPS

4.4 方案

方案1. ***性能方案

由于整個電商網(wǎng)站剛剛上線，數(shù)據(jù)量級還無法清晰的確定，我們根據(jù)行業(yè)內知名電商當前數(shù)據(jù)量級設計***性能方案，本方案可以應對行業(yè)內電商巨頭的各種促銷所帶來的服務請求峰值，并且擁有最快的響應時間，達到服務性能的***化。

需求1. 會員常用地址

整體流程：

1. 提供Restful服務增加會員常用地址。
2. 提供Restful服務獲取會員常用地址列表。

數(shù)據(jù)庫資源評估：

讀QPS：

會員每次下單，拉取一次會員地址列表，按照促銷日訂單量1400萬/天，50%訂單下單時段集中在兩個小時內計算：

(1400萬 × 0.5) / (2 × 60 × 60) = 1000/秒

容量評估按照5倍冗余計算，讀QPS峰值1000/秒 * 5 = 5000/秒，需要5端口數(shù)據(jù)庫服務讀。

寫TPS：

假設每天增加的會員全部添加一次常用地址，并且高峰期會員下訂單時有20%的會員會增加一條常用地址：

(1400萬 × 0.2 + 5萬) / (2 × 60 × 60) = 400/秒

容量評估按照5倍冗余計算，400/秒 * 5 = 2000/秒，需要3端口數(shù)據(jù)庫服務寫。

數(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ù)庫，盡量設計更多的庫，使用32個庫。

設計結果：4端口 × 32庫 × 4表， 4主8從

緩存資源評估：

為了提高用戶下單的體驗，需要使用Redis緩存活躍用戶的常用地址。

定義當天下訂單的會員為活躍會員，活躍會員的地址緩存24小時，假定每天下訂單的會員均為不同會員，每個會員有5個常用地址，緩存大小計算如下：

1400萬 × 5 × 1k = 70G

容量評估按照5倍冗余計算，70G×5=350G，按照每臺Redis 32G內存計算，需要11臺機器，根據(jù)數(shù)據(jù)庫對數(shù)據(jù)存取QPS/TPS的設計，11臺機器完全可以滿足5000/秒的讀QPS和2000/秒的寫TPS。

設計結果：11臺，主從

應用服務器資源評估：

根據(jù)數(shù)據(jù)庫的讀QPS(5000/s)峰值和寫TPS(2000/s)峰值計算，單臺應用服務器即可，選擇2臺避免單點。

設計結果：2臺

需求2. 物流訂單和物流記錄

整體流程：

1. 訂單提交后，通過消息隊列產(chǎn)生物流訂單，消息傳入物流系統(tǒng)，物流系統(tǒng)消費物流訂單消息然后入庫。
2. 后臺任務輪循未完成物流訂單，查詢第三方物流接口狀態(tài)，填寫物流記錄信息。按照每天1400萬的訂單，訂單平均3天到貨，第三方查詢接口5000 QPS，每次狀態(tài)查詢需要時間計算如下： 1400萬 × 3 / 5000 = 8400 / 60 / 60 = 2小時，定時任務2小時查一次。
3. 提供REST服務獲取物流訂單信息。
4. 提供REST服務獲取物流記錄信息。
5. 提供REST服務獲取物流訂單和物流記錄信息。

數(shù)據(jù)庫資源評估：

讀QPS：

會員下單三天到貨，三天內50%客戶會查詢一次物流訂單和一次物流記錄，計算如下：

(1400萬 × 3 × 0.5) / (24 × 60 × 60) = 250/秒

容量評估按照5倍冗余計算，2 × 250/秒 × 5倍 = 2500/秒，需要3端口數(shù)據(jù)庫服務讀。

寫TPS：

會員每次下單，產(chǎn)生一次物流訂單，按照促銷日訂單量1400萬/天，50%訂單下單時段集中在兩個小時內計算：

(1400萬 × 0.5) / (2 × 60 × 60) = 1000/秒

按照每天1400萬的訂單，訂單平均3天到貨，每條物流訂單產(chǎn)生8條物流記錄，并且8條物流記錄在三天內均勻產(chǎn)生，物流記錄寫TPS計算如下：

1400萬 × 3 × 8 / 3 / (24 × 60 × 60) = 1200/秒

容量評估按照5倍冗余計算，(1000/秒 + 1200/秒) * 5 = 11000/秒，需要15端口數(shù)據(jù)庫服務寫。

數(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ù)庫，盡量設計更多的庫，使用32個庫。

設計結果：16端口 × 32庫 × 8表，16主16從

消息隊列資源評估：

為了讓系統(tǒng)能夠應對峰值的突增，采用消息隊列Kafka接收物流訂單。

根據(jù)上面對寫TPS的計算，考慮5倍冗余后，峰值為5000/秒，單臺Kafka和單臺處理機即可處理。

如果峰值有突增，可以增加Kafaka集群的節(jié)點來抗寫流量，處理機根據(jù)后端入庫性能來決定。例如寫峰值增加10倍，達到5萬/秒，需要10臺Kafka，每臺Kafka讀QPS可達3萬，理論上需要2臺處理機，然而，處理機的瓶頸是后端入庫的寫TPS，根據(jù)上面計算，入庫的寫TPS峰值按照5000/秒設計，因此，單臺處理機即可，這個場景下會有消息的堆積，但是最終會處理完畢，達到消峰的效果。

設計結果：1臺Kafka，主從，1臺處理機

應用服務器資源評估：

根據(jù)數(shù)據(jù)庫的讀QPS(2500/s)峰值和寫TPS(11000/s)峰值計算，3臺應用服務器即可。

用于查詢第三方接口的后臺任務服務器，由于受到第三方接口5000/s的QPS的限制，單臺機器即可，為了避免單點，2臺處理機即可。

設計結果：2臺

方案2. 最小資源方案

由于當前系統(tǒng)線上數(shù)據(jù)量并不多，增長量也不大，讀QPS和寫TPS單臺機器完全可以處理，暫時不考慮使用緩存和消息隊列，但是保留使用緩存和消息隊列的接口，如果緩存和消息隊列的資源可用，可以通過開關進行切換。

當前的數(shù)據(jù)量使用單庫單表即可處理，然而，考慮到將來擴容方便，數(shù)據(jù)庫端口暫時使用一個，但是保留我們在***性能方案中對數(shù)據(jù)庫的分庫分表，當讀QPS和寫TPS突增時，DBA可以把庫重新拆分到多個端口來抗請求流量。

因此，方案如下：

會員常用地址

設計結果：1端口 × 32庫 × 16表， 1主1從

物流訂單和物流記錄

設計結果：1端口 × 128庫 × 32表，1主1從

4.5 總結

傾向于采用最小資源方案：

當前線上流量并不大，使用最小資源方案節(jié)省成本。

最小資源方案充分的考慮了數(shù)據(jù)庫的分庫分表，當讀QPS和寫TPS突增時，DBA可以拆分庫到不同的端口，也就是增加端口來應對。

最小資源方案在應用層設計了開關，如果性能突增可以臨時申請和開啟緩存和消息隊列。

5 性能評估參考標準

以下標準是使用PC X86機器的經(jīng)驗值，僅供參考，評審時應該隨著機器的不同而做調整。

通用標準

1. 容量按照峰值5倍冗余計算。
2. 分庫分表后的容量一般可存儲30年的數(shù)據(jù)。
3. 第三方查詢接口5000 QPS。
4. 單條數(shù)據(jù)庫記錄占用大約1K空間。

Mysql

單端口讀：1000 QPS

單端口寫：700 TPS

單表容量：5000萬條

Redis

單端口讀：4萬 QPS

單端口寫：4萬 TPS

單端口內存容量：32G

Kafka

單機讀：3萬 QPS

單機寫：5000 TPS

DB2

單機讀峰值：20000

單機寫峰值：20000

單表容量：1億數(shù)據(jù)

6 總結

本文以互聯(lián)網(wǎng)企業(yè)重點關注的非功能質量為主線，總結了非功能質量需求的總體目標，并針對不同的服務和資源列舉了不同的非功能質量需求，幫助讀者在做技術評審的過程整理思路，盡量窮舉評審時關注的評審點，并隨后提供了一個簡單有效的評審提綱，***根據(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è)和平臺上，這里重點突出進行容量和性能評估的方法論，幫助大家整理實現(xiàn)高并發(fā)互聯(lián)網(wǎng)系統(tǒng)的思路。

根據(jù)本文的容量評估，我們需要分布式的中間件支持對數(shù)據(jù)庫、緩存和消息隊列的水平伸縮和分片。

點擊《互聯(lián)網(wǎng)性能與容量評估的方法論和典型案例》閱讀原文。

【本文為51CTO專欄作者“李艷鵬”的原創(chuàng)稿件，轉載可通過作者簡書號(李艷鵬)或51CTO專欄獲取聯(lián)系】

戳這里，看該作者更多好文