系統(tǒng)負載能力淺析

漢無為 2017-09-30

展開全文

互聯(lián)網(wǎng)時代，高并發(fā)是一個老生常談的話題。無論對于一個Web站點還是App應(yīng)用，高峰時能承載的并發(fā)請求都是衡量一個系統(tǒng)性能的關(guān)鍵標(biāo)志。像阿里雙十一頂住了上億的峰值請求、訂單也確實體現(xiàn)了阿里的技術(shù)水平（當(dāng)然有錢也是一個原因）。

那么，何為系統(tǒng)負載能力？怎么衡量？相關(guān)因素有哪些？又如何優(yōu)化呢？

一. 衡量指標(biāo)

用什么來衡量一個系統(tǒng)的負載能力呢？有一個概念叫做每秒請求數(shù)（Requests per second），指的是每秒能夠成功處理請求的數(shù)目。比如說，你可以配置Tomcat服務(wù)器的maxConnection為無限大，但是受限于服務(wù)器系統(tǒng)或者硬件限制，很多請求是不會在一定的時間內(nèi)得到響應(yīng)的，這并不作為一個成功的請求，其中成功得到響應(yīng)的請求數(shù)即為每秒請求數(shù)，反應(yīng)出系統(tǒng)的負載能力。

通常的，對于一個系統(tǒng)，增加并發(fā)用戶數(shù)量時每秒請求數(shù)量也會增加。然而，我們最終會達到這樣一個點，此時并發(fā)用戶數(shù)量開始“壓倒”服務(wù)器。如果繼續(xù)增加并發(fā)用戶數(shù)量，每秒請求數(shù)量開始下降，而反應(yīng)時間則會增加。這個并發(fā)用戶數(shù)量開始“壓倒”服務(wù)器的臨界點非常重要，此時的并發(fā)用戶數(shù)量可以認為是當(dāng)前系統(tǒng)的最大負載能力。

二. 相關(guān)因素

一般的，和系統(tǒng)并發(fā)訪問量相關(guān)的幾個因素如下：

帶寬
硬件配置
系統(tǒng)配置
應(yīng)用服務(wù)器配置
程序邏輯
系統(tǒng)架構(gòu)

其中，帶寬和硬件配置是決定系統(tǒng)負載能力的決定性因素。這些只能依靠擴展和升級提高。我們需要重點關(guān)注的是在一定帶寬和硬件配置的基礎(chǔ)上，怎么使系統(tǒng)的負載能力達到最大。

2.1 帶寬

毋庸置疑，帶寬是決定系統(tǒng)負載能力的一個至關(guān)重要的因素，就好比水管一樣，細的水管同一時間通過的水量自然就少（這個比喻解釋帶寬可能不是特別合適）。一個系統(tǒng)的帶寬首先就決定了這個系統(tǒng)的負載能力，其單位為Mbps,表示數(shù)據(jù)的發(fā)送速度。

2.2 硬件配置

系統(tǒng)部署所在的服務(wù)器的硬件決定了一個系統(tǒng)的最大負載能力，也是上限。一般說來，以下幾個配置起著關(guān)鍵作用：

CPU頻率/核數(shù)：CPU頻率關(guān)系著CPU的運算速度，核數(shù)則影響線程調(diào)度、資源分配的效率。
內(nèi)存大小以及速度：內(nèi)存越大，那么可以在內(nèi)存中運行的數(shù)據(jù)也就越大，速度自然而然就快；內(nèi)存的速度從原來的幾百hz到現(xiàn)在幾千hz，決定了數(shù)據(jù)讀取存儲的速度。
硬盤速度：傳統(tǒng)的硬盤是使用磁頭進行尋址的，IO速度比較慢，使用了SSD的硬盤，其尋址速度大大較快。

很多系統(tǒng)的架構(gòu)設(shè)計、系統(tǒng)優(yōu)化，最終都會加上這么一句：使用SSD存儲解決了這些問題。

可見，硬件配置是決定一個系統(tǒng)的負載能力的最關(guān)鍵因素。

2.3 系統(tǒng)配置

一般來說，目前后端系統(tǒng)都是部署在Linux主機上的。所以拋開Win系列不談，對于Linux系統(tǒng)來說一般有以下配置關(guān)系著系統(tǒng)的負載能力。

文件描述符數(shù)限制：Linux中所有東西都是文件，一個socket就對應(yīng)著一個文件描述符，因此系統(tǒng)配置的最大打開文件數(shù)以及單個進程能夠打開的最大文件數(shù)就決定了socket的數(shù)目上限。
進程/線程數(shù)限制: 對于Apache使用的Prefork等多進程模式，其負載能力由進程數(shù)目所限制。對Tomcat多線程模式則由線程數(shù)所限制。
TCP內(nèi)核參數(shù)：網(wǎng)絡(luò)應(yīng)用的底層自然離不開TCP/IP，Linux內(nèi)核有一些與此相關(guān)的配置也決定了系統(tǒng)的負載能力。

2.3.1 文件描述符數(shù)限制

系統(tǒng)最大打開文件描述符數(shù)：/proc/sys/fs/file-max中保存了這個數(shù)目,修改此值

臨時性
echo 1000000 > /proc/sys/fs/file-max
永久性：在/etc/sysctl.conf中設(shè)置
fs.file-max = 1000000

進程最大打開文件描述符數(shù)：這個是配單個進程能夠打開的最大文件數(shù)目?？梢酝ㄟ^ulimit -n查看/修改。如果想要永久修改，則需要修改/etc/security/limits.conf中的nofile。

通過讀取/proc/sys/fs/file-nr可以看到當(dāng)前使用的文件描述符總數(shù)。另外，對于文件描述符的配置，需要注意以下幾點：

所有進程打開的文件描述符數(shù)不能超過/proc/sys/fs/file-max
單個進程打開的文件描述符數(shù)不能超過user limit中nofile的soft limit
nofile的soft limit不能超過其hard limit
nofile的hard limit不能超過/proc/sys/fs/nr_open

2.3.2 進程/線程數(shù)限制

進程數(shù)限制：ulimit -u可以查看/修改單個用戶能夠打開的最大進程數(shù)。/etc/security/limits.conf中的noproc則是系統(tǒng)的最大進程數(shù)。
線程數(shù)限制

可以通過/proc/sys/kernel/threads-max查看系統(tǒng)總共可以打開的最大線程數(shù)。
單個進程的最大線程數(shù)和PTHREAD_THREADS_MAX有關(guān)，此限制可以在/usr/include/bits/local_lim.h中查看,但是如果想要修改的話，需要重新編譯。
這里需要提到一點的是，Linux內(nèi)核2.4的線程實現(xiàn)方式為linux threads，是輕量級進程，都會首先創(chuàng)建一個管理線程，線程數(shù)目的大小是受PTHREAD_THREADS_MAX影響的。但Linux2.6內(nèi)核的線程實現(xiàn)方式為NPTL,是一個改進的LWP實現(xiàn)，最大一個區(qū)別就是，線程公用進程的pid（tgid），線程數(shù)目大小只受制于資源。
線程數(shù)的大小還受線程棧大小的制約：使用ulimit -s可以查看/修改線程棧的大小，即每開啟一個新的線程需要分配給此線程的一部分內(nèi)存。減小此值可以增加可以打開的線程數(shù)目。

2.3.3 TCP內(nèi)核參數(shù)

在一臺服務(wù)器CPU和內(nèi)存資源額定有限的情況下，最大的壓榨服務(wù)器的性能，是最終的目的。在節(jié)省成本的情況下，可以考慮修改Linux的內(nèi)核TCP/IP參數(shù)，來最大的壓榨服務(wù)器的性能。如果通過修改內(nèi)核參數(shù)也無法解決的負載問題，也只能考慮升級服務(wù)器了，這是硬件所限，沒有辦法的事。

netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'

使用上面的命令，可以得到當(dāng)前系統(tǒng)的各個狀態(tài)的網(wǎng)絡(luò)連接的數(shù)目。如下：

LAST_ACK 13
SYN_RECV 468
ESTABLISHED 90
FIN_WAIT1 259
FIN_WAIT2 40
CLOSING 34
TIME_WAIT 28322

這里，TIME_WAIT的連接數(shù)是需要注意的一點。此值過高會占用大量連接，影響系統(tǒng)的負載能力。需要調(diào)整參數(shù)，以盡快的釋放time_wait連接。

一般TCP相關(guān)的內(nèi)核參數(shù)在/etc/sysctl.conf文件中。為了能夠盡快釋放time_wait狀態(tài)的連接，可以做以下配置：

net.ipv4.tcp_syncookies = 1 //表示開啟SYN Cookies。當(dāng)出現(xiàn)SYN等待隊列溢出時，啟用cookies來處理，可防范少量SYN攻擊，默認為0，表示關(guān)閉；
net.ipv4.tcp_tw_reuse = 1 //表示開啟重用。允許將TIME-WAIT sockets重新用于新的TCP連接，默認為0，表示關(guān)閉；
net.ipv4.tcp_tw_recycle = 1 //表示開啟TCP連接中TIME-WAIT sockets的快速回收，默認為0，表示關(guān)閉；
net.ipv4.tcp_fin_timeout = 30 //修改系統(tǒng)默認的 TIMEOUT 時間。

這里需要注意的一點就是當(dāng)打開了tcp_tw_recycle，就會檢查時間戳，移動環(huán)境下的發(fā)來的包的時間戳有些時候是亂跳的，會把帶了“倒退”的時間戳的包當(dāng)作是“recycle的tw連接的重傳數(shù)據(jù)，不是新的請求”，于是丟掉不回包，造成大量丟包。另外，當(dāng)前面有LVS，并且采用的是NAT機制時，開啟tcp_tw_recycle會造成一些異常，可見：http://www./?p=416。如果這種情況下仍然需要開啟此選項，那么可以考慮設(shè)置net.ipv4.tcp_timestamps=0，忽略掉報文的時間戳即可。

此外，還可以通過優(yōu)化tcp/ip的可使用端口的范圍，進一步提升負載能力，如下：

net.ipv4.tcp_keepalive_time = 1200 //表示當(dāng)keepalive起用的時候，TCP發(fā)送keepalive消息的頻度。缺省是2小時，改為20分鐘。
net.ipv4.ip_local_port_range = 10000 65000 //表示用于向外連接的端口范圍。缺省情況下很?。?2768到61000，改為10000到65000。（注意：這里不要將最低值設(shè)的太低，否則可能會占用掉正常的端口?。?/span>
net.ipv4.tcp_max_syn_backlog = 8192 //表示SYN隊列的長度，默認為1024，加大隊列長度為8192，可以容納更多等待連接的網(wǎng)絡(luò)連接數(shù)。
net.ipv4.tcp_max_tw_buckets = 5000 //表示系統(tǒng)同時保持TIME_WAIT的最大數(shù)量，如果超過這個數(shù)字，TIME_WAIT將立刻被清除并打印警告信息。默認為180000，改為5000。對于Apache、Nginx等服務(wù)器，上幾行的參數(shù)可以很好地減少TIME_WAIT套接字數(shù)量，但是對于Squid，效果卻不大。此項參數(shù)可以控制TIME_WAIT的最大數(shù)量，避免Squid服務(wù)器被大量的TIME_WAIT拖死。

2.4 應(yīng)用服務(wù)器配置

說到應(yīng)用服務(wù)器配置，這里需要提到應(yīng)用服務(wù)器的幾種工作模式,也叫并發(fā)策略。

multi process:多進程方式，一個進程處理一個請求。
prefork：類似于多進程的方式，但是會預(yù)先fork出一些進程供后續(xù)使用，是一種進程池的理念。
worker：一個線程對應(yīng)一個請求，相比多進程的方式，消耗資源變少，但同時一個線程的崩潰會引起整個進程的崩潰，穩(wěn)定性不如多進程。
master/worker：采用的是非阻塞IO的方式，只有兩種進程：worker和master,master負責(zé)worker進程的創(chuàng)建、管理等，worker進程采用基于事件驅(qū)動的多路復(fù)用IO處理請求。mater進程只需要一個，woker進程根據(jù)cpu核數(shù)設(shè)置數(shù)目。

前三者是傳統(tǒng)應(yīng)用服務(wù)器Apache和Tomcat采用的方式，最后一種是Nginx采用的方式。當(dāng)然這里需要注意的是應(yīng)用服務(wù)器和nginx這種做反向代理服務(wù)器（暫且忽略nginx+cgi做應(yīng)用服務(wù)器的功能）的區(qū)別。應(yīng)用服務(wù)器是需要處理應(yīng)用邏輯的，有時候是耗cup資源的；而反向代理主要用作IO，是IO密集型的應(yīng)用。使用事件驅(qū)動的這種網(wǎng)絡(luò)模型，比較適合IO密集型應(yīng)用，而并不適合CPU密集型應(yīng)用。對于后者，多進程/線程則是一個更好地選擇。

當(dāng)然，由于Nginx采用的基于事件驅(qū)動的多路IO復(fù)用的模型，其作為反向代理服務(wù)器時，可支持的并發(fā)是非常大的。淘寶Tengine團隊曾有一個測試結(jié)果是“24G內(nèi)存機器上，處理并發(fā)請求可達200萬”。

2.4.1 Nginx/Tengine

Ngixn是目前使用最廣泛的反向代理軟件，而Tengine是阿里開源的一個加強版Nginx,其基本實現(xiàn)了Nginx收費版本的一些功能，如：主動健康檢查、session sticky等。對于Nginx的配置，需要注意的有這么幾點：

worker數(shù)目要和cpu（核）的數(shù)目相適應(yīng)
keepalive timout要設(shè)置適當(dāng)
worker_rlimit_nofile最大文件描述符要增大
upstream可以使用http 1.1的keepalive

典型配置可見：https://github.com/superhj1987/awesome-config/blob/master/nginx/nginx.conf

2.4.2 Tomcat

Tomcat的關(guān)鍵配置總體上有兩大塊：jvm參數(shù)配置和connector參數(shù)配置。

jvm參數(shù)配置：

堆的最小值：Xms
堆的最大值：Xmx
新生代大小: Xmn
永久代大小: XX:PermSize：
永久代最大大小: XX:MaxPermSize：
棧大?。?Xss或-XX:ThreadStackSize

這里對于棧大小有一點需要注意的是：在Linux x64上ThreadStackSize的默認值就是1024KB，給Java線程創(chuàng)建棧會用這個參數(shù)指定的大小。如果把-Xss或者-XX:ThreadStackSize設(shè)為0，就是使用“系統(tǒng)默認值”。而在Linux x64上HotSpot VM給Java棧定義的“系統(tǒng)默認”大小也是1MB。所以普通Java線程的默認棧大小怎樣都是1MB。這里有一個需要注意的地方就是java的棧大小和之前提到過的操作系統(tǒng)的操作系統(tǒng)棧大?。╱limit -s）：這個配置只影響進程的初始線程；后續(xù)用pthread_create創(chuàng)建的線程都可以指定棧大小。HotSpot VM為了能精確控制Java線程的棧大小，特意不使用進程的初始線程（primordial thread）作為Java線程。

其他還要根據(jù)業(yè)務(wù)場景，選擇使用那種垃圾回收器，回收的策略。另外，當(dāng)需要保留GC信息時，也需要做一些設(shè)置。

典型配置可見：https://github.com/superhj1987/awesome-config/blob/master/tomcat/java_opts.conf

connector參數(shù)配置

protocol: 有三個選項：bio；nio；apr。建議使用apr選項，性能為最高。
connectionTimeout：連接的超時時間
maxThreads：最大線程數(shù)，此值限制了bio的最大連接數(shù)
minSpareThreads: 最大空閑線程數(shù)
acceptCount：可以接受的最大請求數(shù)目（未能得到處理的請求排隊）
maxConnection: 使用nio或者apr時，最大連接數(shù)受此值影響。

典型配置可見：https://github.com/superhj1987/awesome-config/blob/master/tomcat/connector.conf

一般的當(dāng)一個進程有500個線程在跑的話，那性能已經(jīng)是很低很低了。Tomcat默認配置的最大請求數(shù)是150。當(dāng)某個應(yīng)用擁有250個以上并發(fā)的時候，應(yīng)考慮應(yīng)用服務(wù)器的集群。

另外，并非是無限調(diào)大maxTreads和maxConnection就能無限調(diào)高并發(fā)能力的。線程越多，那么CPU花費在線程調(diào)度上的時間越多，同時，內(nèi)存消耗也就越大，那么就極大影響處理用戶的請求。受限于硬件資源，并發(fā)值是需要設(shè)置合適的值的。

對于tomcat這里有一個爭論就是：使用大內(nèi)存Tomcat好還是多個小的Tomcat集群好？（針對64位服務(wù)器以及Tomcat來說）

其實，這個要根據(jù)業(yè)務(wù)場景區(qū)別對待的。通常，大內(nèi)存Tomcat有以下問題：

一旦發(fā)生full gc，那么會非常耗時
一旦gc，dump出的堆快照太大，無法分析

因此，如果可以保證一定程度上程序的對象大部分都是朝生夕死的，老年代不會發(fā)生gc,那么使用大內(nèi)存Tomcat也是可以的。但是在伸縮性和高可用卻比不上使用小內(nèi)存（相對來說）Tomcat集群。

使用小內(nèi)存Tomcat集群則有以下優(yōu)勢：

可以根據(jù)系統(tǒng)的負載調(diào)整tc的數(shù)量，以達到資源的最大利用率，
可以防止單點故障。

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

MySQL

MySQL是目前最常用的關(guān)系型數(shù)據(jù)庫，支持復(fù)雜的查詢。但是其負載能力一般，很多時候一個系統(tǒng)的瓶頸就發(fā)生在MySQL這一點，當(dāng)然有時候也和SQL語句的效率有關(guān)。比如，牽扯到聯(lián)表的查詢一般說來效率是不會太高的。

影響數(shù)據(jù)庫性能的因素一般有以下幾點：

硬件配置：這個無需多說
數(shù)據(jù)庫設(shè)置：max_connection的一些配置會影響數(shù)據(jù)庫的連接數(shù)
數(shù)據(jù)表的設(shè)計：使用冗余字段避免聯(lián)表查詢；使用索引提高查詢效率
查詢語句是否合理：這個牽扯到的是個人的編碼素質(zhì)。比如，查詢符合某個條件的記錄，我見過有人把記錄全部查出來，再去逐條對比
引擎的選擇：myisam和innodb兩者的適用場景不同，不存在絕對的優(yōu)劣

拋開以上因素，當(dāng)數(shù)據(jù)量單表突破千萬甚至百萬時（和具體的數(shù)據(jù)有關(guān)），需要對mysql數(shù)據(jù)庫進行優(yōu)化，一種常見的方案就是分表：

垂直分表：在列維度的拆分
水平分表：行維度的拆分

此外，對于數(shù)據(jù)庫，可以使用讀寫分離的方式提高性能，尤其是對那種讀頻率遠大于寫頻率的業(yè)務(wù)場景。這里一般采用master/slave的方式實現(xiàn)讀寫分離，前面用程序控制或者加一個Proxy層?？梢赃x擇使用MySQL Proxy，編寫lua腳本來實現(xiàn)基于Proxy的MySQL讀寫分離；也可以通過程序來控制，根據(jù)不同的SQL語句選擇相應(yīng)的數(shù)據(jù)庫來操作，這個也是筆者公司目前在用的方案。由于此方案和業(yè)務(wù)強綁定，是很難有一個通用的方案的，其中比較成熟的是阿里的TDDL，但是由于未全部開源且對其他組件有依賴性，不推薦使用。

現(xiàn)在很多大的公司對這些分表、主從分離、分布式都基于MySQL做了自己的二次開發(fā)，形成了自己公司的一套分布式數(shù)據(jù)庫系統(tǒng)。比如阿里的Cobar、網(wǎng)易的DDB、360的Atlas等。當(dāng)然，很多大公司也研發(fā)了自己的MySQL分支，比較出名的就是姜承堯帶領(lǐng)研發(fā)的InnoSQL。

Redis

當(dāng)然，對于系統(tǒng)中并發(fā)很高并且訪問很頻繁的數(shù)據(jù)，關(guān)系型數(shù)據(jù)庫還是不能妥妥應(yīng)對。這時候就需要緩存數(shù)據(jù)庫出馬以隔離對MySQL的訪問，防止MySQL崩潰。

其中，Redis是目前用的比較多的緩存數(shù)據(jù)庫（當(dāng)然，也有直接把Redis當(dāng)做數(shù)據(jù)庫使用的）。Redis是單線程基于內(nèi)存的數(shù)據(jù)庫，讀寫性能遠遠超過MySQL。一般情況下，對Redis做讀寫分離主從同步就可以應(yīng)對大部分場景的應(yīng)用。但是這樣的方案缺少HA，尤其對于分布式應(yīng)用，是不可接受的。目前，Redis集群的實現(xiàn)方案有以下幾個：

Redis Cluster:這是一種去中心化的方案，是Redis的官方實現(xiàn)。是一種非常“重”的方案，已經(jīng)不是Redis單實例的“簡單、可依賴”了。目前應(yīng)用案例還很少，貌似國內(nèi)的芒果臺用了，結(jié)局不知道如何。
Twemproxy：這是Twitter開源的Redis和Memcached的Proxy方案。比較成熟，目前的應(yīng)用案例比較多，但也有一些缺陷，尤其在運維方面。比如無法平滑的擴容/縮容，運維不友好等。
Codis: 這個是豌豆莢開源的Redis Proxy方案，能夠兼容Twemproxy，并且對其做了很多改進。由豌豆莢于2014年11月開源，基于Go和C開發(fā)?，F(xiàn)已廣泛用于豌豆莢的各種Redis業(yè)務(wù)場景?，F(xiàn)在比Twemproxy快近100%。目前據(jù)我所知除了豌豆莢之外，Hulu也在使用這套方案。當(dāng)然，其升級項目Reborndb號稱比Codis還要厲害。

2.5 系統(tǒng)架構(gòu)

影響性能的系統(tǒng)架構(gòu)一般會有這幾方面：

負載均衡
同步 or 異步
28原則

2.5.1 負載均衡

負載均衡在服務(wù)端領(lǐng)域中是一個很關(guān)鍵的技術(shù)。可以分為以下兩種：

硬件負載均衡
軟件負載均衡

其中，硬件負載均衡的性能無疑是最優(yōu)的，其中以F5為代表。但是，與高性能并存的是其成本的昂貴。所以對于很多初創(chuàng)公司來說，一般是選用軟件負載均衡的方案。

軟件負載均衡中又可以分為四層負載均衡和七層負載均衡。上文在應(yīng)用服務(wù)器配置部分講了nginx的反向代理功能即七層的一種成熟解決方案，主要針對的是七層http協(xié)議（雖然最新的發(fā)布版本已經(jīng)支持四層負載均衡）。對于四層負載均衡，目前應(yīng)用最廣泛的是lvs。其是阿里的章文嵩博士帶領(lǐng)的團隊所研發(fā)的一款linux下的負載均衡軟件，本質(zhì)上是基于iptables實現(xiàn)的。分為三種工作模式：

NAT: 修改數(shù)據(jù)包destination ip，in和out都要經(jīng)過lvs。
DR：修改數(shù)據(jù)包mac地址，lvs和realserver需要在一個vlan。
IP TUUNEL：修改數(shù)據(jù)包destination ip和源ip，realserver需要支持ip tunnel協(xié)議。lvs和realserver不需要在一個vlan。

三種模式各有優(yōu)缺點，目前還有阿里開源的一個FULL NAT是在NAT原來的DNAT上加入了SNAT的功能。

此外，haproxy也是一款常用的負載均衡軟件。但限于對此使用較少，在此不做講述。

2.5.2 同步 or 異步

對于一個系統(tǒng)，很多業(yè)務(wù)需要面對使用同步機制或者是異步機制的選擇。比如，對于一篇帖子，一個用戶對其分享后，需要記錄用戶的分享記錄。如果你使用同步模式（分享的同時記錄此行為），那么響應(yīng)速度肯定會受到影響。而如果你考慮到分享過后，用戶并不會立刻去查看自己的分享記錄，犧牲這一點時效性，可以先完成分享的動作，然后異步記錄此行為，會提高分享請求的響應(yīng)速度（當(dāng)然，這里可能會有事務(wù)準(zhǔn)確性的問題）。有時候在某些業(yè)務(wù)邏輯上，在充分理解用戶訴求的基礎(chǔ)上，是可以犧牲某些特性來滿足用戶需求的。

這里值得一提的是，很多時候?qū)τ谝粋€業(yè)務(wù)流程，是可以拆開劃分為幾個步驟的，然后有些步驟完全可以異步并發(fā)執(zhí)行，能夠極大提高處理速度。

2.5.3 28原則

對于一個系統(tǒng)，20%的功能會帶來80%的流量。這就是28原則的意思，當(dāng)然也是我自己的一種表述。因此在設(shè)計系統(tǒng)的時候，對于80%的功能，其面對的請求壓力是很小的，是沒有必要進行過度設(shè)計的。但是對于另外20%的功能則是需要設(shè)計再設(shè)計、reivew再review，能夠做負載均衡就做負載均衡，能夠緩存就緩存，能夠做分布式就分布式，能夠把流程拆開異步化就異步化。

當(dāng)然，這個原則適用于生活中很多事物。