全鏈路壓測方案梳理

全鏈路壓測的概念挺火的，想做成卻沒有機會（畢竟不是網際網路巨頭類的公司），所以在這裡也不想紙上談兵，可能過段時間它就會被更新更高大上的概念給替換了，但是我們可以收集一下相關資料（目前可以開展全鏈路壓測的公司真的很少，所以資料有限），將來對自己的效能測試專案可能也會有幫助：

阿里全鏈路壓測

全鏈路壓測3.0

智慧型全鏈路壓測

有讚全鏈路壓測實戰

全鏈路壓測方案設計與實施詳解

全鏈路壓測引擎的設計與實現

京東全鏈路壓測

餓了麼全鏈路壓測

滴滴全鏈路壓測解決之道

美團全鏈路壓測自動化實踐

全鏈路壓測平台（quake）在美團中的實踐

全鏈路壓測的大概思路

全鏈路壓測平台主要有兩個核心的也是最頂級的要求：

這導致了，必須線上搞壓測，必須用線上的真實資料搞壓測。

那麼線上搞就容易搞出事情，所以技術含量還是要有的，還是很高的。

1、業務模型梳理

首先應該明確的是：全鏈路壓測針對的是現代越來越複雜的業務場景和全鏈路的系統依賴。所以首先應該將核心業務和非核心業務進行拆分，確認流量高峰針對的是哪些業務場景和模組，

針對性的進行擴容準備，而不是為了解決海量流量衝擊而所有的系統服務集群擴容幾十倍，這樣會造成不必要的成本投入。

2、資料模型構建

資料構建和準備，應該考慮這幾點問題：

①、資料的真實性和可用性

可以從線上環境（生產環境）完全移植乙份當量的資料報，作為壓測的基礎資料，然後基於基礎資料，通過分析歷史資料增長趨勢，預估當前可能的資料量；

據說美團的做法是：

然後壓測流量從資料庫池子裡來。

②、資料脫敏

基於生產環境的全鏈路壓測，必須考慮的一點是不能產生髒資料，以免對生產造成影響，影響使用者體驗等，因此在資料準備時需要進行資料脫敏。

③、資料隔離

同樣，為了避免造成髒資料寫入，可以考慮通過壓測資料隔離處理（根據測試標識區分），落入影子庫，mock物件等手段，來防止資料汙染；另外比如http請求，可以直接將測試標識加在header裡（不汙染**，僅測試引擎新增即可），這樣可以把隔離出來的（帶測試標識的）流量，只訪問隔離出來的伺服器，這樣就不會汙染整個線上伺服器集群。

全鏈路壓測基本上和原生jmeter沒關係，因為jmeter用的是bio（基於jmeter的雲平台化，足夠規模的分布式壓測也是可選的乙個方向），美團用的是nio，阿里的pts也用到nio，好處不解釋了。

採用的方式有：

一般會採用 influxdb 來完成資料的聚合工作，所有聚合指標都是一行 sql 搞定，非常快速。或基於開源二次開發的監控，比如cat，falcon，skywalking等。

關於監控這塊，美團的開源精神值得肯定（雖然內部的好東西未必能開源出來），而像餓了麼監控系統 emonitor 說是比cat好，但目前為止也沒見開源，阿里的雲監控更別提了，天天推銷讓你花錢買服務。

至少目前來看，得是有追求，有餘力的公司吧。

阿里，滴滴，餓了麼，雲集微店，美團，這些公司有乙個共性，都是支付場景比較高併發的公司，就是對錢非常敏感的公司。

支付場景，也就是支付相關的各個服務（訂單，派送，入庫出庫等很多），相連密切，這樣的場景比較複雜，還是高併發，自然對效能測試有高要求。

同時支付場景，是會改變庫的資料的，這也要求線上測試必須做資料隔離，這也是全鏈路壓測的核心。

肯定不是測試，也不是一般的效能測試工程師和測試開發工程師，基本上是乙個研發團隊在搞。

據說美團的壓測平台前身也是測試開發工程師搞的，推廣的也不錯，在美團趟出了一條壓測的路，但是存在了不少有待改進的地方。後來種種原因，平台移交給了開發團隊，現在看起來，平台的壓測效能、可用性等各方面有了很大的提公升。不是說測試開發的同學做不了，而是效率和速度確實還是有差距的。開發同學的效率和速度就是特別大的優勢，能加班，可以快速的讓產品成型並且快速迭代。

以上內容部分參考自

全鏈路壓測方案梳理

全鏈路壓測

全鏈路壓測

全鏈路壓測筆記

相關推薦