關于全鏈路壓測的幾個問題

1 什么是全鏈路壓測?

基于實際的生產業務場景、系統環境，模擬海量的用戶請求和數據對整個業務鏈進行壓力測試，并持續調優的過程

2 全鏈路壓測解決什么問題?

驗證峰值流量下服務的穩定性和伸縮性

驗證新上線功能的穩定性

進行降級、報警等故障演練

對線上服務進行更準確的容量評估

機房故障，流量突增的支撐能力評估

3 什么時機下需要?

業務發展速度（業務的不斷發展，依賴的模塊不斷增多。需要找出短板來進行解決）

在可以預期的一段時間（最好是半年，一個季度有點晚）內，業務會有較快速的發展，線上機器必須要大幅度擴容

擴容有的時候并不是線性的，從兩臺擴展到四臺，你得服務能力或者能提高兩倍

繼續擴容服務能力就有可能提高不上去了，因為要受限于其他的模塊，比如 DB、公共組建、中間件等

對單機壓測結果越來越沒有自信

3.1 一個很好的指標，一般而言，我們都會壓一下我們自己的模塊

3.2 單機的壓測不代表真實的線上場景，內心會越來越虛，這個時候，就要考慮全鏈路了

4 壓力測試方式分為幾個階段？

對線上的單機或集群發起服務調用

將線上流量進行錄制，然后在單臺機器上進行回放

通過修改權重的方式進行引流壓測

全鏈路壓測（難點在于梳理清楚鏈路的邊界）

全鏈路壓測針對的是現代越來越復雜的業務場景和全鏈路的系統依賴。所以首先應該將核心業務和非核心業務進行拆分，確認流量高峰針對的是哪些業務場景和模塊，針對性的進行擴容準備，而不是為了解決海量流量沖擊而所有的系統服務集群擴容幾十倍，這樣會造成不必要的成本投入。

5 全鏈路壓測核心功能有哪些？

數據構造

壓測隔離

服務隔離

數據隔離

6 壓測需要做哪些工作？

數據模型構建

壓測平臺搭建

6.1 壓測機中的機器數據能夠實時的收集查看到、可以隨時停止壓測、一定時間內實時錯誤率達到閾值自動熔斷

系統代碼改造（壓測標記，mock，業務邏輯）

6.2 寫請求寫到影子區域(比如header頭中做標記，存儲、緩存、消息、日志等一系列的狀態數據)、依賴的外部服務做 mock 處理(短信、郵件、push 等等)，多線程改造

真實流量蓄水池，分批釋放（回放業務高峰期產生的流量）

逐步壓測

7 為什么需要容量規劃？

什么時候增減機器、保障系統穩定性、節約成本

8 壓測關注哪些指標？

應用層面

服務器資源

基礎服務：中間件和數據庫

核心指標：（響應時間不要用平均響應時間，關注95線；吞吐量和響應時間掛鉤；吞吐量和成功率掛鉤）

系統：

系統容量

業務性能

基礎設施瓶頸

中間件瓶頸

系統直接的依賴影響

9 如何獲取單臺機器的服務能力

模擬請求 通過對生產環境的一臺機器發起模擬請求調用來達到壓力測試的目的

請求轉發 將分布式環境中多臺機器的請求轉發到一臺機器

調整負載均衡 修改負載均衡設備的權重，讓壓測的機器分配更多的請求

  9.1 在進行壓測的同時，實時探測壓測機器的系統負載，一旦系統負載達到預設的閾值即立刻停止壓測，同時輸出一份壓測報告 通過單機壓測獲取的單機服務能力值也是容量規劃一個非常重要的參考依據

最小機器數 ＝ 預估的業務訪問量 ／ 單機能力

  9.2 在做單個系統的容量規劃時，所有的依賴環節能力是無限的，進而使得我們獲取的單機能力值是偏樂觀的；

  9.3 采用單系統規劃時，無法保證所有系統均一步到位，大多數精力都集中核心少數核心系統；

  9.4 部分問題只有在真正大流量下才會暴露，比如網絡帶寬等等。

全鏈路壓測改造關注點：https://www.codercto.com/a/55270.html

美團quake壓測：https://tech.meituan.com/2018/09/27/quake-introduction.html

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

阿里全鏈路壓測

有贊全鏈路壓測

京東全鏈路壓測

餓了么全鏈路壓測

滴滴全鏈路壓測解決之道

邏輯思維在全鏈路壓測方面的實踐