有讚致力於成為商家服務領域裡最被信任的引領者，因為被信任，所有我們更需要為商家保駕護航，保障系統的穩定性。有讚從去年開始通過全鏈路壓測，模擬大促真實流量，串聯線上全部系統，讓核心系統同時達到流量峰值：
通過全鏈路壓測這一手段，對線上系統進行最真實的大促演練，獲取系統在大壓力時的表現情況，進而準確評估線上整個系統集群的效能和容量水平，不辜負百萬商家的信任。
有讚對於效能測試主要有線下單系統單介面、線上單系統以及線上全鏈路壓測等手段，通過不同維度和顆粒度對介面、系統、集群層面進行效能測試，最終保障系統的穩定性。這裡主要講述一下，有讚全鏈路壓測的相關設計和具體的實施。
說到全鏈路壓測，業內的**、京東都都已有很成熟的技術，主要就是壓測流量的製造、壓測資料的構造、壓測流量的識別以及壓測資料流向的處理；直接看下有贊壓測的整體設計：
壓測平台負責管理壓測指令碼和壓測請求資料，從資料工廠獲取壓測資料集，分發到每乙個壓測 agent 機器上，agent 根據壓測指令碼和壓力目標對線上機器發起請求流量，模擬使用者的檢視商品-新增購物車-下單-支付等行為，線上服務集群識別出壓測的流量，對於儲存的讀寫走影子儲存。這裡就要說到，線上壓測很重要的一點就是不能汙染線上的資料，不能讓買賣家有感知，比如壓測後，賣家發現多了好多訂單，買家發現錢少了。所以，線上服務需要能夠隔離出壓測的流量，儲存也需要識別出壓測的資料，下面看一下有讚的壓測流量和壓測資料儲存的隔離方案。
要想壓測的流量和資料不影響線上真實的生產資料，就需要線上的集群能識別出壓測的流量，只要能識別出壓測請求的流量，那麼流量觸發的讀寫操作就很好統一去做隔離了，先看一下有讚壓測流量的識別：
全鏈路壓測發起的都是http的請求，只需要要請求頭上新增統一的壓測請求頭，具體表現形式為: header name:x-service-chain; header value:
dubbo協議的服務呼叫，通過隱式引數在服務消費方和提供方進行引數的隱式傳遞，表現形式為： attachments:x-service-chain; attachments value:
通過在請求協議中新增壓測請求的標識，在不同服務的相互呼叫時，一路透傳下去，這樣每乙個服務都能識別出壓測的請求流量，這樣做的好處是與業務完全的解耦，只需要應用框架進行感知，對業務方**無侵入
非同步呼叫標識透傳問題，可以自行定製 runnable 或者定製執行緒池再或者業務方自行定製實現。
通過流量識別的改造，各個服務都已經能夠識別出壓測的請求流量了，那麼如何做到壓測資料不汙染線上資料，對於不同的儲存做到壓測資料和真實的隔離呢，有讚主要有客戶端 client 和 proxy 訪問**的方式實現，下面就看一下有讚的資料隔離方案：
針對業務方和資料儲存服務間已有proxy**的情況，可以直接公升級 proxy 層，儲存使用方完全無感知，無侵入，下面以 mysql 為例，說明 proxy 訪問**對於壓測資料隔離的方案；
業務方應用讀寫db時，統一與 rds-proxy (介於 mysql 伺服器與 mysqlclient 之間的中介軟體)互動，呼叫 rds-proxy 時會透傳壓測的標記，rds 識別出壓測請求後，讀寫 db 表時，自動替換成對應的影子表，達到壓測資料和真實的生產資料隔離的目的
elasticsearch、kv 對於壓測的支援也是通過 proxy 訪問**的方式實現的
業務應用通過client呼叫儲存服務時，client 會識別出壓測的流量，將需要讀寫的 table 自動替換為影子表，這樣就可以達到影子流量，讀寫到影子儲存的目的；
hbase、redis 等採用此方案實現
推動框架、中介軟體公升級、業務方改造，難免會有遺漏之處，所以有讚對於壓測的資料統一做了偏移，確保買賣家 id 與線上已有資料隔離開，這樣即使壓測資料由於某種原因寫入了真實的生產庫，也不會影響到線上買賣家相關的資料，讓使用者無感知；
這裡要說一下特殊的週期掃表應用的改造，週期性掃表應用由於沒有外部觸發，所有無法掃瞄影子表的資料，如何讓這樣的 job 集群整體來看既掃瞄生產庫，也掃瞄影子庫呢？ 有讚的解決思路是，部署一些新的 job 例項，它們只掃瞄影子庫，訊息處理邏輯不變；老的 job 例項保持不變（只掃生產庫）
有讚的全鏈路壓測平台目前主要負責壓測指令碼管理、壓測資料集管理、壓測 job 管理和排程等，後續會有重點介紹，這裡不做深入
壓測的「硬體」設施基本已經齊全，下面介紹一下有讚全鏈路壓測的具體實施流程吧
廢話不多說，直接上圖：
有讚全鏈路壓測的執行流程如上圖所示，下面具體看一下幾個核心步驟在有讚是怎麼做的。
要想模擬大促時線上真實的流量情況，首先需要確認的就是壓測場景、鏈路，壓測的目錄，以及壓測的流量漏斗模型：
前面我們已經介紹了如何確定壓測的目標、場景、鏈路，那麼壓測的資料怎麼來尼，這就是資料工廠登場的時候了，下面就介紹一下有讚壓測的資料工廠
有讚的壓測資料工廠主要負責，壓測鋪底資料的準備、壓測請求資料塊的生成；
壓測準備鋪底的資料，這個眾所周知的，但是由於有讚壓測的方案採用的是影子庫的設計，所以對於鋪底資料準備不得不去處理影子庫的資料。直接看下鋪底資料準備的流程圖：
有讚的壓測資料準備目前全部在 dp 大資料平台上操作，基本完成了資料準備操作的自動化，維護了近千的資料準備 job
壓測請求資料資料集
gatling 原生支援 json、csv、db 等方式的資料來源載入，我們採用的壓測資料源是 json 格式的，那麼如此海量的壓測源資料，是通過什麼方式生成和儲存的尼，我們的實現還是依託於 dp 大資料平台，通過 mapreduce 任務的方式，按需生成我們壓測請求需要的資料集：
mapreduce 生成的資料集 json 示例：
壓測就要知道壓測的具體介面和介面引數，所以我們採用統一的 restful 風格規範，讓各個業務方的人員提交壓測介面的 api 文件，這樣壓測指令碼編寫人員就能根據這份 api 快速寫出壓測的指令碼，以及介面的預期結果等
有讚的壓測引擎用的是公司二次封裝的 gatling，原生就支援漏斗比例的控制，直接看例子
)複製**對不同的壓測場景鏈路按模組編寫壓測指令碼，這樣的好處就是需要不同場景混合壓測時，只需要在 setup 時，按需把不同的場景組合到一起即可；需要單獨壓測某乙個場景時，setup 中只留乙個場景就好，做到一次編寫，處處可壓。
壓測的鋪底資料、壓測指令碼、壓測請求的資料集都已經介紹完了，可謂是萬事俱備只欠東風，那這個東風就是我們自建的壓測平台 maxim，這裡不對壓測平台的設計展開介紹，展示一下 maxim 在壓測執行過程中所承擔的工作。
maxim平台主要的功能模組有：
maxim 平台壓測結果報告
下面看一下壓測執行的頁面功能：
全鏈路壓測
2013年為了雙11提前預演而誕生,該服務已提供在阿里雲pts鉑金版。1.1.1 系統可用性問題 經常由下面一些不確定性因素引起 1.1.2 傳統線上單機與單系統壓測的四種方式 從流量分配的角度，將流量集中到某台機器 這兩種方式要求訪問流量不能太小 1.1.3 單系統壓測的問題單鏈路指乙個業務線。全...
全鏈路壓測
之前有和認識的同行聊過他們全鏈路壓測的一些技術實現方案，自己也看了很多相關的資料，這篇部落格，說說自己對全鏈路壓測的理解，以及整理的一些知識點。阿里全鏈路壓測 有讚全鏈路壓測 京東全鏈路壓測 餓了麼全鏈路壓測 一 什麼是全鏈路壓測 基於實際的生產業務場景 系統環境，模擬海量的使用者請求和資料對整個業...
有讚全鏈路壓測引擎的設計與實現
一年以前，有讚準備在雙十一到來之前對系統進行一次效能摸底，以便提前發現並解決系統潛在效能問題，好讓系統在雙十一期間可以從容應對劇增的流量。工欲善其事，必先利其器，我們拿什麼工具來壓測呢？我們做了很多前期調研和論證，最終決定基於 gatling 開發有讚自己的分布式全鏈路壓測引擎 maxim。一年多來...