背景
傳統性能測試更多的是以事務爲核心，更多的是由單個或者多個事務構成業務場景進行壓測。全鏈路壓測指完全引入相關聯的系統，儘量真實模擬線上硬件環境，更多的是以請求爲核心，完全模擬真實請求流量，通過引流等方式進行場景的模擬進行壓測，更多的適用於業務鏈路較長的交易。全鏈路一直是性能測試中的難點，其包含系統越多測試難度就越大，系統架構中每增加一層的監控內容就會給分析帶來幾何倍數的難度。因此，微服務架構下的性能測試的重要性就不言而喻了。
微服務架構下爲什麼做全鏈路壓測
微服務系統系統間調用關係複雜，當出現業務流量暴漲的情況從CDN、網關接入、前端、緩存、中間件、後端服務、數據庫整個交易鏈路都會面臨巨大的訪問壓力，此時業務系統除了收到自身的影響還會依賴其他關聯繫統的情況，如果某一點出現問題，系統會累加問題並影響到其他其他系統，到時候是哪個系統出問題誰也說不出清楚，比如當某系統MQ開始出現積壓，下游系統處理能就可能會變慢，當MQ吃掉內存並造成宕機，整個鏈路交易都會停止。
微服務架構下全鏈路壓測的難點
如果在測試環境進行全鏈路壓測，最大難點在於無法評估用戶從客戶端登錄到完成交易的整個鏈路中，系統能的最大承載能力是多少。如果無法承載生成中的流量造成系統宕機，就會有災難性的後果。所以在測試環境進行全鏈路要結合歷史生成流量，併合理做出業務增長預估，如果能滿足此流量可以判定爲生產環境滿足性能要求。當然，這只是權宜之計，如果在生產環境做全鏈路壓測不會出現此情況。
另外，全鏈路壓測涉及的微服務模塊多，開發組多，各組開發人員又各負責自己的模塊，因爲版本升級塊，業務層架構變化也快，很難能瞭解清楚最新的架構，如果漏掉一個系統的調用關係，分析就會變得非常困難。
軟件的版本控制問題，因爲版本升級快，造成測試環境與生成環境代碼版本不一致，數據庫表結構和索引不一致的情況。這種情況會造成測試結果不準確，重複測試。多系統更難控制此情況。
微服務架構下如何開展全鏈路測試
開展全鏈路壓測，除了傳統性能測試的需求調研、環境準備、腳本開發、數據預埋、場景設計、場景執行、應用監控分析、瓶頸定位、瓶頸修復、迴歸測試、結果整理、輸出報告等環節外還要加入分析需壓測業務場景涉及系統和協調各個壓測系統資源兩個環節。
1、梳理核心鏈路
在壓測前我們一定要首先分析清楚需要壓測的業務場景，只有分析清楚了業務場景才能梳理出來涉及的相關係統，分析清楚後也可以更快的找到性能瓶頸進行系統優化。這個工作一般是由架構師來梳理並確認涉及的相關係統，梳理清楚後就可以反饋給壓測負責人進行人員和資源的協調了。
2、壓測資源協調
在全鏈路壓測過程中，最難的工作其實不是系統優化、壓測環境搭建等技術工作，最難的是壓測資源的協調工作。這裏的資源不單單指壓測硬件、軟件、環境等資源，還包括了人力資源。
3、構建數據
數據的真實和可用是保證壓測結果的關鍵，儘量使數據多元化，參數重複性低，可以採用生產數據脫敏的方式。數據的真實性可以保證更真實的模擬生產數據流量。數據的真實不光指發起的數據，測試數據庫的鋪底數據量也要與生產一致。
4、流量監控
搭建流量監控平臺，收集生產各種業務的流量，統計數據，按比例進行流量回放。
5、容量評估
首先知道容量目標是多少，比如全部交易量預期目標每天1億筆，按流量平臺監控到的業務佔比進行壓測，這樣我們可以清楚在哪個節點應該增加多少機器，既能保證系統的穩定又能避免浪費。容量評估不是一步完成的，目標需要結合歷史數據和公司現有業務規模。第一步先按現有環境摸底測試，再逐步增加或減少機器，循環多次，最後達到精準的容量評估。
微服務架構下全鏈路壓測優化
1、單系統優化
把鏈路中逐個環節儘量切分成小塊，粒度越小越佳，單粒度分析，涉及其他系統加擋板，這樣可以基本解決所有性能問題。缺點是性能週期長。
2、架構優化
分析系統架構，在硬件資源不飽和情況下儘量減少架構層。筆者在測試中遇到一個案例，A系統調用加解密服務器，A系統因特殊原因線程固定300，不能增加線程，併發線程爲300時，A系統服務器CPU爲60%，TPS爲370左右，CPU資源不飽和，加解密服務器cpu爲50%，也不飽和，但因A系統不能調整線程數量，所以把加解密服務的包部署在A系統上，此時300併發，A服務器CPU爲100%，TPS爲700左右。這樣的好處是減少了一層系統調用的連接時間，數據傳輸時間，又能使硬件充分利用，減少硬件的浪費。
3、業務優化
很多開發人員都會將優化思路集中在架構層面，但是很多時候從業務流程上進行優化效果可能更好，而且提升的效果會非常明顯。業務優化不包括業務流程本身，還包活實現業務的代碼邏輯，此優化場景多用於跑批業務。
微服務架構下分析系統瓶頸
下面我將分享在性能測試中，常用的具體分析系統瓶頸的幾個方法。
應用系統從性能角度分爲CPU密集型應用和IO密集型應用，調優的目標是讓硬件達到瓶頸而不是軟件達到瓶頸，最直觀的體現就是TPS上升和監控到的CPU和IObusy使用率達到100%。除非有特殊要求，否則儘可能使硬件使用率高。
CPU不飽和原因有很多，最常用的分析手段是查看線程信息。
1、 jps命令查看java進程pid
2、jstack -l 5599 > 5599.tdump 把線程信息存進一個後綴爲tdump的文件裏，這裏後綴txt也可以，我習慣用jvisualvm打開，所以後綴是tdump
3、sz 5599.tdump 把文件下載到本地
4、打開文件，查看線程信息，有三種情況：
4.1. 如果線程都是RUNNABLE狀態，此時CPU利用率依然不高，說明線程池業務線程數量少，加大線程池線程數量。
4.2.如果線程狀態是BLOCKED，要查該線程等待的鎖編號。
4.3.根據鎖編號找到持有鎖的線程，再根據信息分析代碼問題並優化。
此應用CPU利用率上不去的原因是因爲需要壓縮的文件過大，壓縮時間長，導致其他線程都在等待該線程釋放鎖，CPU同時間只能處理這一個線程，所以利用率低。
5、如果線程狀態是WAITING,要分析是什麼原因導致線程等待：
這個線程是因爲logback爲同步線程鎖，線程等待日誌寫入硬盤，導致CPU利用率上不去，只要把logback改成異步就可以了。
6、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命令可以找到具體寫哪個文件。
總結
本篇介紹了全鏈路壓測的概念，微服務架構下全鏈路壓測的意義、難點以及如何做全鏈路壓測，最後給出系統瓶頸分析和調優建議和方法。