今天給大家分享一個話題，那就是假設你公司要搞一場雙 11 大促，現在告訴你說，咱們公司就是打算搞了，那你此時會一臉懵逼的說，雙 11 大促？會有多大并發啊？我們系統能抗住嗎？

你要這樣的話，那老板是一定不高興的了。所以今天就得給大家分析一下，假設你公司要搞大促，你怎么去通過全鏈路壓測評估一下你的核心系統鏈路能抗多大流量？

公司核心系統業務調用鏈路

首先，如果要為雙 11 大促做準備，咱們必須要對線上系統直接發起全鏈路壓測。

比如說在凌晨業務低峰期的時候，我們自己用壓測系統對咱們的線上核心鏈路發起全鏈路壓測，看看到底我們的整個系統可以抗多少流量，然后再分析一下，搞大促的時候，大概會有多少流量，接著就可以針對大促活動的流量預估，去擴容一下機器。

那么如果要搞全鏈路壓測的話，這個全鏈路壓測背后的原理大家知道嗎？我們得先給大家講一下這個全鏈路壓測背后的原理。

先說一個非常典型的鏈路，假設我們整個平臺的入口是業務系統 A，然后他的核心鏈路里面，他會調依次調用業務系統 B、業務系統 C、業務系統 D，同時還會讀寫自己的數據庫。

然后業務系統 B 又會調用業務系統 E，業務系統 E 又會調用業務系統 F，業務系統 D 又會調用業務系統 G，每個業務系統都會讀寫自己的數據庫。

如下圖所示：

看看上面這個鏈路是不是感覺非常復雜？沒錯的，對于很多公司的核心系統鏈路來說，就是可能會有很多個系統調用的鏈路。

那么這個時候來說的話，我們假設所有業務系統都是單機部署的，現在來看看，整個這個鏈路集成在一起，大概一秒鐘可以跑完多少次這個鏈路？

QPS 和 TPS 的概念

這里給大家解釋一下 QPS 和 TPS 的概念，QPS 是 Query Per Second，往往是針對單個系統自己的接口的，意思就是說自己這個接口每秒被請求多少次，TPS 是 Transaction Per Second，意思就是說每秒鐘可以完成的事務數量。

所以這個 QPS 就不太符合我們這里對全鏈路壓測的定位了，因為全鏈路跑下來，那不是說每秒多少請求可以定義的。

TPS 是比較符合這個定位的，因為我們要看的是每秒鐘這個鏈路跑完，可以跑多少次，跑完一次完整的鏈路，咱們可以認為一個 TPS，每秒鐘可以跑完多少次這個鏈路，那就是 TPS 了。

一次鏈路跑完是靠什么跑的呢？

好，那么接著給大家分析，這個一次鏈路跑完是靠什么跑的呢？

答案顯而易見，靠的是咱們鏈路入口的那個業務系統 A 的一個線程，因為假設業務系統 A 抗的是 http 請求和流量，那么業務系統 A 必然是靠 tomcat 來接收 http 請求的。

然后 tomcat 是會啟動多個線程來處理一個一個的請求的，每一個請求進來都會交給一個線程來處理。

大家看下圖：

接著呢，這個線程收到了一個請求之后，就會按照調用鏈路依次去調用，所以說，要走完一個鏈路，等于業務系統 B、業務系統 E、業務系統 F 這條鏈路得先走完，然后業務系統 C，接著是業務系統 D 和業務系統 G，再有是自己的數據庫訪問。

單擊全鏈路壓測 TPS 估算

這整個鏈路跑完大概要花多久呢？這就要看情況了，要看每個業務系統要處理多少時間了，但是這么復雜的鏈路，往往跑完起碼要幾百毫秒，我們算他 500ms 吧，基本不多也不少了。

那所以說，此時我們的 tomcat 中一個線程，等于每秒也就跑完兩次鏈路而已。

那如果說業務系統 A 的 tomcat 里開啟了 200 個線程呢？那等于是每秒的 TPS 大概也就 200*2=400 而已。

也就是業務系統 A 單臺機器在一秒內，200 個線程可以處理 400 個請求，跑完 400 次鏈路，這就是全鏈路壓測的意義所在，我們要看的是全鏈路跑完一次要耗費多久，然后在較大壓力下，一個線程每秒可以跑完幾次鏈路，再計算單機的 TPS。

進而就可以根據這個單機全鏈路壓測去估算搞大促的時候，每秒要接收多少請求，跑完多少次鏈路，然后就知道要部署多少臺機器了。