隨著信息化系統的建設完整和市場的推廣競爭，性能慢慢變成衡量應用是否可用、好用的關鍵衡量指標之一。性能測試不同于功能測試、接口測試，性能更多關注于業務的響應速度和應用系統的整體處理能力上，當性能指標不符合與預期期望時，用戶往往會直觀地反饋不好用。
這里用戶的“不好用”就是性能測試的核心重點。通過各種監控手段采集相關性能數據后，基于業務分析在各鏈路上的耗時、判斷系統瓶頸是做性能測試、性能優化分析必不可少的環節。但是在當下這種靠個人能力或傳統安插Agent、日志等應用性能監控技術逐漸失效，已經無法滿足用戶的性能需求以及越來越快的系統迭代速度。
尤以當下企業全面轉向云計算，以容器、微服務架構、DevOps為核心的云原生架構成為降本提質增效的最優路徑背景下，大規模容器集群產生更大的業務負載能力、更高的流量突發能力。容器架構的動態變化，對性能監控、分析的范圍影響也越來越大與不可預估。因此，如何在云原生時代下更好開展質量領域性能測試，是我們為企業在市場上提供競爭力的彈藥之一。
性能測試
說到性能測試，大家的第一印象基本上都是這三個階段：
1）模擬用戶業務流程操作，通過錄制手段或腳本編輯生成性能測試腳本，對腳本進行參數化、管理、思考時間、集合點設置完成整體性能腳本
2）模擬用戶負載行為，通過場景化進行壓測的模型設置，選擇監控指標
3）分析測試數據，通過工具自帶的整合分析功能或結合其他性能數據
那么我們做性能測試的目的在于什么呢？大多數同學剛開始做性能測試的時候，都是做完性能腳本調試、設置完壓測模型、執行完腳本，看下系統的CPU、內存、吞吐量、事務TPS，在輸出一份測試報告就結束了。
這種流程和測試報告在過去10年前或許是可以接受的，這受限于當初的技術架構（單體、前后端）和監控分析手段，但在當下技術架構、業務場景、用戶需求、研發模式、敏捷轉型、研發效能等諸多內、外環境的變化，企業對性能測試的目的越來越多樣化、針對性。
常見性能測試目的一般包括：
1、確定系統的響應時間：比如系統平均響應時間≤3秒
2、確定系統的最大用戶數：比如系統在100000個用戶下平均響應時間≤4秒
3、確定系統的最佳配置：比如在Centos7、8C16G、500G配置下，某業務支持50000個用戶同時訪問，平均響應時間≤1秒
傳統性能監控的窘境
性能測試目的確定后，往往都是基于此目的去做性能壓測實施和監控數據分析，這里如何開展壓測實施流程先不展開介紹，我們主要就監控數據分析這部分大家比較少談的話題展開。
1、傳統環境下性能監控顆粒度較粗
傳統環境下系統的應用都是需要通過物理層網絡設施進行流量轉發，因此傳統環境下，業務應用流量都是通過利用網絡設備支持旁路流量鏡像的方式實現采集，比如在交換機設置端口鏡像或TAP轉發采集。
但采集到的流量數據無法和業務對應起來，基本都是系統資源上如CPU、內存、吞吐量或者本身服務器（如Tomcat）自帶的指標等數據，無法分解到具體某個URL和業務上。
這些都導致傳統性能監控更多是以監控系統可用性為核心，不涉及具體業務。
2、技術架構升級的性能監控難點
過去在單體架構、前后端分離、SOA架構上都可以進行物理層網絡設施流量采集，隨之信息化建設的發展，企業全面轉向云計算，微服務架構、容器、DevOps大行其道。
開發團隊為了滿足業務調整更加迅速，在技術上大量使用微服務架構，將業務解耦，把過去大單體拆解到小的服務，使其可以更加快速的發布投產。
運維團隊使用容器、DevOps技術，讓代碼更快發布，對業務流量進行實時監控、業務資源動態伸縮，更好的滿足業務運營需求。
而這些都導致業務解析顆粒度越來越細，服務解耦越來越清晰，問題定位需要越來越精準，尤其是在當下技術上已經不會出現較大功能問題，更多在于不同技術架構、業務依賴、基礎設施（網絡、云平臺、服務器）、服務配置、虛擬化技術的應用編排，而這些都需要精準的監控來進行分析。
3、業務性能需求常態化
得益于互聯網的飛速發展，各種技術的迭代使其能夠滿足越來越多的業務形態，比如當下最流行的直播、賽事轉播等，這些業務能夠讓我們身邊每個人都能隨時隨地的參與和訪問，都離不開性能保障。
性能需求在14年還只是在大型電商活動做秒殺、各種活動的時候，12306剛開始發售時，也曾出現無數次出票服務不可用、系統響應緩慢的問題，當時的性能需求還是被動的或針對性的開展的。而現在日常的生活娛樂、出行交通、工作協同已經是無時無刻不在開展性能需求。
云原生時代性能監控探針
面對傳統性能監控的窘境，以及現階段技術上的框架推動、敏捷開發和自動化監控部署也對性能監控發起了挑戰。
為了解決種種流量監控的難點，掌動智能云網一體化性能保障平臺（XRunner）流量診斷探針，在面對復雜云環境下真正解決云流量采集、治理、回溯、輸出的實用性價值，真正幫助企業對云環境進行無盲點、細粒度的監控，保障性能監控更加精準和性能定位到業務級別。
1、異構環境下流量采集部署
目前主流的開源項目底座、國內主流云廠商底環境、信創環境都支持云環境、宿主機、IDC機房部署、流量采集。
1）云環境支持
● 部署支持私有云、公有云、混合云環境
● 部署支持虛擬機部署，或預置在Docker
2）宿主機系統支持
● 對主流Centos7/8，Ubuntu20.0等相關發行版，都只需要一個版本、一個程序即可實現完美兼容
● 對主流虛擬化、容器化、云廠商（VMware、Kubernetes、Docker、OpenStack、阿里云、騰訊云、華為云等）支持
2、網絡接口、數據包捕獲
通過部署在私有云宿主機，或公有云工作負載的操作系統層，可以實現對：
● 全部網卡，特定網卡，IO捕獲
● 特定IP / IP:Port / Port / IP~IP / Subnet的數據包捕獲
● 并可以執行BPF條件的Byte-Code數據包過濾捕獲
3、宿主機統信數據治理與輸出
對符合特征的流量進行實時解析，可以實時輸出如下四種數據類型：
1、豐富的TCP/UDP的會話指標
判斷網絡時延行為的主要依據；可以實時的分析全部或特定網卡的TCP/UDP會話，并可以將分析結果，以UDP封裝JSON格式的數據，實時轉發到外部的數據接收端；主要的通信指標包括，聚合后的四元組信息，MAC，VXLAN/GRE編號，以及全部標志位信息等。
2、HTTP/URL的指標和內容，負載段的內容
判斷各類應用層風險的主要依據，UniProbe可以實時分析HTTP/URL/XML等會話和負載內容，并可以將其內容和主要指標，以UDP封裝的JSON數據，實時轉發到外部的數據接收端。
3、DB/SQL的指標和內容
判斷各類數據庫風險的主要依據，UniProbe可以實時分析SQL會話內容，并可以將其內容和主要指標，以UDP封裝的JSON數據，實時轉發到外部的數據接收端；支持的DB包括但不限于Oracle，MySQL，SQLserver等結構化數據庫。
4、進程信息
如上三類數據監控功能，都可以與宿主機的進程相關聯，通過分析進程的活躍程度（CPU/MEM用量），進一步定位、分解性能風險。
收益與價值
通過云網一體化性能保障平臺（XRunner）的性能診斷探針的實施，能帶給企業如下價值體現：
1、對復雜云環境下應用的云流量進行分析，做到云流量可視化，云網性能監控，異常流量發現和分析
2、在多層虛擬化環境下從物理設備層、私有云、K8S容器云、lstio、業務層POD等多維度性能追蹤，識別分層次下綜合性能瓶頸，從而進行性能定位和調優
3、幫助客戶從用戶和業務視角分析和評估業務交易健康、后端應用性能、混合基礎架構支撐能力
4、幫助用戶基于統一平臺，快速實現端到端業務交易追蹤、代碼級業務處理性能分析、業務故障、性能、多層虛擬化架構和SDN云網性能的全棧問題跟蹤與診斷等等。
免責聲明：市場有風險，選擇需謹慎！此文僅供參考，不作買賣依據。
關鍵詞：
