全鏈路壓測

1 阿里分享

2013年爲了雙11提早預演而誕生,該服務已提供在阿里雲PTS鉑金版。

• 系統穩定性保障核武器——全鏈路壓測
• 雙11核武器——全鏈路壓測詳解

1.1 可用性及單機壓測問題

1.1.1 系統可用性問題

常常由下面一些不肯定性因素引發：

• 系統容量
• 業務性能
• 基礎設施瓶頸
• 中間件瓶頸
• 系統直接的依賴影響

1.1.2 傳統線上單機與單系統壓測的四種方式

• 模擬調用者壓測生產環境：讀請求+寫請求（須要特定處理）
• 流量錄製和回放：快速率回放對單機壓測

從流量分配的角度，將流量集中到某臺機器（這兩種方式要求訪問流量不能過小）：

• 請求流量轉發
• 改變負載均衡的權重

1.1.3 單系統壓測的問題

• 在作單個系統的容量規劃時，全部的依賴環節能力是無限的，進而使得咱們獲取的單機能力值是偏樂觀的；
• 採用單系統規劃時，沒法保證全部系統均一步到位，大多數精力都集中核心少數核心系統；
• 部分問題只有在真正大流量下才會暴露，好比網絡帶寬等等。

1.2 全鏈路壓測組成

單鏈路指一個業務線。

全鏈路壓測是一個模擬線上環境的完整閉環，由5大核心要素組成：

1. 壓測環境：對應用戶真實的線上環境，具有數據與流量隔離能力的生產環境； 原則：可以用中間件解決的問題，毫不對業務系統進行改造，系統所需作的是升級中間件，這一原則極大提升了工做效率。
2. 壓測基礎數據：構造知足高峯場景的核心基礎相關數據，影子庫裏構造相同量級的數據； 真實線上數據篩選脫敏。
3. 壓測流量（模型、數據）：成百上千的接口組合，到複雜的接口之間的參數傳遞，複雜的條件判斷來構造精準的全局流量模型，和真實業務狀況保持一致；
   > 壓測引擎的三層結構：
   • 協議支持
   • 請求發送：CGroup資源隔離，異步Reactor模型發送請求，鏈路間線程池隔離
   • 集羣協做： Master，Slave長鏈接； Cristian算法同步網絡延遲，Slave動做一致；
4. 流量發起：模擬全國各地真實的用戶請求訪問，探測站點能力；
5. 問題定位：多維度的監控和報表，服務端可經過其餘生態產品協助定位。

翻譯構造能力的體現：便捷的構造全局業務場景和流量數據的能力。

原子因素：鏈路（被壓測的最小單位） 指令： 思考時間、集合點、條件跳轉、cookie存取、全局準備、併發用戶限制等

原子因素->串行鏈路->場景

1.3 超限後的流量控制

• 丟棄請求
• 對下游降級
• 黑白名單
• 請求排隊

1.4 流量平臺數據量

• T級別的壓測請求數據
• 每秒1600W+次請求壓測能力
• 維持1億+的無線長鏈接和登錄用戶
• 秒級的智能數據調度和引擎調度能力

2 京東分享

ForgeBot， 2016年開發

京東全鏈路壓測軍演系統(ForceBot)架構解密

最先基於開源的NGrinder，能勝任單業務壓測。Controller功能耦合重，支持的Agent數量有限。 以後開發了ForgeBot。

2.1 主要功能模塊

• Controller：任務分配
• Task Service：負載任務下發，支持橫向擴展。提供任務交互和註冊服務。（gRPC:HTTP2+protobuf3）
• Agent：註冊心跳，拉取任務、更新任務狀態、 執行和中止worker process（採用Docker容器部署）
• Monitor Service:接受並轉發壓測數據給JMQ
• DataFlow:對壓測數據作流式計算(輸出TPS,TP999,TP99,TP90,TP50,MAX,MIN)，將計算結果存到DB(ES)

在管理端建立測試場景，Controller掃描發現場景，尋找空閒Agent資源。

任務分配時，Controller計算每一個間隔的執行時間點和遞增的虛擬用戶數，由Agent動態加壓減壓。

在多個組件使用了gRPC框架通信

分讀壓測和寫壓測

2.2 一些解決問題的思路

問題：如何模擬在某一個瞬間壓力達到峯值？
解決方案：經過集合點功能實現，提早開啓峯值所需足夠數量的線程，經過計算肯定各個時間點上不須要執行任務的線程數量，經過條件鎖讓這些線程阻塞。當壓力須要急劇變化時，咱們從這些阻塞的線程中喚醒足夠數量的線程，使更多的線程在短期進入對目標服務壓測的任務。

問題：爲了計算總體的 TPS，須要每一個Agent把每次調用的性能數據上報，會產生大量的數據，若是進行有效的傳輸？
解決方案：對每秒的性能數據進行了必要的合併，組提交到監控服務

3 餓了麼分享

餓了麼全鏈路壓測平臺的實現與原理

3.1 業務模型的梳理

• 是否關鍵路徑
• 業務的調用關係
• 業務的提供的接口列表
• 接口類型(http、thrift、soa等)
• 讀接口仍是寫接口？
• 各接口之間的比例關係

3.2 數據模型的構建

3.2.1 寫請求

壓測方法：

• 用戶、商戶、菜品等在數量上與線上等比例縮放；
• 對壓測流量進行特殊標記；
• 根據壓測標記對支付，短信等環節進行mock；

• 根據壓測標記進行數據清理；

  讀請求

  壓測方法：拉取線上日誌，根據真實接口比例關係進行回放

3.2.2 無日誌服務

壓測方法：

• 構建壓測數據使緩存命中率爲0%時，服務接口性能，數據庫性能；
• 緩存命中率爲100%時，服務接口性能；
• 緩存命中率達到業務預估值時，服務接口性能；

3.3 壓測工具

定製JMeter

3.4 壓測指標監控和收集

• 應用層面
• 服務器資源
• 基礎服務：中間件和數據庫

要點：

• 響應時間不要用平均響應時間，關注95線；
• 吞吐量和響應時間掛鉤
• 吞吐量和成功率掛鉤

3.5 具體實現

SpringBoot+AngularJS.

測試期間產生的冷數據(用例數據、結果數據)持久化至MongoDB，熱數據(實時數據)持久化至InfluxDB並按期清理。

分佈式測試：從新實現JMeter的分佈式調度
測試狀態流轉：各類流程造成閉環，要考慮各類異常。
主要流程：配置 -> 觸發 -> 運行 -> 結果收集 -> 清理。

整個狀態流轉的實現，採用異步Job機制實現了相似狀態機的概念，狀態屬性持久化到數據庫中，便於恢復。

3.6 安全保障

因爲是在線上真實環境，須要避免測試引發的服務不可用和事故。

• 權限管理：用戶權限分級管理，不能隨意觸發他人的測試用例，同時高峯期和禁止發佈期，不容許執行任何測試。
• 中止功能：這是面向用戶的手動中止功能，用戶能夠隨時點擊運行狀態下的測試用例上的中止按鈕，後臺會直接kill掉全部運行該測試用例的測試機上的JMeter進程。
• 熔斷功能：系統會根據實時信息中的錯誤率進行判斷，當必定時間內的實時錯誤率達到或超過某個閾值時，該次測試將被自動熔斷，無需用戶干預。
• 兜底腳本：最極端的狀況，當整個系統不可用，而此時須要中止測試時，咱們提供了一份外部腳本直接進行中止。