之前的博客，有對業內比較出名的幾家互聯網大廠的全鏈路壓測方案進行過整理和總結，傳送門：聊聊全鏈路壓測。
時隔一年多，由於性能測試及相關知識的學習實踐，對其有了新的認識，這里，再次聊聊我對全鏈路測試的理解。。。
目前的現狀
以我現在所在的銀行業務系統來說，目前的現狀大概有這些：業務邏輯太復雜、系統龐大、子系統較多、系統間解耦程度較低、調用鏈路較長、核心系統環環相扣。
在這種情況下，常規的性能測試工作內容，大概如下：
①、只能進行獨立系統的壓測工作，導致壓測任務量較大；
②、強依賴系統較多，第三方調用面臨種種限制，只能通過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的架構設計，如下圖：
完成了上面的工作，接下來就可以開展全鏈路壓測的工作了。當然，有一點需要說明：全鏈路壓測並不適用於中小型公司，一方面因為成本，另一方面，不適合而已。
最后，在開展性能測試之前，請認真思考，當我們討論性能測試時，我們在說什么？