jul 15, 2018 | 技術
| hits
參與了我們業務的全鏈路壓測，雖然過程磕磕絆絆，壓測的當天晚上還在寫壓測指令碼，但是核心鏈路的壓測還是做了起來，效果也不錯，當前晚上就爆出了乙個p1級的bug。這篇文章就總結下如何做核心鏈路的全鏈路壓測。
首先要清楚的一點就是，什麼時候開始做全鏈路壓測？我們有另外乙個業務線，現在就沒有打算做，那個業務線的日均單不到十萬，而要壓測的業務線的日均單到了200萬，但這並不意味著200萬是乙個標準，我覺得可以從下面幾點考慮：
下面具體看看要做全鏈路需要哪些工作。
梳理核心鏈路的流程和邊界
因為全鏈路一定會設計多個流程，多種技術，多個依賴，所以，要做全鏈路壓測，首先要梳理核心鏈路的流程，明確鏈路的邊界，我覺得梳理這個是比較簡單的，因為乙個業務再複雜，它的核心鏈路肯定有限，例如，我們的核心鏈路就包括：
核心鏈路是乙個業務的核心，這一塊應該可以很快梳理清楚，但是，難點在於梳理清楚鏈路的邊界。例如：
在核心鏈路的基礎上，我們會有很多的分支業務，而這些分支業務有的可以參與壓測，有的不能參與壓測：原因多種多樣，比如，這個分支業務不是我們自己公司的，或者這個分支業務本身就不怎麼重要，可以降級掉，甚至有的業務就是不能壓測，比如給使用者下放push訊息。
在具體實施的時候，業務反覆跟整個鏈路的每個業務owner反覆確認，哪些是核心業務，哪些是分支業務，哪些參與壓測，哪些不參與壓測，把這些形成文件，逐個跟進。
提供全鏈路壓測的底層支援
要做全鏈路，要實現非核心鏈路的降級，就必須對底層的產品，例如中介軟體，資料庫訪問，mq等做改動，讓這些中介軟體支援全鏈路壓測。我們整體看看，一般需要哪些改動。
我們把模型簡化一下，如下圖，雖然是簡化的，但是基本上包括主流的分布式業務的技術棧。
可以看到，底層主要需要提供下面的支援：
影子表：參與壓測的業務，要逐個排查自己依賴的資料庫，然後建立影子表，影子表必須跟正常表的schema保持一致，可以在每次壓測時候手動建立，也可以推動dba自動建立。建立好影子表後，如果當前流量是壓測流量，那麼寫入和讀取都走影子表。如果有自己的資料庫中介軟體最好，沒有的話可以借助於mybatis的interceptor機制。
日誌-影子目錄：為了防止壓測流程的日誌對正常日誌造成干擾，需要改造日誌元件，將壓測流量產生的日誌落入到影子目錄。影子目錄可以有日誌元件自動建立。
mq支援是否消費壓測流量：有的時候，全鏈路會通過mq進行傳遞，所以，必須在消費mq的時候進行選擇：是否選擇消費壓測流量的mq訊息。這就需要對mq系統進行改造，一方面使其可以透傳壓測流量，另一方面，需要支援配置是否消費壓測的mq訊息
快取，大資料隔離：還有一些場景，比如，快取層，大資料層對壓測流量的處理也要考慮隔離。快取可以使用不同的集群；大資料可以直接不收集壓測的資料。
思考全鏈路壓測的資料怎麼mock
流程支援之後，還有關鍵的一步，就是考慮如何構造壓測的mock資料。在使用影子表之後，可以比較輕鬆的實現跟正常資料隔離，那剩下的就是好構造好mock資料，有幾點需要考慮：
做好壓測流量的降級預案
這一點尤其重要，特別當業務特別的複雜的時候，一定要確認好，第三方依賴能不能接收壓測流量，所以，只要依賴第三方的服務，我們都要接入壓測流量降級的開關，防止對第三方服務的汙染。實現上，可以整合到rpc機制上，也可以提供類似於單獨的限流元件。
梳理監控體系
確認好流程的技術支援和mock資料的支援後，還要讓每個業務梳理自己的監控，確保壓測時候能夠準確，及時的發現問題。
線下做好預演
真實的壓測之前，肯定要進行預演，預演主要確認：
盡量模擬現實
我們壓測的腳步要盡可能的模擬現實，比如：
壓測的腳步要跟各個業務確認，盡量跟線上真實的使用者行為保持一致
逐步平滑加壓
壓測的時候，逐步加壓，並且要保持平滑加壓，不要把一秒的流量都在前面幾毫秒內都壓出去。
形成報告
每次壓測後進行復盤，總結壓測中的問題，壓測結果，機器的指標等資料形成報告發給大家，制訂好後續的action以及跟進的負責人。
全鏈路壓測的技術難點不多，除了要花時間梳理流程和思考如何處理資料之外，最難的就是整個鏈路跨多個業務，甚至部門，需要跟進每個業務線的進度，確保大家能夠在給定的時間點進行聯調以及進行壓測。在推進的時候，按照核心鏈路所在的模組進行跟進，每個模組出乙個owner，各個owner跟進核心的介面和依賴，每週大家碰一下同步下總體的進度。
全鏈路壓測
2013年為了雙11提前預演而誕生,該服務已提供在阿里雲pts鉑金版。1.1.1 系統可用性問題 經常由下面一些不確定性因素引起 1.1.2 傳統線上單機與單系統壓測的四種方式 從流量分配的角度，將流量集中到某台機器 這兩種方式要求訪問流量不能太小 1.1.3 單系統壓測的問題單鏈路指乙個業務線。全...
全鏈路壓測
之前有和認識的同行聊過他們全鏈路壓測的一些技術實現方案，自己也看了很多相關的資料，這篇部落格，說說自己對全鏈路壓測的理解，以及整理的一些知識點。阿里全鏈路壓測 有讚全鏈路壓測 京東全鏈路壓測 餓了麼全鏈路壓測 一 什麼是全鏈路壓測 基於實際的生產業務場景 系統環境，模擬海量的使用者請求和資料對整個業...
全鏈路壓測筆記
公司業務發展，難有乙個量化的資料衡量核心鏈路的真實峰值。有助於提公升核心業務的穩定性。找出整個鏈路的瓶頸，優化少量的瓶頸部分提公升整體效能，以期達到用最少的資源達到最佳效果。認識誤區 不能單純認為壓測各個子系統後，整體系統沒有問題，因為涉及到業務訪問鏈路，多個業務可能有共用資源的瓶頸，主鏈路請求量增...