壓測的一些思路

時機

首先要清楚的一點就是，何時開始作全鏈路壓測？咱們有另一個業務線，如今就沒有打算作，那個業務線的日均單不到十萬，而要壓測的業務線的日均單到了200萬，但這並不意味着200萬是一個標準，我以爲能夠從下面幾點考慮：

• 業務發展速度。在能夠預期的一段時間（最好是半年，一個季度有點晚）內，業務會有較快速的發展，線上機器必需要大幅度擴容；可是，擴容有的時候並非線性的，從兩臺擴展到四臺，你得服務能力或者能提升兩倍，可是在繼續擴容，服務能力就有可能提升不上去了，由於要受限於其餘的模塊，好比，DB，公共組建，中間件等等
• 鏈路的複雜程度在擴張。通常而言，隨着業務的發展，咱們的接口會愈來愈多，系統會逐漸的作分佈式，業務線內部的模塊越抽象越多，業務線跟其餘業務線的交互也也愈來愈多，咱們沒法單純的根據本身系統的處理能力來評估接口的服務能力。
• 對單機壓測結果愈來愈沒有自信。這也是一個很好的指標，通常而言，咱們都會壓一下咱們本身的模塊，可是身爲模塊的owner，本身愈來愈清楚，單機的壓測不表明真實的場景，心裏會愈來愈虛，這個時候，就要考慮全鏈路了。

方法

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

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

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

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

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

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

在覈心鏈路的基礎上，咱們會有不少的分支業務，而這些分支業務有的能夠參與壓測，有的不能參與壓測：緣由多種多樣，好比，這個分支業務不是咱們本身公司的，或者這個分支業務自己就不怎麼重要，能夠降級掉，甚至有的業務就是不能壓測，好比給用戶下放push消息。

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

提供全鏈路壓測的底層支持

要作全鏈路，要實現非核心鏈路的降級，就必須對底層的產品，例如中間件，數據庫訪問，MQ等作改動，讓這些中間件支持全鏈路壓測。咱們總體看看，通常須要哪些改動。

咱們把模型簡化一下，以下圖，雖然是簡化的，可是基本上包括主流的分佈式業務的技術棧。

能夠看到，底層主要須要提供下面的支持：

• 全鏈路透傳壓測標誌：必須有一種在全鏈路透傳壓測標誌的能力，而且必須基於一次請求，也就是同一個traceId，如今，大部分分佈式業務都會接入trace系統，例如，google的dapper，阿里的鷹眼等，對trace系統進行改造，使其可以透傳壓測標誌，須要透傳的路徑大概有：
  • HTTP,RPC(DUBBO),MQ,線程池等
• 影子表：參與壓測的業務，要逐個排查本身依賴的數據庫，而後建立影子表，影子表必須跟正常表的schema保持一致，能夠在每次壓測時候手動建立，也能夠推進DBA自動建立。建立好影子表後，若是當前流量是壓測流量，那麼寫入和讀取都走影子表。若是有本身的數據庫中間件最好，沒有的話能夠藉助於Mybatis的Interceptor機制。
• 日誌-影子目錄：爲了防止壓測流程的日誌對正常日誌形成干擾，須要改造日誌組件，將壓測流量產生的日誌落入到影子目錄。影子目錄能夠有日誌組件自動建立。
• MQ支持是否消費壓測流量：有的時候，全鏈路會經過MQ進行傳遞，因此，必須在消費MQ的時候進行選擇：是否選擇消費壓測流量的MQ消息。這就須要對MQ系統進行改造，一方面使其能夠透傳壓測流量，另外一方面，須要支持配置是否消費壓測的MQ消息
• 緩存，大數據隔離：還有一些場景，好比，緩存層，大數據層對壓測流量的處理也要考慮隔離。緩存可使用不一樣的集羣；大數據能夠直接不收集壓測的數據。

思考全鏈路壓測的數據怎麼mock

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

• 用戶數據要提早作好認證等準備工做
• Mock數據要儘量跟真實數據保持一致，好比，價格水平，圖片數量，地址信息等等
• Mock數據有些限制須要放開，好比，庫存，一些運營性質的活動能夠取消等
• 千萬不要污染正常數據：認真梳理數據處理的每個環節，確保mock數據的處理結果不會寫入到正常庫裏面

作好壓測流量的降級預案

這一點尤爲重要，特別當業務特別的複雜的時候，必定要確認好，第三方依賴能不能接收壓測流量，因此，只要依賴第三方的服務，咱們都要接入壓測流量降級的開關，防止對第三方服務的污染。實現上，能夠集成到RPC機制上，也能夠提供相似於單獨的限流組件。

梳理監控體系

確認好流程的技術支持和Mock數據的支持後，還要讓每一個業務梳理本身的監控，確保壓測時候可以準確，及時的發現問題。

• 核心接口和核心依賴的流量和耗時監控
• 中間件組件，緩存，數據庫的監控報警
• 機器的指標報警

線下作好預演

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

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

儘可能模擬現實

咱們壓測的腳步要儘量的模擬現實，好比：

• 購買的行爲：不是下單後當即購買，而是要等一會兒
• 騎車子的行爲：開鎖後並非裏面換車，而是騎一會
• 用戶付款的行爲：壓測時候確定不會真的讓用戶付款，因此咱們得模擬用戶付款
• 購買商品的數據
• 。。。

壓測的腳步要跟各個業務確認，儘可能跟線上真實的用戶行爲保持一致

逐步平滑加壓

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

造成報告

每次壓測後進行復盤，總結壓測中的問題，壓測結果，機器的指標等數據造成報告發給你們，制訂好後續的Action以及跟進的負責人。

推動

全鏈路壓測的技術難點很少，除了要花時間梳理流程和思考如何處理數據以外，最難的就是整個鏈路跨多個業務，甚至部門，須要跟進每一個業務線的進度，確保你們可以在給定的時間點進行聯調以及進行壓測。在推動的時候，按照核心鏈路所在的模塊進行跟進，每一個模塊出一個owner，各個owner跟進核心的接口和依賴，每週你們碰一下同步下整體的進度。