1、淺談當前行業現狀

在開始全鏈路壓測學習前，我們先來簡單介紹一下當前全鏈路壓測行業現狀，
在互聯網行業中，小魚發現一個很有趣的現象：

• 熟悉或者了解性能測驗的人，大概有50%；
• 而在這50%人群中，精通性能測驗的，僅僅有20%；
• 而在這20%的性能測驗人中，做過全鏈路壓測不足的 5%；

這是一個很尷尬的結果，
小魚在《深聊性能測驗，從入門到放棄之：初識性能測驗》這篇就介紹過，性能測驗是一個綜合性學科，一個人是做不來的，
而全鏈路測驗呢，我們或多或少在網上搜索或者公眾號的關于全鏈路壓測的文章，無非就以下幾個特點：

• 目標和方案只有摘要級的說明；
• 全鏈路壓測平臺沒有細節描述，很籠統；
• 只有少之又少的大廠一些籠統的資料，也沒有投入成本(例如：人員成本、資金成本、時間成本)的資料；
• 沒有架構級全鏈路改造細節；
• 沒有架構級監控平臺范圍的細節；
• 沒有性能分析邏輯的細節；

所以，看過這些文章，可能還是一頭霧水：

• 首先：不知道自己的企業是否能支撐全鏈路壓測；
• 其次：不知道應該如何具體實施；
• 第三：不知道如何計算投入的成本，

我說了這么多，可能還有的同學還是不理解，我在舉個例子：
某企業為了跟潮流，要做全鏈路壓測，但是由于本身的限制，并不具備全鏈路壓測的條件，只做了一些小的動作，在線上減少覆寫范圍并分段進行壓測，最后的結果，可想而知，這完全失去了全鏈路壓測的根本價值，

全鏈路壓測的出發點是對線上的真實系統做改造后直接在線上壓測！

實際上的全鏈路壓測的落地，是需要經過各種綜合考量后的結果，
從整個全鏈路專案來看，上到公司BOSS，下到各個工程師都需要全部參與進來，
換句話說，全鏈路涉及到角色如下：

• 公司BOSS
• 產品經理
• 架構師
• 開發工程師
• 測驗工程師
• 運維工程師

不同的崗位，關注點也不同：

• BOSS：全鏈路壓測帶來的業務容量提升和企業利潤增長；
• 產品經理：業務容量的增長和后續功能的設計；
• 架構師：全域架構設計對全鏈路壓測的宏觀支撐；
• 開發工程師：業務細節和技術細節的改造；
• 測驗工程師：覆寫住這些改造；
• 運維工程師：全鏈路改造和線上的壓測程序對系統整體狀態的影響，

所以，如何掌握全鏈路壓測的重要性，就不言而喻，
在當今全鏈路壓測趨勢下，我們要做的，不僅僅是如何進行全鏈路壓測，
還需掌握，如何統籌搭建運行全鏈路壓測，
接下來，我們就來認識下，什么是全鏈路壓測，全鏈路壓測的難點及目標，

2、初識全鏈路壓測

2.1 全鏈路壓測的難點

很多人覺得全鏈路壓測的難點，是不是如何搭建環境，如何進行壓測？
不然，
其實全鏈路壓測的難點，是管理協調；
為什么這么說呢，
上面小魚也提到了，全鏈路壓測涉及到角色多，系統多，鏈路長，所以必然導致管理成本增加，
相比較而言，技術的實作就是細節的落地程序，消耗的只是人員和時間成本，

但是，其實也算是很遺憾的事情，我們的專欄，并不會過多的章節來介紹管理協調的技巧，畢竟，更多的同學，是針對全鏈路壓測的技術來的，

2.2 全鏈路壓測的目標

在性能領域中，全鏈路壓測一直都是大廠的利器，也是讓小廠趨之如騖；
所以，我們就要來看下，全鏈路到底有什么神奇的功效，在互聯網的公司有這么高的熱度，
要理解這一點，我們得先看看全鏈路壓測的目標：

• 全鏈路壓測被稱為系統整體容量保障的核武器；
• 全鏈路壓測可以實作生產環境的壓測服務，模擬真實的生產峰值場景，以發現真實的線上瓶頸并實作監控分析；
• 全鏈路壓測可以實作精準的容量規劃，確保線上系統的正常運行；
• 全鏈路壓測可以實作海量的并發請求，以模擬真實的用戶峰值場景；
• 全鏈路壓測可以實作壓測流量和生產流量的隔離，避免對生產流量產生影響；
• 全鏈路壓測可以自動化壓測，減少人工成本，并提高壓測頻率，快速發現問題；

看完這些，你應該就能知道，為什么全鏈路壓測會有這么神奇的功效了，
其實這些還沒完，如果你是在性能領域多年，那么多多少少會看過一些全鏈路壓測的文章，而這些文章中，通常都會涉及到一些阿里，位元組，美團，滴滴，京東等大廠的資訊，
而這些文章最后給人的感覺就是：為了增加系統運行安全性，全鏈路壓測是企業必須要做的一件事情，

既然全鏈路壓測這么好，我們要不要跟風呢？

想要了解一件事情，就是去拆解這件事，
所以，我們接下來就來拆解全鏈路壓測，

2.3 拆解全鏈路壓測

我們先來拆解一下全鏈路壓測，啥是“鏈路”？簡單點說就是幾個點連成的線，這個詞在 IT 行業中非常常用，但是在性能行業中，卻是近幾年才被廣泛使用的“新詞”，要講鏈路，就得說到微服務分布式架構的發展，
一開始，在微服務分布式架構還沒有流行起來的時候，人們大多使用 SOA 架構，它大概的技術架構是這樣的：

系統之間的呼叫，都會通過ESB，因為呼叫的鏈路比較短，
進入到微服務分布式架構之后，由于微服務被拆得越來越細，大概的技術架構就變成了下圖所示的樣子：

這里的流程圖只是舉個例子，

從圖上可以看到，鏈路變長了，這是大流量帶來的系統拆分導致的，在這種情況下，識別問題也就更加困難了，
我們來總結一下這兩個架構圖：

• 原來一個系統的功能點多，現在一個系統功能點少；
• 原來測驗一個系統就有一堆的業務邏輯，現在測驗一個系統只有很簡單的業務邏輯；
• 原來一個系統就可以完成的業務操作，現在得跳好幾個系統才能實作；

在互聯網的初期，壓測主要關注單系統介面，而這完全不能說明系統處理業務的容量能力，
隨著業務的大規模發展，性能也必須做到覆寫“全部”系統，“全鏈路”這個概念就顯得格外重要了，它指的是系統的全鏈路，
說到這，“全鏈路”的內涵就解釋得差不多了，那說到壓測，就得有工具、有平臺，

由于系統架構的改變是容量改變引起的，因而容量出現大爆發的時候，要想實作壓測，工具就必須支持這么大的容量，而之前常用的壓力工具像 LoadRunner、JMeter 等，它們本身在分布執行能力、引數化拆分管理能力等方面都有著天生的弊端，所以我們必須另外打造具有大容量并發能力的工具，
這也是現在各企業想盡辦法來實作自己的大并發壓測平臺的原因，

為了加深理解，我們再通過全鏈路線上壓測與傳統線下壓測做對比：

從表中，我們可以大致的看出來，全鏈路線上壓測與傳統線下壓測的區別點，

當然，線下也可以使用 脫敏的生產資料，這沒有固定的要求，

其實最關鍵的一點區別，就是：線上 還是線下

其他的區別也可以不算是區別，因為那些區別點都是可以平衡掉的，比如說壓力場景、鋪底資料、監控手段等，關鍵在于投入多少，
投入的內容包括了：系統的改造投入、人員的投入、環境的投入、時間的投入，

2.4 到底要不要全鏈路壓測

實際上，要不要使用全鏈路壓，測需要充分考慮企業的實際條件，我們可以通過以下幾個問題來入手，

• 1、企業有沒有那么大的流量需求？
  如果不到幾十萬、上百萬、上千萬 / 每秒的交易量，其實完全不用考慮全鏈路壓測平臺的實作邏輯，如果你只是覺得這邏輯聽起來更高大上而去實作它，那投入的成本等于說是打了水漂，
• 2、你的系統要不要做全鏈路線上壓測？
  如果不是在線上做全鏈路壓測，那很多業務流量的改造作業就可以完全忽略，甚至，我們都不用考慮改造什么壓力工具，這就是給自己找麻煩(有這時間擼串不香嗎)，
• 3、系統能不能做全鏈路線上壓測？
  在網上可以看到，全鏈路壓測90%都是互聯網大廠，為什么呢？首先是因為請求量大；其次，做全鏈路線上壓測的系統，即使出了問題，也不會對企業利潤產生太大的影響，這一點至關重要，
• 4、組織支持不支持你做真正的全鏈路線上壓測？
  在全鏈路線上壓測這件事情上，必然不是底層干活的人（部門經理及以下）可以決定的，全鏈路線上壓測是需要企業上下層協調一致才可以做得到的，如果領導只是給你安排了一個做全鏈路線上壓測的任務，但沒有給你具體的權限支撐，是不可能做得下去的，而恰好有很多上層領導就是這種光安排任務，不給具體支持的風格，
  這時，你得跟領導詳細溝通一下，把成本利弊都分析清楚，如果從企業角度思考后，你們一致認為全鏈路壓測是必須要做的，那就需要領導更具體的支持才行，不然可能很難推進，

通過以上4點，我相信，你會放棄當初的想法，覺得自己的公司，并不適合做全鏈路，
但是，針對另外一些企業，全鏈路壓測是不可或缺的，因為它能解決以下三個問題：

• 直接使用生產環境，避免了環境的差異性；
• 實作高并發廣域網壓測平臺，模擬了真實的用戶場景；
• 不用進行線下線上容量的推算；

傳統的線下壓測顯然做不到這三點，如果以上三個問題對企業的影響較大，那么全鏈路壓測就很有必要了，

3、全鏈路壓測涉及改造點

上面說到，全鏈路壓測對某些企業必不可少的，但是，凡事都有利與弊，
做全鏈路壓測，就涉及到改造，具體有哪些，我們一起來看，

3.1 壓力工具改造

這就涉及到流量問題，
如果你的壓力場景只需要萬級每秒以下的請求量級，其實不需要做工具改造，傳統工具就能做得到，
但是如果需要更大流量，就得對壓力工具進行改造了，壓力工具改造的內容有哪些呢？

• 壓力發起部分：主要是多節點分布式的改造；
• 引數化部分：主要是資料量大引起的改造需求，在傳統的壓測工具中，基本上都是使用 Master-Slave 的方式，master 負責拆分引數化資料，但當資料量過大的時候，顯然這是個問題點，

改造的部分只有這兩點，在其他的功能點上傳統的壓力工具是可以覆寫大流量的壓測需求的，

3.2 業務流量改造與隔離

在業務流量的改造與隔離，一般有兩種方法：

• 1、實作全鏈路的壓測流量識別，從而實作隔離；
• 2、只在入口做壓測流量的識別，直接旁路到另一套獨立的鏈路中去，

3.2.1 全鏈路壓測流量識別

業務標識改造的目的：實作業務流量的隔離，
業務流量隔離的目的：不讓壓測流量影響真實的線上用戶，

貫穿業務改造的關鍵是整個業務流的識別跟蹤，最后還可以方便地進行資料的清理，

具體業務改造需要包含的內容：

• 腳本改造
  也就是加上流量標識，以實作后續的流量隔離，這一點任何一個壓力工具都只需要加個引數即可，沒有復雜度，
• 應用服務改造
  這是改造作業量最大的部分，改造要實作的是對流量標識的識別，再把請求旁路到相應的存盤組件中去，
  應用的改造主要是對現有的業務代碼進行入侵式的改造，增加業務開發的作業量， 實作的手段就是跨執行緒透傳，將壓測流量寫入 ThreadLocal 物件中，
• 中間件的改造
  對于一些跨服務呼叫使用的中間件，由于需要對壓測流量進行標識，所以也是需要改造的，
• 存盤邏輯的改造
  不管是快取還是資料庫、佇列，都要對壓測流量進行識別，以便隔離，目的就是不影響生產資料，
  對快取（比如 Redis)，我們可以實作不同的 key 值；對資料庫，我們可以實作影子表或影子庫，
• 日志改造
  壓測流量的日志最好不要和生產日志在一起，

3.2.2 入口壓測流量識別

針對入口做壓測流量識別，改造方法，就相對簡單：
只要在網關做壓測流量的識別即可，后面就全都是部署的活了，

4、總結

到這里，今天的內容就講完了，
我們在回顧一下，今天主要分享的內容：

• 全鏈路壓測的行業現狀
• 什么是全鏈路壓測
• 全鏈路壓測的難點及目標
• 到底要不要做全鏈路壓測
• 全鏈路壓測的改造

面對全鏈路壓測的優點，我們也要理性的分析有利用，
不能盲目的跟風，不然只能適得其反，
一切都要從實際地位出發，做符合實際的事情，才能得到真正的價值，