今天讀了美團技術團隊新發布的全鏈路壓測平台quake在美團中的實踐，做個筆記。
先說下總的讀後感:
壓力測試/效能測試有多種方式，從下面的幾個發展階段可以看出越來越追求真實高峰訪問的模擬。
現在大公司普遍的分布式架構，雲計算的應用，容器的使用也可以提供更有力的資源排程。但全鏈路壓測最重要的工作在於需要架構，開發團隊的支援和適配工作。
沒有全鏈路的監控及相關工具支撐，沒有架構的調整（壓測標識）和資料庫的配合（影子表），這個全鏈路壓測就是個聽起來更美的名字（你也知道技術圈喜歡造新詞）。
文章筆記摘要基於線上真實環境和實際業務場景，通過模擬海量的使用者請求，對整個系統進行壓力測試。
主要特徵：
回放業務高峰期產生的流量
通過以上兩種方式生成壓測詞表?（詞表分片處理，方便後續批量載入）
新增壓測標識，各服務和中介軟體依據標識來進行壓測服務的分組和影子表方案的實施。
在請求頭新增特殊標識，但需要保證執行緒間和跨服務間透傳。
鏈路診斷功能方便定位問題。
2.2.1 服務隔離
通常選擇深夜低峰壓測，同時隔離正常流量和測試流量。 隔離策略：基於ip，機器數，百分比
2.2.2 資料隔離
影子表（阿里）：使用線上同乙個資料庫，包括共享資料庫中的記憶體資源，只在寫入資料時寫進另乙個影子表。 kv的處理類似，mq則選擇生產端或消費端忽略訊息。
2.3.1 資源計算預估
2.3.2 事件注入機制
根據系統的實際情況對壓力進行相應調整。
**設計：觀察者模式（會觸發的事件）和責任鏈模式（執行事件）
2.3.3 熔斷保護機制
客戶端熔斷： 根據業務自定義的熔斷閾值，實時分析監控資料，當達到熔斷閾值時，任務排程器會向壓測引擎傳送降低qps或者直接中斷壓測的指令，防止系統被壓掛。
全鏈路壓測
2013年為了雙11提前預演而誕生,該服務已提供在阿里雲pts鉑金版。1.1.1 系統可用性問題 經常由下面一些不確定性因素引起 1.1.2 傳統線上單機與單系統壓測的四種方式 從流量分配的角度，將流量集中到某台機器 這兩種方式要求訪問流量不能太小 1.1.3 單系統壓測的問題單鏈路指乙個業務線。全...
全鏈路壓測
之前有和認識的同行聊過他們全鏈路壓測的一些技術實現方案，自己也看了很多相關的資料，這篇部落格，說說自己對全鏈路壓測的理解，以及整理的一些知識點。阿里全鏈路壓測 有讚全鏈路壓測 京東全鏈路壓測 餓了麼全鏈路壓測 一 什麼是全鏈路壓測 基於實際的生產業務場景 系統環境，模擬海量的使用者請求和資料對整個業...
全鏈路壓測筆記
公司業務發展，難有乙個量化的資料衡量核心鏈路的真實峰值。有助於提公升核心業務的穩定性。找出整個鏈路的瓶頸，優化少量的瓶頸部分提公升整體效能，以期達到用最少的資源達到最佳效果。認識誤區 不能單純認為壓測各個子系統後，整體系統沒有問題，因為涉及到業務訪問鏈路，多個業務可能有共用資源的瓶頸，主鏈路請求量增...