隨着業務的快速發展我們日常遇到的系統性能壓力問題也逐漸出現，甚至在部分場合會遇到一些突發的營銷活動，會導致系統性能突然暴漲，可能導致我們系統的癱瘓。最近幾年隨着電商的各種促銷活動，有一個詞也漸漸進入我們眼簾－－“全鏈路壓測”。
全鏈路壓測被眾多互聯網公司的程序員定義為核武器，傳統性能測試更多的是以事務為核心，更多的是由單個或者多個事務構成業務場景進行壓測。那全鏈路壓測到底是什么？一般指完全引入相關聯的系統，真實模擬線上硬件環境，更多的是以請求為核心，完全模擬真實請求流量，通過引流等方式進行場景的模擬進行壓測，更多的適用於業務鏈路較長的交易。
筆者以前只是一直聽說全鏈路壓測，但是並沒有真正經歷過，對全鏈路壓測的理解也不是很全面，前年在互聯網電商公司雙11的時候參加過一次全鏈路的壓測，當時全公司第一次做大范圍的全鏈路壓測，整個架構部也是第一次牽頭來完成了整個全鏈路壓測，經過大家1個月的努力，最后在活動期間完全扛住了壓力，並且還有性能過剩。當時做完后因為忙的太累，沒有進行過總結，最近新的公司正好在壓測，借此也總結下全鏈路壓測。
01 為什么需要全鏈路壓測
我們在整個業務流程中，最大的困難在於評估從用戶登錄到完成全部交易的整個鏈條中，核心頁面和交易關鍵交易的實際承載能力。如果得到了各個系統的實際承載能力，就可以在路由網關進行相關交易限流控制，來防止在大並發來了以后系統出現宕機，我們都知道一旦系統宕機就會導致災難性的后果，而且就算運維短時間重啟了起來恢復了運行，但是可能過了一會兒過程系統承載量又出現宕機，早期阿里在雙十一的時候就發生過這樣的問題，系統在0點，出現大面積癱瘓，重啟后又癱瘓。
為什么會出現這個問題，就是因為大家對整個全交易鏈條上的各個環節的系統承壓能力不清楚，所以在出現了全鏈路壓測，一方面能夠讓各個產品知道自己的承壓極限在哪？有的同學會問了通過單系統壓測不是也可以知道各個系統的承壓能力嗎？但是實際情況不可能那么簡單，那么順利，在活動開始的瞬間，從CDN、網關接入、前端、緩存、中間件、后端服務、數據庫整個交易鏈路都會面臨巨大的訪問壓力，這個時候系統服務除了受自生的影響，還依賴於其他關聯系統的情況，並且影響會一直蔓延，只要有一個節點出現故障，那么故障在上下游系統經過層層累加后會造成的影響誰都說不清楚，所以最好的辦法就是模擬完全的真實情況來做到提前心里有數。驗證的最好辦法就是讓事件提前發生，通過全鏈路壓測就可以提早發現問題。
另一方面也可以讓各個系統能夠有個明確的優化目標並找出性能瓶頸，同時對於一些特殊環節可以通過臨時增加公有雲的方式來提高整體的性能，一旦通過全鏈路壓測，了解了瓶頸所在就可以坦然的去按照壓測指標去申請公有雲資源，活動結束后再歸還資源，這樣做到成本最低化。
02 全鏈路壓測常常遇到的問題
如何開展全鏈路壓測？在說這個問題前，我們先考慮下，全鏈路壓測有哪些問題比較難解決。
1）涉及的系統太多，牽扯的開發人員太多；
在壓測過程中，做一個全鏈路的壓測一般會涉及到大量的系統，在整個壓測過程中，光各個產品的人員協調就是一個比較大的工程，牽扯到太多的產品經理和開發人員，如果公司對全鏈路壓測早期沒有足夠的重視，那么這個壓測工作是非常難開展的。
2）模擬的測試數據和訪問流量不真實；
在壓測過程中經常會遇到壓測后得到的數據不准確的問題，這就使得壓測出的數據參考性不強，為什么會產生這樣的問題？主要就是因為壓測的環境可能和生成環境存在誤差、參數存在不一樣的地方、測試數據存在不一樣的地方這些因素綜合起來導致測試結果的不可信。
3）壓測生產數據未隔離，影響生產環境；
在全鏈路壓測過程中，壓測數據可能會影響到生產環境的真實數據，舉個例子，電商系統在生產環境進行全鏈路壓測的時候可能會有很多壓測模擬用戶去下單，如果不做處理，直接下單的話會導致系統一下子會產生很多廢訂單，從而影響到庫存和生產訂單數據，影響到日常的正常運營。
03 如何開展全鏈路壓測
其實進行全鏈路壓測對於整個公司技術要求還是很高的，如果沒有一定能力的公司最好不要貿然嘗試全鏈路壓測，因為如果沒做好可能會把生產環境搞宕，所以對於沒有一定科技能力的公司還是盡量不要貿然追潮流實施全鏈路壓測。對於科技能力不強的公司如果也想達到全鏈路壓測那該怎么辦？其實辦法也很簡單，可以在壓測環境進行模擬，做一個比例模擬，模擬1%－2%的訪問量在測試環境進行壓測，得到數據后乘以對應的倍數來得到總的壓測指標，這里的比例當然不是簡單的倍數相乘，需要各個系統得到系統線性擴展和單機壓測指標的一個線性值，因為一般來說的線性擴展都不可能是100%的，一定會有一定擴展后的損失。
1）分析需壓測業務場景涉及系統
在壓測前我們一定要首先分析清楚需要壓測的業務場景，只有分析清楚了業務場景才能梳理出來涉及的相關系統，分析清楚后也可以更快的找到性能瓶頸進行系統優化。這個工作一般是由架構師來梳理並確認涉及的相關系統，梳理清楚后就可以反饋給總壓測負責人進行人員和資源的協調了。
2）協調各個壓測系統資源
在全鏈路壓測過程中，最難的工作其實不是系統優化、壓測環境搭建等技術工作，最難的是壓測資源的協調工作。這里的資源不單單指壓測硬件、公有雲等資源，還包括了人力資源，在整個壓測過程中，需要各個相關產品的產品經理和技術開發人人員參與進去，這個工作可能不是架構師或者一個牽頭產品的負責人能夠協調的動的，必須要有一個自上而下的推力去推動，需要一個有一定級別的領導做背書，我們當時是分管科技的老總召集了所有的產品經理和各個產品技術開發負責人開了一個全鏈路壓測的方案討論會，這個會一方面說明了這個事情的重要性，讓各個產品都當場立下軍令狀，並且安排出支持的人員，同時也授權給壓測負責人。這個搞定以后壓測負責人后續就可以光明正大的協調各個產品的配合人員了。
3）壓測環境
壓測環境也是個比較頭疼的問題，很多系統可能壓根就沒有壓測環境，所以全鏈路壓測有個和傳統壓測比較大的區別就是，全鏈路壓測是在生產環境，這種做法其實是存在一定風險的，一方面是系統風險，一方面是業務數據風險。對於全鏈路壓測系統風險一定是首要考慮的問題，不能因為壓測把系統搞宕機影響到日常生產環境的正常運營，我們當時做的電商系統還好，不涉及相關的監管。但是在銀行業這樣做還是有很大的風險的，一旦生產系統出現關鍵交易系統的宕機可能導致一些金融事故，會對金融市場造成恐慌，而且會被銀監會通報，所以銀行的壓測還是不要進行全鏈路壓測，不過可以在測試環境盡量仿真的模擬全鏈路壓測。
前年在電商環境上做全鏈路壓測直接在生產上進行壓測，用生產環境最大的好處就是環境的真實性，通過生產環境能夠最高程度的還原生產環境不用額外准備壓測環境。但是使用生產環境進行壓測需要考慮將請求和訪問、業務數據處理都進行隔離，防止影響到生產環境，具體如何實施，涉及到比較多的細節這里就不詳細描述了。總的思路就是在發起請求的時候通過請求報文頭中的壓測標示來進行區分處理，將壓測的流量都分流到指定的應用服務器和指定的存儲進行數據保存和處理。
進行全鏈路壓測的時候，為了防止系統崩潰，可以選擇在凌晨用戶量最小的時候進行，這樣就算發生故障也可以將影響降到最低。
4）壓測數據
環境准備好了，可能就需要考慮造壓測數據了，壓測數據准備有兩方面數據需要准備，一方面是壓測請求數據的准備，需要模擬請求數據，請求數據最好的辦法就是采用生產的真實數據，我們當時的做法是直接錄制3-5天的生產訪問請求流量，只需要對錄制的請求進行數據清洗就可以了，將某個用戶的請求替換成一個壓測虛擬用戶的請求，請求的商品也替換成壓測虛擬商品，這個數據漂白替換的工作是比較復雜的，對於做數據漂白的的同學對系統的接口非常了解，否則很可能造成業務數據的混亂，造成大量的業務報表和系統數據的臟數據；另一方面是測試數據的准備，我們當時准備了壓測虛擬商品的數據、虛擬商品庫存數據、虛擬供貨商、虛擬用戶。
5）壓測數據隔離
因為是在生產環境做的壓測，壓測數據需要與正常的業務數據隔離開，我們當時的方案是對於壓測的這些臟數據都做了特定標示，對於虛擬用戶、虛擬商品、虛擬訂單、虛擬庫存都是有特殊標示的，這樣這類數據在統計的時候都不會進行統計，在壓測后也會對這些數據進行清理，防止污染正常業務數據。
6）壓測數據實時監控
在壓測過程中，為了能發現性能問題，我們需要對壓測過程中各個系統的cpu、內存、磁盤io都進行系統層面的監控，同時也需要對各個業務節點的耗時進行監控，一方面從業務層面去監控壓測事務性能，另一方面從系統層面監控，這樣我們可以先從業務層面找到性能瓶頸，再單獨分析各個系統的系統層面的瓶頸，最終找到優化方案。
我們當時公司內部有個實時監控平台，這個平台是基於大眾點評開源的cat實現的多平台監控系統，能夠實時監控各個系統的實時交易運行情況，這樣能夠在第一時間發現遇到大流量的情況后，性能瓶頸在哪？然后進行針對性的優化。
04 全鏈路壓測優化思路
性能優化的核心在我看來其實就是一個充分利用系統資源並平衡IO的過程。這句話怎么理解，首先在保證代碼沒有問題的情況下，充分利用系統的cpu、內存、磁盤資源，一般來說在保證cpu、內存都消耗到80%以上基本上就達到了性能峰值了，但是我們在壓測過程中常常遇到的問題是cpu、內存消耗都不高，而是卡在了IO上，IO包括了磁盤IO、數據庫IO、網絡IO，我們需要根據監控的數據從這3方面去找到瓶頸，並去解決IO的問題。一般來說造成這種情況一般都是因為IO聚集導致了阻塞，可以考慮采用緩存、異步的方式去解決，對於一些關鍵交易的事務的完整性可以考慮采用先緩存最后通過緩存同步數據庫的方式來保證最終一致性。
全鏈路壓測一般可以從3個層面去進行優化：
1）優化單個系統性能
就算不進行全鏈路壓測，單個系統的性能優化也是要考慮的問題，對單個系統的優化，其實方法有很多，但是萬變不離其宗，就是在壓測過程中監控系統各項指標，從中挑出慢交易，針對慢交易進行優化，對於聯機系統大部分都是因為各種IO問題導致性能上不去。可以根據各種介質IO訪問的性能來優化（內存緩存>文件>數據庫>網絡），基本上通過緩存和異步處理這兩顆銀彈就可以解決80%的性能問題。
當鏈路上的單個系統性能提升了，整體的全鏈路性能自然就提升了。
2）優化關聯路徑
但是在優化的過程中，我們常常發現絕大部分系統性能都很高，但是總的TPS還是很低，這就需要去根據監控了解下目前整個鏈路上的性能瓶頸到底在哪？通過全鏈路監控可以發現整個業務流程在哪個節點耗時最長，那么這個耗時最長的節點就是我們需要優化的地方，只要這些關鍵路徑的性能提升上來以后整體的性能就上來了。關鍵節點的優化方式和單系統優化思路一致。
3）優化業務流程
很多開發人員都會將優化思路集中在技術層面，但是很多時候從業務流程上進行優化效果可能更好，而且提升的效果會非常明顯。業務層面的優化主要是從分散IO的角度去考慮，將實際業務場景中的用戶請求進行分散，例如常見的大秒系統、驗證碼系統、游戲工具等都是為了進行業務層面的IO分散來保證。這類業務流程的優化首先要梳理清楚整個業務流程，包括所有的細節。然后針對每個環節在保證用戶體驗的情況下分散用戶請求，這樣可以最大限度的保證體驗。
05 總結
整個壓測優化過程就是一個不斷優化不斷改進的過程，通過長期的循序漸進的改進不斷發現問題，優化系統，才能讓系統的穩定性和性能都得到質的提升。整個壓測優化的思路其實和高並發架構設計的思路是一致的，接下來也會寫一些關於高並發架構的文章，本篇的全鏈路壓測只是給大家做個入門介紹，其中涉及到的問題遠遠不止文中提到的這些，而且問題的解決辦法也遠遠不是說的那么簡單，造虛擬用戶、虛擬商品並不是隨便造的，數據隔離也不是簡單加個前綴什么的就可以的，也是有很多講究的，因為全鏈路壓測涉及到的內容太多而且還涉及到各家公司的組織架構，所以這里就不展開了，只是給大家一個思路，按照這個思路結合自己公司的情況去實施，慢慢摸索總結出一套適合自己產品的全鏈路壓測。