系統容量相比傳統應用數量級增長
微服務化架構，呼叫關係更加複雜
使用者增長迅速，資源突發需求量大
▼▼▼傳統效能測試工具效能不足，自研技術門檻高
瓶頸在各微服務間漂移，測試技術難度大
如何摸清資源擴容模型，有限資源下如何驗證效能
一旦效能問題流入現網，問題定位周期長
feed流會頻繁操作後台的redis等服務，每次操作會產生100+次網路操作，200+次key/value運算，因此會成為系統的主要效能瓶頸
備註：feed是將使用者主動訂閱的訊息源組合在一起形成內容聚合器，幫助使用者持續地獲取最新的訂閱源內容，在社交類應用中被廣泛使用若干
2. 測試場景分析建模
業務特點：使用者增長迅速、突發事件高流量併發
step1：以使用場景為主線，構建效能模型（使用角色、使用階段等）
step2：分析每個操作場景的影響因子，如好友、關注數量等，建立每個場景的測試模型
單場景一級介面測試
單場景二級介面測試
如需測試某個對效能的影響，可遞增方式改變因子值進行測試
按照頁面權重分配壓力模型，實際在生產環境比例會不斷變化，因此在效能摸底過程中需要不斷調整摸底
示例：全頁面混合壓測模型
3. 測試工具需求分析
識別關鍵場景測試需求
http協議/rest介面
使用者登陸認證 ，模擬多使用者操作
支援介面串聯場景，需要上下文關聯
效能暫無基線，需要支援遞增模式快速摸底
各頁面使用者量未知，需要靈活調整混合模型配比
由於社交類應用業務增長迅速，因此需要支援按需使用，隨時擴大工具的併發量
需要支援10萬以上的併發
測試結果易於觀察、儲存
提供監控能力，便於快速定位
4. 測試服務選型與搭建
測試服務選項原則：功能滿足、效率高（即開即用）、成本低
雲效能測試服務cpts更適合測試高擴充套件性的大規模分布式系統
5. 測試執行
分層開展效能測試，在整合階段確保效能測試活動可開展
測試執行的一些典型問題
效能是乙個逐步提公升的過程，測試過程中需要找到擴容的模型，從不足50的tps提公升至萬級
6. 測試結果分析
1.1 如何從測試工具側快速分析被測物件可能存在的問題
1.2 一些通用優化建議
擴容，鏈路中的某一應用可能出現cpu使用率較高或者連線池資源不夠用(rpc、jdbc、redis連線池等)但本身對於拿到連線的請求處理又很快，這一類需要橫向擴充套件資源。
應用邏輯優化，比如存在慢sql、 邏輯的不合理如呼叫db或者redis次數過多、沒有做讀寫分離造成寫庫壓力過大。
超時時間的合理設定，對於應用之間的rpc呼叫或者應用與其他基礎元件之間的呼叫，均需要設定合理的超時時間，否則過長的等待將造成整個鏈路的故障。
快取的應用，請求盡可能從前端返回，而不是每乙個都要讓後端應用處理後再返回，減輕後端應用及資料庫壓力，提高系統吞吐能力。
限流，對於超出承載能力的qps或併發，可以進行攔截並直接返回提示頁面。
降級，對於非核心鏈路上的應用，允許故障關閉而不影響核心鏈路
擴容和優化也是有限度的，在評估容量內，保障核心交易鏈路正常是重中之重，對於非核心功能模組考慮降級場景
業務特點：突發事件高流量突發，如瞬間由百級使用者增長到萬級
對於網路架構複雜的應用，可以通過網路架構上的分段驗證，如分別從最外端的cdn入口（1）中間的elb（2）業務層（3）分別做測試，驗證網路架構上的瓶頸和影響
大規模分布式壓測
阿里雲效能測試頁面 需要臨時擴容他們的機器來支援100w的qps，每秒100w的請求，聽起來還是挺恐怖的。什麼概念呢，2013 年雙12的大秒系統的峰值qps也就在42萬多。從這樣的資料來看，這個客戶的需求高的離譜。但是既然使用者有這個需求，我們還是需要滿足客戶的期望。遇到問題主要有 遇到的挑戰主要...
分布式系統 （大規模分布式系統原理解析和架構實踐）
分布式系統的基礎理論 分布式系統 多台機器通過網路連線在一起，作為乙個整體為上層提供服務。一 基礎理論知識 資料分布 複製 一致性 容錯。1 異常 1 伺服器宕機 記憶體錯誤，伺服器停電 如何通過讀取持久化戒指 機械硬碟 固態硬碟 中的資料恢復記憶體資訊，從而恢復宕機前某個一致性狀態。2 網路異常 ...
大規模分布式儲存系統（雲儲存）作者blog
技術雜談 10年定下近幾年的技術方向 1,精通架構 深入理解線上，線下分布式儲存 計算並能夠形成完整的知識體系 2,理解系統 理解系統，網路，idc，虛擬化等相關知識 3,掌握應用 通過應用證明和修正分布式知識體系 11年做了一些事情 1,思考並討論google，amazon，microsoft，y...