基於實際的生產業務場景、系統環境，模擬海量的使用者請求和資料對整個業務鏈進行壓力測試，並持續調優的過程
單鏈路指乙個業務線。全鏈路壓測是乙個模擬線上環境的完整閉環，由5大核心要素組成：
壓測環境：對應使用者真實的線上環境，具備資料與流量隔離能力的生產環境； 原則：能夠用中介軟體解決的問題，絕不對業務系統進行改造，系統所需做的是公升級中介軟體，這一原則極大提高了工作效率。
壓測流量（模型、資料）：成百上千的介面組合，到複雜的介面之間的引數傳遞，複雜的條件判斷來構造精準的全域性流量模型，和真實業務情況保持一致；
> 壓測引擎的三層結構：
流量發起：模擬全國各地真實的使用者請求訪問，探測站點能力；
問題定位：多維度的監控和報表，服務端可通過其他生態產品協助定位。
翻譯構造能力的體現：便捷的構造全域性業務場景和流量資料的能力。原子因素：鏈路（被壓測的最小單位） 指令： 思考時間、集合點、條件跳轉、cookie訪問、全域性準備、併發使用者限制等
原子因素->序列鏈路->場景
ps：業務的不斷發展，依賴的模組不斷增多。需要找出短板來進行解決
ps：介面的服務能力取決於模組中最低的那個—木桶理論
首先應該明確的是：全鏈路壓測針對的是現代越來越複雜的業務場景和全鏈路的系統依賴。所以首先應該將核心業務和非核心業務進行拆分，確認流量高峰針對的是哪些業務場景和模組，針對性的進行擴容準備，而不是為了解決海量流量衝擊而所有的系統服務集群擴容幾十倍，這樣會造成不必要的成本投入。
全鏈路壓測應對的都是海量的使用者請求衝擊，可以使用分布式壓測的手段來進行使用者請求模擬，目前有很多的開源工具可以提供分布式壓測的方式，比如jmeter、ngrinder、locust等。可以基於這些壓測工具進行二次開發，由contorller機器負責請求分發，agent機器進行壓測，然後測試結果上傳contorller機器。
考慮到壓測量較大的情況下回傳測試結果會對agent本身造成一定資源占用，可以考慮非同步上傳，甚至事務補償機制。
回放業務高峰期產生的流量根據系統的實際情況對壓力進行相應調整。通過以上兩種方式生成壓測詞表（詞表分片處理，方便後續批量載入）
**設計：觀察者模式（會觸發的事件）和責任鏈模式（執行事件）客戶端熔斷： 根據業務自定義的熔斷閾值，實時分析監控資料，當達到熔斷閾值時，任務排程器會向壓測引擎傳送降低qps或者直接中斷壓測的指令，防止系統被壓掛。
容量規劃的目的在於讓每乙個業務系統能夠清晰地知道：什麼時候該加機器、什麼時候應該減機器？雙11等大促場景需要準備多少機器，既能保障系統穩定性、又能節約成本
ps：什麼時候增減機器、保障系統穩定性、節約成本業務流量預估階段：通過歷史資料分析未來某乙個時間點業務的訪問量會有多大
系統容量評估階段：初步計算每乙個系統需要分配多少機器
容量的精調階段：通過全鏈路壓測來模擬大促時刻的使用者行為，在驗證站點能力的同時對整個站點的容量水位進行精細調整
流量控制階段：對系統配置限流閾值等系統保護措施，防止實際的業務流量超過預估業務流量的情況下，系統無法提供正常服務流量控制階段：對系統配置限流閾值等系統保護措施，防止實際的業務流量超過預估業務流量的情況下，系統無法提供正常服務
為了精準地獲取到單台機器的服務能力，壓力測試都是直接在生產環境進行，這有兩個非常重要的原因：單機壓測既需要保證環境的真實性，又要保證流量的真實性
模擬請求：通過對生產環境的一台機器發起模擬請求呼叫來達到壓力測試的目的
工具：apache ab、webbench、httpload、jmeter、loadrunner複製請求：通過將一台機器的請求複製多份傳送到指定的壓測機器適用場景：新系統上線或者訪問量不大的系統採用這種方式來進行單機壓測
缺點：模擬請求和真實業務請求之間存在的差異，會對壓力測試的結果造成影響 另乙個缺點在於寫請求的處理比較麻煩，因為寫請求可能會對業務資料造成汙染，這個汙染要麼接受、要麼需要做特殊的處理(比如將壓測產生的資料進行隔離）
ps：和真實請求有差異、寫請求需要處理、適合新系統上線或訪問量不大的
適用場景：系統呼叫量比較小的場景請求**：將分布式環境中多台機器的請求**到一台機器缺點：同樣也面臨著處理寫請求髒資料的問題 另外乙個缺點複製的請求必須要將響應攔截下來，所以被壓測的這台機器需要單獨提供，且不能提供正常的服務(不能把響應給到真實的使用者了，比如涉及到發簡訊郵件之類的)
適用場景：系統呼叫量比較大的場景調整負載均衡優點：請求的引流**方式不僅壓測結果非常精準、不會產生髒資料、而且操作起來也非常方便快捷，在阿里巴巴也是用的非常廣泛的一種單機壓測方式，這種方式怎麼測試出當前系統最大能抗的流量是多少呢？
適用場景：系統呼叫量比較大的場景經常由下面一些不確定性因素引起：優點：調整負載均衡方式活的的壓測結果非常準確、並且不會產生髒資料
ps：單機壓測可以基於上面的4種壓測方式基礎上，構件一套自動化的壓測系統，可以配置定時任務定期對系統進行壓測，也可以在任意想壓測的時間點手動觸發一次壓測
在進行壓測的同時，實時探測壓測機器的系統負載，一旦系統負載達到預設的閾值即立刻停止壓測，同時輸出乙份壓測報告 通過單機壓測獲取的單機服務能力值也是容量規劃乙個非常重要的參考依據
最小機器數 ＝ 預估的業務訪問量 ／ 單機能力
從流量分配的角度，將流量集中到某台機器（這兩種方式要求訪問流量不能太小）：
接收和傳送 http / grpc 等請求時
依賴的模組
mongodb 使用影子 collection ，將壓測流量對 mongodb 的讀寫打到影子表上。即正常的業務表名為a,則影子表名為 ashadow
redis 使用影子 key ，將壓測流量對 redis 的讀寫打到影子 key 上。 如set key value會變成set key_shadow valuekafka 使用影子 topic，key 後拼接 _shadow
不需要參與壓測的做 mock 處理
2023年為了雙11提前預演而誕生,該服務已提供在阿里雲pts鉑金版。
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機制實現了類似狀態機的概念，狀態屬性持久化到資料庫中，便於恢復。
阿里全鏈路壓測
有讚全鏈路壓測
京東全鏈路壓測
餓了麼全鏈路壓測
滴滴全鏈路壓測解決之道
美團全鏈路壓測自動化實踐
全鏈路壓測
2013年為了雙11提前預演而誕生,該服務已提供在阿里雲pts鉑金版。1.1.1 系統可用性問題 經常由下面一些不確定性因素引起 1.1.2 傳統線上單機與單系統壓測的四種方式 從流量分配的角度，將流量集中到某台機器 這兩種方式要求訪問流量不能太小 1.1.3 單系統壓測的問題單鏈路指乙個業務線。全...
全鏈路壓測
之前有和認識的同行聊過他們全鏈路壓測的一些技術實現方案，自己也看了很多相關的資料，這篇部落格，說說自己對全鏈路壓測的理解，以及整理的一些知識點。阿里全鏈路壓測 有讚全鏈路壓測 京東全鏈路壓測 餓了麼全鏈路壓測 一 什麼是全鏈路壓測 基於實際的生產業務場景 系統環境，模擬海量的使用者請求和資料對整個業...
全鏈路壓測筆記
公司業務發展，難有乙個量化的資料衡量核心鏈路的真實峰值。有助於提公升核心業務的穩定性。找出整個鏈路的瓶頸，優化少量的瓶頸部分提公升整體效能，以期達到用最少的資源達到最佳效果。認識誤區 不能單純認為壓測各個子系統後，整體系統沒有問題，因為涉及到業務訪問鏈路，多個業務可能有共用資源的瓶頸，主鏈路請求量增...