一、時機

首先要清楚的一點就是，什麼時候開始做全鏈路壓測？我們有另外一個業務線，現在就沒有打算做，那個業務線的日均單不到十萬，而要壓測的業務線的日均單到了200萬，但這並不意味著200萬是一個標準，我覺得可以從下面幾點考慮：

• 業務發展速度。在可以預期的一段時間（最好是半年，一個季度有點晚）內，業務會有較快速的發展，線上機器必須要大幅度擴容；但是，擴容有的時候並不是線性的，從兩臺擴充套件到四臺，你得服務能力或者能提高兩倍，但是在繼續擴容，服務能力就有可能提高不上去了，因為要受限於其他的模組，比如，DB，公共組建，中介軟體等等。
• 鏈路的複雜程度在擴張。一般而言，隨著業務的發展，我們的介面會越來越多，系統會逐漸的做分散式，業務線內部的模組越抽象越多，業務線跟其他業務線的互動也也越來越多，我們無法單純的根據自己系統的處理能力來評估介面的服務能力。
• 對單機壓測結果越來越沒有自信。這也是一個很好的指標，一般而言，我們都會壓一下我們自己的模組，但是身為模組的owner，自己越來越清楚，單機的壓測不代表真實的場景，內心會越來越虛，這個時候，就要考慮全鏈路了。

二、方法

下面具體看看要做全鏈路需要哪些工作。

1、梳理核心鏈路的流程和邊界

因為全鏈路一定會設計多個流程，多種技術，多個依賴，所以，要做全鏈路壓測，首先要梳理核心鏈路的流程，明確鏈路的邊界，我覺得梳理這個是比較簡單的，因為一個業務再複雜，它的核心鏈路肯定有限，例如，我們的核心鏈路就包括：

• 建立訂單
• 開始形成
• 獲取行程費用
• 結束訂單
• 支付訂單
• 完單

核心鏈路是一個業務的核心，這一塊應該可以很快梳理清楚，但是，難點在於梳理清楚鏈路的邊界。例如：

• 開始訂單要做風控
• 結束訂單要發券
• 結束訂單要通知使用者費用
• 完單後要通知營銷
• 。。。

在核心鏈路的基礎上，我們會有很多的分支業務，而這些分支業務有的可以參與壓測，有的不能參與壓測：原因多種多樣，比如，這個分支業務不是我們自己公司的，或者這個分支業務本身就不怎麼重要，可以降級掉，甚至有的業務就是不能壓測，比如給使用者下放push訊息。

在具體實施的時候，業務反覆跟整個鏈路的每個業務owner反覆確認，哪些是核心業務，哪些是分支業務，哪些參與壓測，哪些不參與壓測，把這些形成文件，逐個跟進。

2、提供全鏈路壓測的底層支援

要做全鏈路，要實現非核心鏈路的降級，就必須對底層的產品，例如中介軟體，資料庫訪問，MQ等做改動，讓這些中介軟體支援全鏈路壓測。我們整體看看，一般需要哪些改動。

我們把模型簡化一下，如下圖，雖然是簡化的，但是基本上包括主流的分散式業務的技術棧。

可以看到，底層主要需要提供下面的支援：

• 全鏈路透傳壓測標誌：必須有一種在全鏈路透傳壓測標誌的能力，並且必須基於一次請求，也就是同一個traceId，現在，大部分分散式業務都會接入trace系統，例如，google的dapper，阿里的鷹眼等，對trace系統進行改造，使其能夠透傳壓測標誌，需要透傳的路徑大概有：HTTP、RPC(DUBBO)、MQ、執行緒池等。
• 影子表：參與壓測的業務，要逐個排查自己依賴的資料庫，然後建立影子表，影子表必須跟正常表的schema保持一致，可以在每次壓測時候手動建立，也可以推動DBA自動建立。建立好影子表後，如果當前流量是壓測流量，那麼寫入和讀取都走影子表。如果有自己的資料庫中介軟體最好，沒有的話可以藉助於Mybatis的Interceptor機制。
• 日誌-影子目錄：為了防止壓測流程的日誌對正常日誌造成干擾，需要改造日誌元件，將壓測流量產生的日誌落入到影子目錄。影子目錄可以有日誌元件自動建立。
• MQ支援是否消費壓測流量：有的時候，全鏈路會通過MQ進行傳遞，所以，必須在消費MQ的時候進行選擇：是否選擇消費壓測流量的MQ訊息。這就需要對MQ系統進行改造，一方面使其可以透傳壓測流量，另一方面，需要支援配置是否消費壓測的MQ訊息。
• 快取，大資料隔離：還有一些場景，比如，快取層，大資料層對壓測流量的處理也要考慮隔離。快取可以使用不同的叢集；大資料可以直接不收集壓測的資料。

3、思考全鏈路壓測的資料怎麼mock

流程支援之後，還有關鍵的一步，就是考慮如何構造壓測的mock資料。在使用影子表之後，可以比較輕鬆的實現跟正常資料隔離，那剩下的就是好構造好mock資料，有幾點需要考慮：

• 使用者資料要提前做好認證等準備工作。
• Mock資料要儘可能跟真實資料保持一致，比如，價格水平，圖片數量，地址資訊等等。
• Mock資料有些限制需要放開，比如，庫存，一些運營性質的活動可以取消等。
• 千萬不要汙染正常資料：認真梳理資料處理的每一個環節，確保mock資料的處理結果不會寫入到正常庫裡面。

4、做好壓測流量的降級預案

這一點尤其重要，特別當業務特別的複雜的時候，一定要確認好，第三方依賴能不能接收壓測流量，所以，只要依賴第三方的服務，我們都要接入壓測流量降級的開關，防止對第三方服務的汙染。實現上，可以整合到RPC機制上，也可以提供類似於單獨的限流元件。

5、梳理監控體系

確認好流程的技術支援和Mock資料的支援後，還要讓每個業務梳理自己的監控，確保壓測時候能夠準確，及時的發現問題。

• 核心介面和核心依賴的流量和耗時監控。
• 中介軟體元件，快取，資料庫的監控報警。
• 機器的指標報警。

6、線下做好預演

真實的壓測之前，肯定要進行預演，預演主要確認：

• 壓測流程是否寫入到了正確的目的地，例如，寫入到影子表，影子目錄，壓測cache等等。
• 壓測流量的降級是否完備和有效。
• 進一步確保監控都已到位。

7、儘量模擬現實

我們壓測的腳步要儘可能的模擬現實，比如：

• 購買的行為：不是下單後立即購買，而是要等一下子。
• 騎車子的行為：開鎖後並不是裡面換車，而是騎一會。
• 使用者付款的行為：壓測時候肯定不會真的讓使用者付款，所以我們得模擬使用者付款。
• 購買商品的資料。
• ...

壓測的指令碼要跟各個業務確認，儘量跟線上真實的使用者行為保持一致。

8、逐步平滑加壓

壓測的時候，逐步加壓，並且要保持平滑加壓，不要把一秒的流量都在前面幾毫秒內都壓出去。

9、形成報告

每次壓測後進行復盤，總結壓測中的問題，壓測結果，機器的指標等資料形成報告發給大家，制訂好後續的Action以及跟進的負責人。

三、推進

全鏈路壓測的技術難點不多，除了要花時間梳理流程和思考如何處理資料之外，最難的就是整個鏈路跨多個業務，甚至部門，需要跟進每個業務線的進度，確保大家能夠在給定的時間點進行聯調以及進行壓測。在推進的時候，按照核心鏈路所在的模組進行跟進，每個模組出一個owner，各個owner跟進核心的介面和依賴，每週大家碰一下同步下總體的進度。