一年以前，有讚準備在雙十一到來之前對系統進行一次效能摸底，以便提前發現並解決系統潛在效能問題，好讓系統在雙十一期間可以從容應對劇增的流量。工欲善其事，必先利其器，我們拿什麼工具來壓測呢？我們做了很多前期調研和論證，最終決定基於 gatling 開發有讚自己的分布式全鏈路壓測引擎 —— maxim。一年多來，我們使用 maxim 對系統做了很多次的效能壓測，在提公升系統效能、穩定性的同時，也得益於歷次壓測的實踐經驗逐步改進 maxim。
由於時間或成本關係，我們打算基於開源軟體做二次開發，而以下就是我們技術選型時的核心考量：
我們調研了以下 4 個主流開源效能測試框架：
以上，我們最終選擇基於 gatling 做二次開發。
maxim 在 gatling 基礎上開發了很多新特性：
maxim 架構的主要構成：
maxim的排程演算法
maxim 控制中心採用六邊形架構（也叫埠與介面卡模式），核心服務只處理核心業務邏輯（如排程演算法），其他功能如與 agent 通訊、指令碼儲存、資料儲存、壓測報告等都是通過適配層呼叫特定實現的 api 實現。具體技術的話，與 agent 通訊使用 grpc 實現，其他功能則是通過 spi 技術實現，我們把這一層叫做接縫層（seam）。這樣設計最大層度的解耦了核心業務邏輯和其他功能的特定實現，我們在保持接縫層 api 不變的情況下，可以自由選擇技術方案實現相應的功能。比如資料服務這塊強依賴了有贊的大資料平台，假設我們開源了 maxim，外部團隊就可以選擇他們自己的技術方案實現資料服務，或者為了測試目的 mock 掉。
原生 gatling 是將壓測日誌寫入本地日誌檔案的，而在分布式中，如果每個壓力注入器都把日誌寫在本地，則為了基於所有日誌分析生成壓測報告，我們需要首先收集分散在各個壓力注入器中的日誌檔案，這樣顯然是低效的。所以我們改造了 gatling ，將所有日誌都寫到同乙個 influxdb 資料庫。需要生成壓測報告時，控制中心從 influxdb 資料庫讀入本次壓測任務的所有壓測日誌並儲存為乙個日誌檔案，再交由 gatling 的日誌處理模組來生成壓測報告。
原生 gatling 不支援 dubbo 壓測，所以我們擴充套件 gatling，實現並開源了 gatling-dubbo壓測外掛程式，具體實現方法詳見 dubbo壓測外掛程式的實現——基於gatling
maxim 目前還是個單打獨鬥的產品，未來我們希望與大資料平台、運維平台等系統打通，讓 maxim 逐漸進化為乙個一站式的壓測平台，並引入更多新特性，如壓測過程和壓測報告的實時計算和展示等等。
我的系列部落格
混沌工程 - 軟體系統高可用、彈性化的必由之路
非同步系統的兩種測試方法
dubbo壓測外掛程式的實現——基於gatling
我的其他測試相關開源專案
捉蟲記：方便產品、開發、測試三方協同自測的管理工具
gatling-dubbo：擴充套件自gatling的dubbo效能測試外掛程式
招聘
有讚測試組在持續招人中，大量崗位空缺，只要你來，就能幫你點亮全棧開發技能樹，有意向換工作的同學可以發簡歷到 sunjun【@】youzan.com
有讚全鏈路壓測實戰
有讚致力於成為商家服務領域裡最被信任的引領者，因為被信任，所有我們更需要為商家保駕護航，保障系統的穩定性。有讚從去年開始通過全鏈路壓測，模擬大促真實流量，串聯線上全部系統，讓核心系統同時達到流量峰值 通過全鏈路壓測這一手段，對線上系統進行最真實的大促演練，獲取系統在大壓力時的表現情況，進而準確評估線...
全鏈路壓測
2013年為了雙11提前預演而誕生,該服務已提供在阿里雲pts鉑金版。1.1.1 系統可用性問題 經常由下面一些不確定性因素引起 1.1.2 傳統線上單機與單系統壓測的四種方式 從流量分配的角度，將流量集中到某台機器 這兩種方式要求訪問流量不能太小 1.1.3 單系統壓測的問題單鏈路指乙個業務線。全...
全鏈路壓測
之前有和認識的同行聊過他們全鏈路壓測的一些技術實現方案，自己也看了很多相關的資料，這篇部落格，說說自己對全鏈路壓測的理解，以及整理的一些知識點。阿里全鏈路壓測 有讚全鏈路壓測 京東全鏈路壓測 餓了麼全鏈路壓測 一 什麼是全鏈路壓測 基於實際的生產業務場景 系統環境，模擬海量的使用者請求和資料對整個業...