全鏈路壓測？
基于實際的生產業務場景和系統環境，模擬海量的用戶請求和資料，對整個業務鏈路進行各種場景的測驗驗證，持續發現并進行瓶頸調優，保障系統穩定性的一個技術工程，
針對業務場景越發復雜化、海量資料沖擊，發現并解決整個業務系統的可用性、擴展性以及容錯性的程序，
核心流程
全鏈路壓測實施的核心流程如下：
1 全鏈路壓測的意義
? 上圖是 2012 年淘寶核心業務應用關系的拓撲圖，還不包含了其他的非核心業務應用，所謂的核心業務就是和交易相關的，和錢相關的業務，這張圖大家可能看不清楚，看不清楚才是正常的，因為當時的阿里應用數量之多、應用間關系之混亂靠人工確實已經無法理清楚了，
? 在真實的業務場景種，每個系統的壓力都比較大，而系統之間是有相互依賴關系的，單機壓測沒有考慮到依賴環節壓力都比較大的情況，會引入一個不確定的誤差，這就好比，我們要生產一個儀表，每一個零件都經過了嚴密的測驗，最終把零件組裝成一個儀表，儀表的作業狀態會是什么樣的并不清楚，
技術角度：降低成本、提高服務可用性、技術練兵&團隊協作&快速回應；
業務角度：提升用戶體驗、技術更好的服務業務、創造更多業務價值，
2 鏈路壓測方案刨析
2.1 線下壓測
? 顧名思義就是在測驗環境進行壓測，且是針對一些重點專案這種測驗手段，因為測驗環境硬體資源以及壓測資料與線上差別太大并且服務間依賴關系錯綜復雜，測驗環境很難模擬且不夠穩定，壓測出來的資料指標參考價值不大，難以用測驗環境得出的結果推導生產真實容量，
2.2 預生產環境壓測
? 這個一般是將生成環境的硬體以及軟體同步復制到與生產環境一份，然后對服務內部的外部呼叫介面進行攔截，然后進行壓測這樣可以評估出來生產環境的真實容量以及達到壓測的目的，但是成本非常高，需要將生產環境的硬體完全的復制一份，并未維護成本非常高，部署的時候需要同步的在預生產環境進行部署，以及壓測代碼的更改，
2.3 引流壓測
? 隨著業務量的不斷增長，考慮到線下測驗結果的準確性，開始嘗試生產壓測，這種壓測手段，我們稱之為引流壓測，事實上沒有真正的模擬放大壓力進行測驗，而是一種通過縮小在線服務集群數的方式來放大單機處理量，比如一個業務系統的集群有100個節點，將其中90個節點模擬下線或轉發流量到剩余的10個節點上實施壓測，
? 引流壓測的弊端在于，DB承受壓力不變，上下游系統的壓力不變，壓測結果僅能代表單個應用的性能，但往往無法識別鏈路和架構級的隱患，而且在引流程序中倘若出現例外或突如其來的業務高峰，很容易造成生產故障，
2.4 全鏈路壓測
? 隨著微服務架構的流行，服務按照不同的維度進行拆分，一次請求往往需要涉及到多個服務，互聯網應用構建在不同的軟體模塊集上，這些軟體模塊，有可能是由不同的團隊開發、可能使用不同的編程語言來實作、有可能布在了幾千臺服務器，橫跨多個不同的資料中心，因此，就需要一些可以幫助理解系統行為、用于分析性能問題的工具，以便發生故障的時候，能夠快速定位和解決問題，但是他的缺點也很明顯就是需要的技術難度很高，需要克服流量染色，資料隔離，日志隔離，風險熔斷等技術難題，因位在生產環境壓測，所以控制不好風險也是非常高的，
? 所以，在復雜的微服務架構系統中，幾乎每一個前端請求都會形成一個復雜的分布式服務呼叫鏈路，一個請求完整呼叫鏈可能如下圖所示：
2.5 四種壓測方案對比
| 壓測效果 | 技術難度 | 機器成本 | 維護成本 | 風險 | |
|---|---|---|---|---|---|
| 線下壓測 | 差 | 低 | 低 | 低 | 無 |
| 預生產壓測 | 好 | 低 | 高 | 高 | 中 |
| 引流壓測 | 差 | 中 | 無 | 低 | 高 |
| 全鏈路壓測 | 好 | 高 | 無 | 低 | 高 |
3. 全鏈路壓測概述
3.1 什么是全鏈路壓測
? 基于實際的生產業務場景、生產環境，模擬海量的用戶請求和資料對整個業務鏈（通常是核心業務鏈）進行壓力測驗，并持續調優的程序，
3.2 解決什么問題
? 解決在業務場景越發復雜化、海量資料沖擊下系統整個業務鏈的可用性、服務能力的瓶頸，以及容量規劃等問題，
3.2.3 精確的容量規劃
3.2.3.1 為什么需要容量規劃
什么時候增級訓器、保障系統穩定性、節約成本
? 容量規劃的目的在于讓每一個業務系統能夠清晰地知道：什么時候該加機器、什么時候應該級訓器？雙11等大促場景需要準備多少機器，既能保障系統穩定性、又能節約成本
3.2.3.2 容量規劃四步走
- 業務流量預估階段：通過歷史資料分析未來某一個時間點業務的訪問量會有多大
- 系統容量評估階段：初步計算每一個系統需要分配多少機器
- 容量的精調階段：通過全鏈路壓測來模擬大促時刻的用戶行為，在驗證站點能力的同時對整個站點的容量水位進行精細調整
- 流量控制階段：對系統配置限流閾值等系統保護措施，防止實際的業務流量超過預估業務流量的情況下，系統無法提供正常服務流量控制階段：對系統配置限流閾值等系統保護措施，防止實際的業務流量超過預估業務流量的情況下，系統無法提供正常服務
3.3 進行全鏈路的性能監控
全鏈路性能監控 從整體維度到區域維度展示各項指標，將跨應用的所有呼叫鏈性能資訊集中展現，可方便度量整體和區域性能，并且方便找到故障產生的源頭，生產上可極大縮短故障排除時間，
- 保證系統穩定性：可能提前預估系統存在的各種問題，提前模擬高并發場景，有備無患，
- 請求鏈路追蹤，故障快速定位：可以通過呼叫鏈結合業務日志快速定位錯誤資訊，
- 精準的容量評估：能夠定位到最需要擴容的服務，幫助公司用最低的成本滿足業務的性能要求
- 真實的性能驗證：能夠在生成環境以最真實的環境來驗證系統的真實性能，
- 資料分析，優化鏈路：可以得到用戶的行為路徑，匯總分析應用在很多業務場景，
3.4 如何展開全鏈路壓測
3.4.1 業務模型梳理
- 首先應該將核心業務和非核心業務進行拆分，確認流量高峰針對的是哪些業務場景和模塊，針對性的進行擴容準備，
- 梳理出對外的介面：使用MOCK（模擬）方式做擋板，
- 千萬不要污染正常資料：認真梳理資料處理的每一個環節，確保 mock 資料的處理結果不會寫入到正常庫里面
3.4.2 資料模型構建
- 資料的真實性和可用性：可以從生產環境完全移植一份當量的資料包，作為壓測的基礎資料，然后基于基礎資料，通過分析歷史資料增長趨勢，預估當前可能的資料量
- 資料隔離：千萬千萬不要污染正常資料：認真梳理資料處理的每一個環節，可以考慮通過壓測資料隔離處理，落入影子庫，mock 物件等手段，來防止資料污染
3.4.3 壓測工具選型
? 使用分布式壓測的手段來進行用戶請求模擬，目前有很多的開源工具可以提供分布式壓測的方式，比如JMeter、nGrinder、Locust等，
務模塊介紹
現在我們對整體的業務進行介紹以及演示
本文由
傳智教育博學谷教研團隊發布，如果本文對您有幫助，歡迎
關注和點贊；如果您有任何建議也可留言評論或私信，您的支持是我堅持創作的動力，轉載請注明出處！
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/507124.html
標籤：Java
下一篇：阿里云云效流水線自動部署配置