2023年為了雙11提前預演而誕生,該服務已提供在阿里雲pts鉑金版。
1.1.1 系統可用性問題
經常由下面一些不確定性因素引起：
1.1.2 傳統線上單機與單系統壓測的四種方式
從流量分配的角度，將流量集中到某台機器（這兩種方式要求訪問流量不能太小）：
1.1.3 單系統壓測的問題單鏈路指乙個業務線。
全鏈路壓測是乙個模擬線上環境的完整閉環，由5大核心要素組成：
壓測環境：對應使用者真實的線上環境，具備資料與流量隔離能力的生產環境； 原則：能夠用中介軟體解決的問題，絕不對業務系統進行改造，系統所需做的是公升級中介軟體，這一原則極大提高了工作效率。
壓測流量（模型、資料）：成百上千的介面組合，到複雜的介面之間的引數傳遞，複雜的條件判斷來構造精準的全域性流量模型，和真實業務情況保持一致；
> 壓測引擎的三層結構：
流量發起：模擬全國各地真實的使用者請求訪問，探測站點能力；
問題定位：多維度的監控和報表，服務端可通過其他生態產品協助定位。
翻譯構造能力的體現：便捷的構造全域性業務場景和流量資料的能力。
原子因素：鏈路（被壓測的最小單位） 指令： 思考時間、集合點、條件跳轉、cookie訪問、全域性準備、併發使用者限制等
原子因素->序列鏈路->場景
forgebot， 2023年開發
京東全鏈路壓測軍演系統(forcebot)架構解密
最早基於開源的ngrinder，能勝任單業務壓測。controller功能耦合重，支援的agent數量有限。 之後開發了forgebot。
在管理端建立測試場景，controller掃瞄發現場景，尋找空閒agent資源。
任務分配時，controller計算每個間隔的執行時間點和遞增的虛擬使用者數，由agent動態加壓減壓。
在多個元件使用了grpc框架通訊
分讀壓測和寫壓測
問題：如何模擬在某乙個瞬間壓力達到峰值？
解決方案：通過集合點功能實現，提前開啟峰值所需足夠數量的執行緒，通過計算確定各個時間點上不需要執行任務的執行緒數量，通過條件鎖讓這些執行緒阻塞。當壓力需要急劇變化時，我們從這些阻塞的執行緒中喚醒足夠數量的執行緒，使更多的執行緒在短時間進入對目標服務壓測的任務。
問題：為了計算整體的 tps，需要每個agent把每次呼叫的效能資料上報，會產生大量的資料，如果進行有效的傳輸？
解決方案：對每秒的效能資料進行了必要的合併，組提交到監控服務
餓了麼全鏈路壓測平台的實現與原理
3.2.1 寫請求
壓測方法：
3.2.2 無日誌服務
壓測方法：
定製jmeter
要點：springboot+angularjs.
測試期間產生的冷資料(用例資料、結果資料)持久化至mongodb，熱資料(實時資料)持久化至influxdb並定期清理。
分布式測試：重新實現jmeter的分布式排程
測試狀態流**各種流程形成閉環，要考慮各種異常。
主要流程：配置 -> 觸發 -> 執行 -> 結果收集 -> 清理。
整個狀態流轉的實現，採用非同步job機制實現了類似狀態機的概念，狀態屬性持久化到資料庫中，便於恢復。
全鏈路壓測
之前有和認識的同行聊過他們全鏈路壓測的一些技術實現方案，自己也看了很多相關的資料，這篇部落格，說說自己對全鏈路壓測的理解，以及整理的一些知識點。阿里全鏈路壓測 有讚全鏈路壓測 京東全鏈路壓測 餓了麼全鏈路壓測 一 什麼是全鏈路壓測 基於實際的生產業務場景 系統環境，模擬海量的使用者請求和資料對整個業...
全鏈路壓測筆記
公司業務發展，難有乙個量化的資料衡量核心鏈路的真實峰值。有助於提公升核心業務的穩定性。找出整個鏈路的瓶頸，優化少量的瓶頸部分提公升整體效能，以期達到用最少的資源達到最佳效果。認識誤區 不能單純認為壓測各個子系統後，整體系統沒有問題，因為涉及到業務訪問鏈路，多個業務可能有共用資源的瓶頸，主鏈路請求量增...
再談全鏈路壓測
之前的部落格，有對業內比較出名的幾家網際網路大廠的全鏈路壓測方案進行過整理和總結，傳送門 聊聊全鏈路壓測。時隔一年多，由於效能測試及相關知識的學習實踐，對其有了新的認識，這裡，再次聊聊我對全鏈路測試的理解。目前的現狀 以我現在所在的銀行業務系統來說，目前的現狀大概有這些 業務邏輯太複雜 系統龐大 子...