隨行付微服務測試之性能測試

背景

傳統性能測試更多的是以事務爲核心，更多的是由單個或者多個事務構成業務場景進行壓測。全鏈路壓測指徹底引入相關聯的系統，儘可能真實模擬線上硬件環境，更多的是以請求爲核心，徹底模擬真實請求流量，經過引流等方式進行場景的模擬進行壓測，更多的適用於業務鏈路較長的交易。全鏈路一直是性能測試中的難點，其包含系統越多測試難度就越大，系統架構中每增長一層的監控內容就會給分析帶來幾何倍數的難度。所以，微服務架構下的性能測試的重要性就不言而喻了。

微服務架構下爲何作全鏈路壓測

微服務系統系統間調用關係複雜，當出現業務流量暴漲的狀況從CDN、網關接入、前端、緩存、中間件、後端服務、數據庫整個交易鏈路都會面臨巨大的訪問壓力，此時業務系統除了收到自身的影響還會依賴其餘關聯繫統的狀況，若是某一點出現問題，系統會累加問題並影響到其餘其餘系統，到時候是哪一個系統出問題誰也說不出清楚，好比當某系統MQ開始出現積壓，下游系統處理能就可能會變慢，當MQ吃掉內存並形成宕機，整個鏈路交易都會中止。

微服務架構下全鏈路壓測的難點

若是在測試環境進行全鏈路壓測，最大難點在於沒法評估用戶從客戶端登陸到完成交易的整個鏈路中，系統能的最大承載能力是多少。若是沒法承載生成中的流量形成系統宕機，就會有災難性的後果。因此在測試環境進行全鏈路要結合歷史生成流量，併合理作出業務增加預估，若是能知足此流量能夠斷定爲生產環境知足性能要求。固然，這只是權宜之計，若是在生產環境作全鏈路壓測不會出現此狀況。

另外，全鏈路壓測涉及的微服務模塊多，開發組多，各組開發人員又各負責本身的模塊，由於版本升級塊，業務層架構變化也快，很難能瞭解清楚最新的架構，若是漏掉一個系統的調用關係，分析就會變得很是困難。

軟件的版本控制問題，由於版本升級快，形成測試環境與生成環境代碼版本不一致，數據庫表結構和索引不一致的狀況。這種狀況會形成測試結果不許確，重複測試。多系統更難控制此狀況。

微服務架構下如何開展全鏈路測試

開展全鏈路壓測，除了傳統性能測試的需求調研、環境準備、腳本開發、數據預埋、場景設計、場景執行、應用監控分析、瓶頸定位、瓶頸修復、迴歸測試、結果整理、輸出報告等環節外還要加入分析需壓測業務場景涉及系統和協調各個壓測系統資源兩個環節。

一、梳理核心鏈路

在壓測前咱們必定要首先分析清楚須要壓測的業務場景，只有分析清楚了業務場景才能梳理出來涉及的相關係統，分析清楚後也能夠更快的找到性能瓶頸進行系統優化。這個工做通常是由架構師來梳理並確認涉及的相關係統，梳理清楚後就能夠反饋給壓測負責人進行人員和資源的協調了。

二、壓測資源協調

在全鏈路壓測過程當中，最難的工做其實不是系統優化、壓測環境搭建等技術工做，最難的是壓測資源的協調工做。這裏的資源不僅僅指壓測硬件、軟件、環境等資源，還包括了人力資源。

三、構建數據

數據的真實和可用是保證壓測結果的關鍵，儘可能使數據多元化，參數重複性低，能夠採用生產數據脫敏的方式。數據的真實性能夠保證更真實的模擬生產數據流量。數據的真實不光指發起的數據，測試數據庫的鋪底數據量也要與生產一致。

四、流量監控

搭建流量監控平臺，收集生產各類業務的流量，統計數據，按比例進行流量回放。

五、容量評估

首先知道容量目標是多少，好比所有交易量預期目標天天1億筆，按流量平臺監控到的業務佔比進行壓測，這樣咱們能夠清楚在哪一個節點應該增長多少機器，既能保證系統的穩定又能避免浪費。容量評估不是一步完成的，目標須要結合歷史數據和公司現有業務規模。第一步先按現有環境摸底測試，再逐步增長或減小機器，循環屢次，最後達到精準的容量評估。

微服務架構下全鏈路壓測優化

一、單系統優化

把鏈路中逐個環節儘可能切分紅小塊，粒度越小越佳，單粒度分析，涉及其餘系統加擋板，這樣能夠基本解決全部性能問題。缺點是性能週期長。

二、架構優化

分析系統架構，在硬件資源不飽和狀況下儘可能減小架構層。筆者在測試中遇到一個案例，A系統調用加解密服務器，A系統因特殊緣由線程固定300，不能增長線程，併發線程爲300時，A系統服務器CPU爲60%，TPS爲370左右，CPU資源不飽和，加解密服務器cpu爲50%，也不飽和，但因A系統不能調整線程數量，因此把加解密服務的包部署在A系統上，此時300併發，A服務器CPU爲100%，TPS爲700左右。這樣的好處是減小了一層系統調用的鏈接時間，數據傳輸時間，又能使硬件充分利用，減小硬件的浪費。

三、業務優化

不少開發人員都會將優化思路集中在架構層面，可是不少時候從業務流程上進行優化效果可能更好，並且提高的效果會很是明顯。業務優化不包括業務流程自己，還包活實現業務的代碼邏輯，此優化場景多用於跑批業務。

微服務架構下分析系統瓶頸

下面我將分享在性能測試中，經常使用的具體分析系統瓶頸的幾個方法。

應用系統從性能角度分爲CPU密集型應用和IO密集型應用，調優的目標是讓硬件達到瓶頸而不是軟件達到瓶頸，最直觀的體現就是TPS上升和監控到的CPU和IObusy使用率達到100%。除非有特殊要求，不然儘量使硬件使用率高。

CPU不飽和緣由有不少，最經常使用的分析手段是查看線程信息。

一、 jps命令查看java進程pid

二、jstack -l 5599 > 5599.tdump 把線程信息存進一個後綴爲tdump的文件裏，這裏後綴txt也能夠，我習慣用jvisualvm打開，因此後綴是tdump

三、sz 5599.tdump 把文件下載到本地

四、打開文件，查看線程信息，有三種狀況：

4.1. 若是線程都是RUNNABLE狀態，此時CPU利用率依然不高，說明線程池業務線程數量少，加大線程池線程數量。

4.2.若是線程狀態是BLOCKED，要查該線程等待的鎖編號。

4.3.根據鎖編號找到持有鎖的線程，再根據信息分析代碼問題並優化。

此應用CPU利用率上不去的緣由是由於須要壓縮的文件過大，壓縮時間長，致使其餘線程都在等待該線程釋放鎖，CPU同時間只能處理這一個線程，因此利用率低。

五、若是線程狀態是WAITING,要分析是什麼緣由致使線程等待：

這個線程是由於logback爲同步線程鎖，線程等待日誌寫入硬盤，致使CPU利用率上不去，只要把logback改爲異步就能夠了。

六、IO的問題有兩種狀況，一種是CPU等待IO；一種是單個磁盤IObusy達到100%，其餘磁盤空閒。第一種狀況能夠採用緩存、異步的方式去解決，這樣能解決大部分性能問題。這裏主要介紹第二種狀況，第二種狀況能夠進行業務層面的IO分散來保證。就是把寫入一個磁盤的文件分散寫到多個磁盤上，這樣就能夠緩解單個磁盤的壓力。對於性能人員來講，要定位到具體是哪一個文件致使的IO繁忙程度高。在代碼的邏輯清晰的狀況下，是徹底能夠知道哪些文件是頻繁讀寫的。可是對性能分析人員，一般是面對一個不是本身編寫的系統，有時仍是多個團隊合做產生的系統。若是能夠迅速地把問題到一個段具體的代碼，到一個具體的文件，那就能夠提升溝通的效率。

iostat命令能夠發現IO異常。iotop能夠定位具體哪一個進程致使io異常。但要定位到具體文件，咱們須要先了解一個文件的重要屬性：inode。

理解inode，要從文件儲存提及。文件儲存在硬盤上，硬盤的最小存儲單位叫作"扇區"（Sector）。每一個扇區儲存512字節（至關於0.5KB）。操做系統讀取硬盤的時候，不會一個個扇區地讀取，這樣效率過低，而是一次性連續讀取多個扇區，即一次性讀取一個"塊"（block）。這種由多個扇區組成的"塊"，是文件存取的最小單位。"塊"的大小，最多見的是4KB，即連續八個 sector組成一個 block。

[root@cdhslave1 ~]# tune2fs -l /dev/sda3|grep  Block
  Block count:              66891008
  Block size:               4096
  Blocks per group:         32768
複製代碼

文件數據都儲存在"塊"中，那麼很顯然，咱們還必須找到一個地方儲存文件的元信息，好比文件的建立者、文件的建立日期、文件的大小等等。這種儲存文件元信息的區域就叫作inode，中文譯名爲"索引節點"。inode包含文件的元信息，具體來講有如下內容：

  1. 文件的字節數

  2. 文件擁有者的User ID

  3. 文件的Group ID

  4. 文件的讀、寫、執行權限

  5. 文件的時間戳，共有三個：ctime指inode上一次變更的時間，mtime指文件內容上一次變更的時間，atime指文件上一次打開的時間。

  6. 連接數，即有多少文件名指向這個inode

  7. 文件數據block的位置

經過inode就能找到具體文件，監控inode，我用SystemTap這個工具。

SystemTap是一個診斷Linux系統性能或功能問題的開源軟件。它使得對運行時的Linux系統進行診斷調式變得更容易、更簡單。下圖是Systemtap的工做原理：

Systemtap的運行是在內核層面，而不是shell層面。Systemtap自帶的examples中有監控IO的例子，以iotop.stp爲例，執行的結果是：每隔5秒打印讀寫總量排前10位的進程。先寫一個命令dd bs=64k count=40k if=/dev/zero of=test oflag=dsync，這個命令是每次從/dev/zero 讀取64k數據，而後寫入當前目錄下的test文件，一共重複4萬次。執行命令後打開iotop.stp監控，以下圖：

能夠看到讀寫最多進程。可是現有腳本不能看到dd命令讀文件和寫文件的inode，須要本身擴展一下腳本，腳本擴展後以下圖：

這裏就能夠看到咱們讀文件的inode爲4072，寫文件的inode爲15，經過find / -inum命令能夠找到具體寫哪一個文件。

總結

本篇介紹了全鏈路壓測的概念，微服務架構下全鏈路壓測的意義、難點以及如何作全鏈路壓測，最後給出系統瓶頸分析和調優建議和方法。

做者簡介

趙延華，隨行付資深性能測試工程師，7D性能小組成員，負責性能測試方法及性能測試平臺推廣的工做，擅長性能分析和調優。