前言

之前自己也寫過好幾篇關於全鏈路壓測的文章或者部落格，最近看了infoQ上infoQ-數列科技楊德華的專欄，覆盤了下自己以往在全鏈路壓測實施方面的工作，發覺還有很多可以做的更好的地方。

就以這篇文章來做個總結，順帶說說我自己實施全鏈路壓測工作方面的一些收穫和經驗。

18年初：聊聊全鏈路壓測

19年初：再談全鏈路壓測

20年初：全鏈路壓測探索實踐之路

19年雙十一備戰：全鏈路壓測第一次實踐

20年618大促總結：生產全鏈路壓測實踐之道

20年雙11大促總結：全鏈路壓測落地和演進之路

觀點

很多同學問過我關於全鏈路壓測如何實施落地，如何在生產環境實現的技術問題。

這裡我想借用上面infoQ專欄大佬的一句話：生產全鏈路壓測，表面是一個技術工程，實際上是一個很有難度的組織協調專案。

下面我會從幾個方面來談談我個人現在對於全鏈路壓測的一些思考和經驗總結。

技術

很多同學說起全鏈路壓測，都喜歡深究它的技術細節，這沒錯。

但全鏈路壓測想要成功的在生產環境實施，更多的是考驗組織協調能力的一個專案。至於技術層面，能說的有很多，這次我們先聊聊比較核心的一些技術點。

隔離方案

流量隔離

既然我們的前提是在生產環境進行壓測，那麼無論是趁著業務流量低峰期，還是生產全鏈路壓測常態化，對於壓測流量的隔離區分，是一定要首先解決的。如下圖所示：

目前業內比較常見的方案，有如下兩種：

1）中介軟體改造+流量標透傳（業務侵入較多）；

2）agent+位元組碼增強技術（業務侵入較低）；

這兩種方案的選型，需要基於研發團隊的整體技術棧以及業務迭代情況等因素綜合考慮。

比如我司，採用的是第一種方案：基礎架構團隊基於spring cloud全家桶二次開發了一套全鏈路壓測框架的腳手架，由業務研發團隊接入。

資源隔離

資源隔離主要指的伺服器、Redis、MQ、DB等資源。一般來講大部分企業的業務都是白天流量較高，凌晨是流量低谷。

在流量低谷期，直接壓測生產的服務，風險相對較小且可控。

如果生產服務穩定性較好，且能做到按比例資源隔離以及壓測流量識別透傳，那麼第二種方案反而可以考慮。

且如果要採用資源隔離方案，那麼核心鏈路梳理和區分工作是必須要做的。

區分核心和非核心業務，核心業務分級（P0/P1/P2），由小及大的不斷覆蓋。

資料隔離

壓測會產生大量的資料，這些資料如何處理是DBA團隊面臨的最大挑戰。

目前來說，業內比較通用的方式都是採用影子庫表或者壓測資料帶特殊標識進入生產業務庫表，以tag或者特殊欄位做區分。他們的區別如下：

1）影子庫+影子表：一般生產庫和影子庫都是在同一個DB例項上，基礎資料會脫敏後同步過去；

2）生產業務表標識：在生產業務表中新增壓測標識欄位，壓測資料需要定時清理（餓了麼採用這套方案）；

我司採用的方案如下：

DB路由：①.同instance不同schema（風險大）；②.不同instance同schema（安全性高，成本高）；

Redis路由：①.key值加統一字首；②.Redis-client做路由；

MQ路由：採用影子topic模式，帶壓測標識的資料進入影子topic；

ES路由：①.index統一加字首，提供統一ES client做資料訪問，由client做路由；

日誌隔離

壓測會產生大量日誌，為了便於正常的業務問題跟進排查和壓測區分，個人建議還是對帶壓測標的日誌進行字首處理，這樣運維同學也可以快速的清理，以免磁碟寫滿導致生產故障。

改造工作

監控平臺

監控系統需要透明化，且壓測監控大盤和業務監控大盤需要單獨配置。其中有如下的點需要注意：

1）設定告警閾值、告警降噪、專項業務告警；

2）專項告警，需要覆蓋核心介面、監控大盤、業務大盤；

3）優點：問題快速定位，避免不透明影響問題的發現和修復速率；

4）容量規劃：藉助監控平臺的賦能，快速梳理清楚系統架構、拓撲關係，才便於做容量規劃；

流控平臺

流量發起和服務保護功能是全鏈路壓測成功開展的必要前提。服務保護方面，業內常用的元件有Sentinel、Hystrix，他們一般都是基於執行緒池/訊號量來進行流控。

預案平臺

常說大促時候，服務穩定性有三大利器：限流、熔斷和降級。前面介紹了流控（限流和熔斷），那麼降級是什麼呢？按照我個人的經驗，降級預案一般分為主動降級和緊急降級。

主動降級：商品首頁快取&資料兜底、小紅點、客戶端限流浮層、重試機制等；

緊急降級：收貨地址、浮動費率、運費計算、運營位固定等方案；

當然，無論是主動降級方案還是緊急降級方案，都是需要進行業務梳理和細化拆分的，還要和產品運營等團隊的同學提前溝通好，避免跨團隊溝通的Gap產生。

還有些前置事項，比如業務拆分（訂單拆分為正逆向），比如不同業務服務叢集隔離，比如DB垂直拆分、讀寫分離、分庫分表等方案，這些都是需要考慮的。

至於異地多活、故障演練、災備演練，這些更需要成熟的技術體系建設和多方達成一致，才能更好的保障生產服務的穩定性。總的來說，全鏈路壓測除了技術，更多的還需要溝通與協調。

壓測實施

到了壓測實施階段，基本就只能硬著頭皮硬上了，特別是第一次搞生產全鏈路壓測，至今記憶深刻。生產全鏈路壓測，需要注意以下幾點：

服務擴容

需要注意的是，在生產開始壓測前，系統需要進行前置擴容，避免資源不足導致整體容量瓶頸。還需要注意的是，在大促峰值流量來臨時，儘可能不要去執行擴容操作。

壓測方式

至於壓測執行方式，業內能玩的基本就是這幾種方式。當然，壓測前的預熱，是必不可少的。壓測執行方式方面，主要有如下幾項：

1）階梯遞增：這種方式的目的在於不斷遞增流量，找到系統的效能拐點；

2）峰值脈衝：有些特殊場景，需要區分流量是逐漸變大，還是驟升後保持高峰；

3）系統摸高：關閉熔斷降級限流等fallback功能，提高壓測流量觀察系統性能轉折點；

4）預案驗證：開啟熔斷限流等fallback功能，功能是否生效，系統是否能扛得住；

5）破壞性測試：主要為了驗證預案的有效性，類似於容災演練時的預案執行演練，驗證後手搶救方案。

注意：執行第4/5項時，建議進行生產業務的功能正確性驗證！

預案評審

在預案評審和演練階段，進行預案演練的目的主要有如下幾項：

1）驗證預案是否生效；

2）針對預案設定閾值進行測試調優；

3）驗證預案生效時服務本身的效能表現；

4）針對上述專項場景進行實戰演練；

建議：按照我個人的實施經驗，建議輸出對應的全鏈路壓測SOP&大促作戰SOP。

管理

前面關於全鏈路壓測的觀點，已經提到了：生產全鏈路壓測，表面是一個技術工程，實際上是一個很有難度的組織協調專案。

從管理的角度出發，下面三項是管理者或者專案推動者應該高度重視的。

目標

大家應該都瞭解SMART體系，在考慮實施全鏈路壓測時候，下面幾點SMART目標，也是需要重點考慮的。

目標與標準：SMART5大元素

1）目標必須是具體的（Specific）——業務指標、技術指標、容量指標等；

2）目標必須是可以衡量的（Measurable）——從不同的維度和資料來評估；

3）目標必須是可以達到的（Attainable）——不要設定過高的脫離現實的目標；

4）目標必須和其他目標具在相關性（Relevant）——對業務以及技術團隊有什麼價值；

5）目標必須說明明確的截止期限（Time-based）——根據日期和任務資源倒排期，保障專案成功；

流程

總結一下，生產全鏈路壓測這個技術專案，可以用三個維度和五個階段來概括。

五個階段：準備階段、執行階段、故障修復、專案覆盤、專案結項；

三個維度：做什麼、風險如何處理、事項review（保持資訊同步）。

組織

日常工作中，我們一般有版本迭代的常規需求以及一些特殊的獨立專案。非業務或者弱業務的事情，可以通過虛擬的組織架構來明確定義不同崗位的職責，避免混亂。

一般來說，生產全鏈路壓測中，虛擬的組織架構一般有如下幾種角色：

Sponsor：發起&組織人；

PMO：專案管理、專案經理；

Principal：（主）負責人；

Owner：業務&技術某一領域負責人（領頭人）；

價值

最開始我司推動實施全鏈路壓測時，我畫了下面這張圖，用來體現全鏈路壓測的價值：

從我個人角度來說，全鏈路壓測的最大價值在於：

1）成本：降低環境成本，人力成本（不斷實踐，投入的人力越來越少）；

2）問題：提前發現大流量下系統潛在的隱患，提升系統穩定性；

3）容量：提升效能，識別短板，機器配比有了明確的數值，避免不必要的冗餘；

4）限流：倒逼各個服務&系統進行限流降級等服務穩定性保障措施，預案驗證演練；

5）ROI：降低溝通成本，團隊練兵協調組織能力提升，形成自己的一些技術規範和手冊；

&n