之前的部落格，有對業內比較出名的幾家網際網路大廠的全鏈路壓測方案進行過整理和總結，傳送門：聊聊全鏈路壓測。
時隔一年多，由於效能測試及相關知識的學習實踐，對其有了新的認識，這裡，再次聊聊我對全鏈路測試的理解。。。
目前的現狀
以我現在所在的銀行業務系統來說，目前的現狀大概有這些：業務邏輯太複雜、系統龐大、子系統較多、系統間解耦程度較低、呼叫鏈路較長、核心系統環環相扣。
在這種情況下，常規的效能測試工作內容，大概如下：
①、只能進行獨立系統的壓測工作，導致壓測任務量較大；
②、強依賴系統較多，第三方呼叫面臨種種限制，只能通過mock方式解決；
③、沒有較為獨立的效能測試環境，uat和pat測試資料差異較大，無法給予上線乙個較為準確的容量評估；
④、專案排期沒有預留足夠的效能測試時間，導致需要經常加班甚至通宵；
⑤、工程師檔案建立較為薄弱，對系統效能的認知和重視度不足，往往讓人覺得沮喪；
上面的幾種情況，據我了解，在大多數公司都存在類似的情況，這些因素導致面臨著越來越高的資料衝擊和越來越複雜的業務場景，急需一種手段來保障和提高系統的高效能高可用。
面臨的挑戰
除了上面所說的技術層面的問題，要開展全鏈路壓測，還面臨如下的幾點挑戰：
①、由於全鏈路壓測涉及的系統及場景較多，因此需要跨團隊溝通、跨系統協調改造，公司體量越大，這一點難度就越大；
②、全鏈路壓測涉及的系統較多，且不同的系統架構也有所不同，因此需要考慮：機房管理、基礎網路、db管理、持久儲存、中介軟體、應用部署、流量接入、監控與運維保障等多方面；
③、全鏈路壓測的目的是找到系統呼叫鏈路薄弱環節並優化，這就要求對整個呼叫鏈路涉及的系統進行進行準確的容量規劃，因此環境和配置，是必須重視的一點；
當然，可能還存在其他問題，比如效能測試團隊成員的技術水平是否滿足要求、管理層的支援力度等方面，畢竟，這是一項很龐大複雜的軟體工程專案！！！
不過全鏈路壓測的優點也很明顯，比如：優化聯絡薄弱環節可以提高系統的可用性，容量規劃可以節省成本，提高效率。
開展前的準備工作
在開展全鏈路壓測之前，我們需要做哪些準備工作？
①、業務梳理：覆蓋全部的業務場景，是難度很大且不理智的選擇，一般來說只需要篩選出高頻使用的功能、核心功能以及基礎功能即可；
②、場景梳理：場景梳理也是很重要的一項工作，因為只有確定了被測場景，我們才能設計合理的測試方案和策略，場景覆蓋正常操作、異常操作即可；
③、流量模型：「我們往往對高併發一無所知！」因此需要通過監控分析等手段，得到日常流量場景、峰值流量場景下各系統的流量以及配比，進行一定的放大，來作為全鏈路壓測的流量參考模型；
④、資料處理：全鏈路壓測通常在生產環境進行，所以防止資料汙染是必須考慮的問題，一般來說都是通過對入口流量進行標記區分、資料隔離、影子庫等方式來避免，當然，還需要做好災備工作；
⑤、實時監控：無論是壓測開始前還是測試進行中，都需要及時且視覺化的獲取到系統的狀態變化，方便及時排查定位問題，也避免壓測對正常的服務造成干擾；
監控的重點，主要是對應服務的tps、不同百分比的rt、成功率、資源耗用、服務狀態、告警等資訊；
全鏈路壓測平台架構設計
要開展全鏈路壓測，那麼乙個合理高效可用的壓測管理平台，是很有必要的，參考了很多全鏈路壓測的設計思路，我個人的想法中全鏈路壓測平台的架構設計，主要由以下幾部分組成：
①、controller：主要任務為壓測任務分配、agent管理；
②、agent：負責心跳檢測、壓測任務拉取、執行壓測（多程序多執行緒方式）；
③、task service：負責壓測任務下發、agent的橫向擴充套件，以確保壓測發起端不成為瓶頸（可以利用rpc框架來實現）；
④、monitor service：接收agent回傳的監控和測試資料日誌，並**給訊息佇列，讓compute service進行彙總計算展現；
⑤、compute service：對壓測結果進行計算，並結合grafana等視覺化工具進行介面展示；
⑥、log service：日誌服務，即無論壓測機還是服務應用在測試過程中產生的日誌，都統一收集，方便進行問題排查定位；
⑦、elasticsearch/influxdb：對壓測產生的資料儲存；
⑧、git：壓測指令碼的版本管理；
⑨、gitlab：作為資料倉儲進行版本管理，agent主動拉取指令碼執行；
⑩、redis：主要用於配置資訊管理；
ps：當然，我個人的構思存在不完善或者有待仔細斟酌的地方，這裡只是給乙個參考。具體的架構設計圖，可參考京東的全鏈路軍演系統forcebot的架構設計，如下圖：
完成了上面的工作，接下來就可以開展全鏈路壓測的工作了。當然，有一點需要說明：全鏈路壓測並不適用於中小型公司，一方面因為成本，另一方面，不適合而已。
最後，在開展效能測試之前，請認真思考，當我們討論效能測試時，我們在說什麼？
全鏈路壓測
2013年為了雙11提前預演而誕生,該服務已提供在阿里雲pts鉑金版。1.1.1 系統可用性問題 經常由下面一些不確定性因素引起 1.1.2 傳統線上單機與單系統壓測的四種方式 從流量分配的角度，將流量集中到某台機器 這兩種方式要求訪問流量不能太小 1.1.3 單系統壓測的問題單鏈路指乙個業務線。全...
全鏈路壓測
之前有和認識的同行聊過他們全鏈路壓測的一些技術實現方案，自己也看了很多相關的資料，這篇部落格，說說自己對全鏈路壓測的理解，以及整理的一些知識點。阿里全鏈路壓測 有讚全鏈路壓測 京東全鏈路壓測 餓了麼全鏈路壓測 一 什麼是全鏈路壓測 基於實際的生產業務場景 系統環境，模擬海量的使用者請求和資料對整個業...
全鏈路壓測筆記
公司業務發展，難有乙個量化的資料衡量核心鏈路的真實峰值。有助於提公升核心業務的穩定性。找出整個鏈路的瓶頸，優化少量的瓶頸部分提公升整體效能，以期達到用最少的資源達到最佳效果。認識誤區 不能單純認為壓測各個子系統後，整體系統沒有問題，因為涉及到業務訪問鏈路，多個業務可能有共用資源的瓶頸，主鏈路請求量增...