生產全鏈路壓測實踐之道

前言

每一年的618&雙11，對於電商公司來講都是一次大考。爲了應對活動當天的瞬時峯值流量，進行全鏈路壓測是頗有必要的一項技術工程。

並且全鏈路壓測除了對核心鏈路進行性能問題排查優化以外，還能發現不少平常迭代中累積的小問題，對團隊協同做戰能力，也是一個很好的提高。

 

演進

從去年雙11到今年618，我司的全鏈路壓測體系建設，整體來講經歷了以下三次演進：

時間節點	環境	壓測方式	優勢	缺點
19年雙11	1:1等比環境	Jmeter分佈式壓測	1）徹底生產等比環境 2）不用擔憂形成生產髒寫 3）不用擔憂影響正常生產業務	1）環境成本高昂 2）聯調部署麻煩耗時 2）沒法真實模擬生產環境
核心系統重構	混部環境	Jmeter分佈式壓測 流量標+影子庫+Mock	1）重構服務能夠視爲生產服務 2）部分業務走生產環境(灰度驗證) 3）壓測團隊精力更加專一&謹慎	1）環境複雜，問題排查困難 2）可能會對生產形成髒寫 3）時間緊張，須要作更多取捨
20年618	生產環境	Jmeter分佈式壓測 流量標+影子庫+Mock	1）環境成本幾乎爲0 2）徹底真實環境，請求流轉更真實 3）團隊協同能力快速提高	1）須要更精細的前期梳理 2）只能流量低峯壓測（通宵） 3）沒法作到流量&機器隔離

從上可看出，生產環境全鏈路壓測的優勢仍是不少的，總結下來重點是下面幾點：

1）大幅度節省環境成本；

2）徹底真實請求場景；

3）快速發現存在問題；

4）推進技術建設落地；

5）團隊協同能力提高；

6）故障響應處理提效；

 

準備工做

一、鏈路梳理

1-業務場景

業務場景的梳理，主要目的是識別核心鏈路+場景模型；

2-上下依賴

根據核心鏈路+場景模型的梳理，分析出它們的上下游依賴（強弱依賴、MQ、job）；

3-接口文檔

隨着業務版本迭代，涉及到接口邏輯變動，信息沒法作到及時更新。若是沒法提早進行梳理，在服務聯調過程當中容易出現各類莫名其妙的問題。

4-流量配比

流量配比是個很玄學的問題！

真實的用戶請求走哪些鏈路，各自佔比多少？不一樣的業務場景，平常和週末、大促相比，佔比又是多少？

這些數據都是實時變化的，咱們能作的，只有針對性的評估計算出一個大致範圍，並留有必定冗餘空間。

二、模型梳理

1-壓測範圍

其實壓測範圍和核心鏈路梳理很相似，不過範圍界定更多的是從業務角度來劃分。對電商公司來講，核心的業務永遠是商品、庫存、訂單、支付！

2-壓測模型

壓測模型，以我我的經驗，主要能夠從以下幾個維度去劃分：

1）單機單接口基準（接口級別）

單機單接口的壓測，能夠經過梯度增長請求的方式，觀察接口隨着請求的增長，其性能表現&資源損耗的變化。

2）單機混合鏈路場景（服務級別）

單機混合場景，大多仍是經過梯度增長請求的方式，觀察服務級別的性能表現，重點關注3個指標：

①.安全水位（CPU50%）

②.告警水位（CPU70%）

③.最大水位（CPU≥90%&Load5≥150%）

3）全鏈路壓測場景（生產集羣）

針對生產集羣的全鏈路壓測，須要涉及的壓測模型較多，通常有以下幾種：

①.梯度增長模型：主要爲了探測集羣模式下系統的最大吞吐量（也避免壓垮服務，形成事故）

②.固定併發模型：驗證系統長期處於負載下的穩定性；

③.脈衝併發模型：探測系統的健壯性、驗證限流熔斷等服務保護措施的正確性&可用性；

④.超賣驗證模型：對電商業務來講，主要針對一些限時搶購&秒殺的場景；通常這種場景，會涉及到分佈式鎖、

緩存、數據一致性等技術點；玩很差的話，容易形成客訴、資損、甚至服務異常宕機！

3-流量模型

出於保密原則，流量模型請參考我以前的博客：全鏈路壓測第一次實踐

4-壓測方案

作完前期的準備工做，建議輸出一份壓測方案，核心就一句話：任務拆解，設定里程碑！

三、資源準備

1-ECS預購

通常大促前夕，雲服務資源都會比較緊張，所以須要進行預購。資源預購須要注意以下幾點：

1）保持和生產服務同規格配置，儘量在同一可用區；

2）預購數量能夠根據生產現有服務數量&一輪壓測結果&預期指標進行評估，留有必定備用機器；

2-DB升配

大促期間流量會比較高，所以能夠提早對核心業務DB進行必定規格的升配，後續根據壓測優化結果調整。

3-SLB擴容

目前阿里雲SLB，單個最大支持5W的QPS。爲了知足峯值流量衝擊及預期指標，須要提早對其進行擴容。

四、專項梳理

1-壓測check項

因爲壓測是在生產環境開展，所以在壓測開始前，要針對相關服務的Mock配置、影子庫表、流量標傳遞、測試用戶數據預熱等相關項進行確認排查，確保壓測抱回致使髒寫。

2-定時job統計

因爲部分業務是經過定時job去調度執行的，爲了不壓測時job調度對服務的性能影響，所以須要專門梳理相關的定時job等任務，針對性的進行臨時關閉或者調度策略調整。

3-降級開關梳理

爲了應對活動當天的峯值流量，能夠對一些弱依賴或者非關鍵業務進行降級操做，好比"小紅點"、"SQL校驗"、

"退款到帳時間"、商品推薦等。

PS：建議將相關的降級操做都經過配置或者開發的方式來處理，便於一鍵啓停，下降操做難度。

4-穩定性預案

穩定性預案通常分爲以下幾種：

1）應用級別：如降級、熔斷；

2）系統級別：日誌歸檔、網關防爬、風控；

3）定時任務：常見的定時job如批處理，定時獲取數據；

4）緩存預熱：如商品信息、費率信息；

5）異常處理：針對一些異常狀況，如優惠券不可用、地址信息獲取失敗（18年淘寶）；

 

優化提效

一、壓測方式

目前生產全鏈路採用的是基於jmeter的分佈式壓測，但jmeter自己的分佈式壓測會將壓測數據由slave上報給master，這樣會帶來必定的性能損耗。

針對這點咱們將壓測數據寫入influxDB，而後由grafana進行查詢，作聚合計算並展現。因爲分佈式壓測須要將測試數據同步到對應的壓測機上，

針對這個問題咱們開發了一鍵上傳，壓測一鍵啓停的功能，這樣既提升了併發調整的效率，對於異常場景，也能作到儘快的流量熔斷保護功能。

二、後端優化

1）通信協議升級：服務內部調用由http升級爲dubbo的RPC調用；

2）監控採樣頻次：下降了監控數據採樣率，由100%下降到10%；

3）數據緩存：針對部分非實時強一致性數據，進行了緩存操做；

4）JVM參數：針對JVM啓動參數，設置Xms和Xmx保持一致，減小擴堆動做；

5）線程優化：通過多輪壓測對比，最終評估獲得結果，undertow的work_threads修改成16N；

三、前端優化

CDN、靜態資源、大圖壓縮、資源內置；

 

監控建設

監控體系建設是一個長期的過程，針對大促，咱們主要優化了以下幾點：

1-實時拓撲圖

2-決策系統：核心鏈路監控大盤若干

3-監控大盤：業務域監控大盤

這樣更便於在也測和大促時及時發現和排查問題。

 

其餘專項

1-規格自檢升級：mq、db、redis、slb、es、MongoDB；

2-數據庫巡檢：索引、慢SQL、鏈接數、proxy層check、負載check；

3-架構圖梳理：機房、可用區、業務集羣分佈、slb、網絡升級、slb；

4-安全專項：防爬、防DDoS；

針對大促，運維團隊也對相關的服務資源進行了規格巡檢和升配擴容，保障618大促。