2019年10月26日，由Testin主辦的第二屆NCTS中國云測試行業(yè)峰會在京召開，此次峰會以“AI+未來”為主題，匯聚來自國內(nèi)外測試領(lǐng)域的知名專家學(xué)者、領(lǐng)先企業(yè)決策者、高層技術(shù)管理者、媒體從業(yè)者等，共同探討高端云測試技術(shù)，幫助測試從業(yè)者了解最前沿行業(yè)趨勢，及最新的行業(yè)實(shí)踐。

會上，VIPKID性能測試方向負(fù)責(zé)人寧浩然做《千萬級約課系統(tǒng)自動化壓測實(shí)踐》主題演講。寧浩然分析了

VIPKID在鏈路壓測過程中遇到的問題和挑戰(zhàn)，介紹了自動化壓測平臺如何解決代碼級定位鏈路上的性能問題，以及公司如何在無人值守的情況下完成自動化壓測。他指出，“對于測試開發(fā)工程師，最重要的不是為了開發(fā)而開發(fā)，而是要發(fā)現(xiàn)工作過程中遇到的痛點(diǎn)問題，把那些可以重復(fù)化的或者可以用機(jī)器取代的工作通過技術(shù)手段替代掉，這才是我們主要的工作方向。”

以下為寧浩然演講實(shí)錄：

大家好，我是VIPKID的寧浩然，很高興在這里給大家?guī)肀敬畏窒恚曳窒淼闹黝}是《千萬級約課系統(tǒng)自動化壓測實(shí)踐》。我會基于VIPKID的特點(diǎn)，分析我們在鏈路壓測過程中遇到的問題和挑戰(zhàn)有哪些，簡單介紹一下開發(fā)的自動化壓測平臺是如何解決代碼級定位鏈路上的性能問題，以及我們?nèi)绾胃以跓o人值守的情況下完成自動化壓測。

首先簡單介紹一下我們的業(yè)務(wù)，VIPKID目前的業(yè)務(wù)是在線教育。簡單點(diǎn)來說，用戶可以使用我們的軟件進(jìn)行課程預(yù)約，在約定的時間內(nèi)通過視頻的方式完成在線一對一線上上課。我們每周一中午會開放下周的課程預(yù)約，屆時會有幾十萬的用戶在短短1分鐘時間內(nèi)將下周要上的課全部約完，這種搶課模式給我們的系統(tǒng)造成了相當(dāng)大的壓力。每周一對于我們來講都是一個大考。現(xiàn)在公司成立了專門的供需團(tuán)隊(duì)解決用戶需求方面的問題，目前高峰期的流量已經(jīng)有了一定程度上的緩解，所以本次分享我們會以業(yè)務(wù)和系統(tǒng)壓力增長最快的2017-2018年為例，介紹我們是如何扛住每周一次的約課高峰。

從圖里可以看到，我們在一年的時間里系統(tǒng)承載壓力上漲了13倍左右，而單秒的約課量也達(dá)到了數(shù)千節(jié)，每周一這個“大考”，對于我們來說可以說是越來越嚴(yán)峻，而留給我們產(chǎn)研團(tuán)隊(duì)的時間永遠(yuǎn)只有一周。

挑戰(zhàn)有哪些？首先可以看一下我們的約課鏈路，為了讓我們的系統(tǒng)可以承載更高的壓力，滿足業(yè)務(wù)的增長預(yù)期，我們把鏈路上的每一個環(huán)節(jié)都做了調(diào)整或者優(yōu)化，這些調(diào)整讓我們的系統(tǒng)承載能力有了很大提高，但是在這個調(diào)整的過程中，無疑是非常痛苦的。我們上到ELB、SLB下到DB，每一次改動都有或多或少的隱患，這些隱患放到線上都是一種災(zāi)難，我們通過鏈路壓測的方式把這些問題全部招回，保證我們近兩年約課高峰期的穩(wěn)定性，近兩年共招回線上性能風(fēng)險近百例。

總結(jié)一下，我們主要面臨的挑戰(zhàn)有以下幾點(diǎn)：1、上線非常頻繁，在座可能會說上線頻繁算什么特點(diǎn)，作為互聯(lián)網(wǎng)公司哪家上線不頻繁呢？這里的上線有很大一部分都是服務(wù)重構(gòu)、拆庫拆表優(yōu)化類的項(xiàng)目，這些改動都會影響我們核心的約課鏈路，所以每次的上線對于我們來講都需要進(jìn)行鏈路機(jī)的壓測，當(dāng)時平均每周大概需要壓測2-3次，是鏈路級的。

同時由于我們的鏈路比較復(fù)雜，性能問題定位也是困難重重，對于我們來講時間就是生命，我們需要在一周的時間內(nèi)完成系統(tǒng)整體性能提高30%這個指標(biāo)，這個數(shù)據(jù)是怎么來的呢？就是我們業(yè)務(wù)增長最快的一段時間里，每周的業(yè)務(wù)增長量就是30%左右。雖然我們做了一些整體的大規(guī)模的優(yōu)化，來使我們的系統(tǒng)有一個質(zhì)的提高，但是每周依然需要對特定服務(wù)或者接口做一些特定的優(yōu)化。從設(shè)計再到開發(fā)，再到功能測試、到性能測試上線，我們只有一周的時間，這對于我們測試來講，就需要有很高的速度方面的要求。我們當(dāng)時給自己提出了一些指標(biāo)，我們需要在一天的時間里完成數(shù)百個接口的準(zhǔn)備工作，比如，當(dāng)天提出了壓測需求，當(dāng)晚就要完成一個壓測的實(shí)施。同時，當(dāng)天壓測如果發(fā)現(xiàn)問題，我們要在當(dāng)晚就把這個問題做出一個初步的定位，因?yàn)槲覀円话闶窃谥芩幕蛘咧芪暹M(jìn)行壓測，如果當(dāng)天不定位，第二天就沒有時間修復(fù)，緊接著馬上就是高峰期了。

我們?nèi)绾慰焖俚臏?zhǔn)備呢？這個我會放在后面來說。

從2016年開始，我們對系統(tǒng)進(jìn)行例行的鏈路壓測，首先會統(tǒng)計周一高峰期的數(shù)據(jù)，然后確定下周的性能指標(biāo)及我們的優(yōu)化方向并進(jìn)行壓測實(shí)施，包括一些問題修復(fù)回歸，這是我們每周都在例行去做的。從最開始的人工準(zhǔn)備階段，到現(xiàn)在我們已經(jīng)可以通過平臺進(jìn)行自動化的壓測，包括自動周一拉取數(shù)據(jù)、生成腳本、如果有問題我們自動停掉、沒有問題或者發(fā)現(xiàn)什么問題自動生成報告，第二天研發(fā)和測試的同學(xué)來了直接分析就好，后面我會再具體介紹。

對于我們的平臺來講，主要的目的無非是提高我們的壓測數(shù)據(jù)和腳本準(zhǔn)備上的效率以及壓測結(jié)果分析的效率。所以我們主要分為三塊，首先壓測準(zhǔn)備，主要是壓測腳本和數(shù)據(jù)的準(zhǔn)備。對于腳本來講，我們希望壓測的比例可以和線上高峰期實(shí)際接口請求比例是一致的，同樣我們可以通過簡單的配置對系統(tǒng)壓力進(jìn)行等比的增減。對于一些不想要壓測的接口可以支持將它過濾掉。而數(shù)據(jù)方面，我們希望壓測數(shù)據(jù)有足夠高的復(fù)雜度和樣本量，同時我們又希望壓測過程中不要影響到線上的真實(shí)用戶。目前我們是通過拉取線上NG日志的方式，高峰期時間段、接口請求狀況、響應(yīng)時間、請求量等等，計算我們分給每個接口的新增數(shù)是多少，以此來生成我們的壓測腳本，數(shù)據(jù)同樣是用高峰期實(shí)際用戶請求數(shù)據(jù)并對這些流量進(jìn)行打標(biāo)，在保證我們盡可能模擬線上真實(shí)情況的同時，也不影響到線上真實(shí)用戶的使用。

結(jié)果分析這部分也是在壓測過程中一個老大難的問題，比如，一次壓測出現(xiàn)了一個問題，研發(fā)可能會先去NG日志或者是sever日志去查，有各個監(jiān)控平臺，CPU、數(shù)據(jù)庫等等，這些數(shù)據(jù)明明我們都有，但是排查起來對于一線開發(fā)或者測試來講常常會不知道如何入手。

我們的壓測平臺會把所有和本次壓測相關(guān)的數(shù)據(jù)全部匯總起來，通過平臺進(jìn)行分析，然后給出一個定位的結(jié)論，我們收集的數(shù)據(jù)不僅有本次壓測的，還包括往期、線上高峰期的數(shù)據(jù)，一是看本次有沒有異常，第二也通過對比的方式更精準(zhǔn)的定位系統(tǒng)鏈路上的問題。打個比方，比如，整個系統(tǒng)需要承載的壓力是10萬qps，其中一個接口線上要求它到1000，實(shí)際上到500的時候可能就不行了，這種問題常常在我們的鏈路壓測過程中十分難暴露出來，因?yàn)樗鼘ξ覀兿到y(tǒng)整體的影響太小了，我們根本就看不出來，但是通過平臺可以很快的通過分析，本次數(shù)據(jù)的接口響應(yīng)時間或者是預(yù)期QPS和實(shí)際QPS把這一塊的結(jié)果定位出來，這只是其中一種，還包括主機(jī)上面的問題等等，我們的報告不光體現(xiàn)出壓測結(jié)果，更重要的是可以把這次出現(xiàn)的問題抽離或者壓測出來，輔助我們快速的定位。

再一個很重要的點(diǎn)是監(jiān)控，目前運(yùn)維的監(jiān)控平臺是基于grafana做的，優(yōu)點(diǎn)是擴(kuò)展性、兼容性比較強(qiáng)，可以添加各種類型的監(jiān)控，但是缺點(diǎn)是它的入口成本或者添加成本比較高，往往要加一個鏈路級的監(jiān)控，會花費(fèi)很長的時間，如果改動的話還要讓運(yùn)維提供，需要他們操作，因?yàn)橐痪€人員具備操作這個東西的能力。對于我們壓測來講，其實(shí)我們并不需要一個監(jiān)控平臺有如此好的擴(kuò)展性，我們更期望的是可以通過一個簡單的配置就能快速的把我們的數(shù)據(jù)大盤給生成出來，方便我們定位就行了，我們每次關(guān)注的點(diǎn)并不會有什么變化，比如主機(jī)，就看看cpu、load等等這些值。所以，我們目前的做法是按照目前監(jiān)控的類型，只要把你的服務(wù)名還有它的類型填好就可以快速的生成大盤。

另外一點(diǎn)，就是我們平常所加的監(jiān)控可能在壓測過程中不一定完全適用，比如平常主機(jī)、CPU設(shè)成70%就需要報警，因?yàn)槲艺J(rèn)為這可能是代表流量異常的情況，但是壓測過程中可能就把這個數(shù)值輕松打破掉了。然后每次的鏈路壓測都會收到大量的無用的報警，其實(shí)報警多了和沒有報警就沒有什么區(qū)別，沒有人會看所有的報警內(nèi)容。這樣一些很嚴(yán)重的問題往往就會被掩蓋掉了，所以在我們的監(jiān)控平臺里面會單獨(dú)把這部分監(jiān)控給抽離出來，也就是說每次開啟壓測這部分監(jiān)控才會啟動，這部分監(jiān)控又分為報警監(jiān)控、停止監(jiān)控，這也是我們做自動化壓測的一個基礎(chǔ)。比如，我們達(dá)到某一個閾值，我們認(rèn)為需要報警通知、需要排查問題。然后到服務(wù)器承載不了的時候會自動把它停掉。

如圖，這是我們平臺設(shè)計的圖，主要分為四個部分，一個任務(wù)調(diào)度處理模塊主要負(fù)責(zé)各模塊之間的調(diào)度任務(wù)，包括壓測啟停、監(jiān)控開關(guān)等等。壓測這塊主要是接口還有數(shù)據(jù)方向上的準(zhǔn)備，監(jiān)控和報告服務(wù)就是剛才說的開啟監(jiān)控、停止減虧等等，還有生成報告的服務(wù)。數(shù)據(jù)來源主要有兩個，一個是運(yùn)維的監(jiān)控平臺，這塊主要負(fù)責(zé)拿取各種的像主機(jī)、DB、還有一些信息，elk是日志平臺，通過它拉取流量也可以根據(jù)線上流量情況進(jìn)行數(shù)據(jù)的分析。

下面是我們平臺使用的界面，首先，會先配置一下需要壓哪個域名、哪個時間段的、總的Qps期望是多少，再就是添加一個監(jiān)控，包括各個監(jiān)控閾值。這些添加好之后，我們一鍵開始，剩下的工作全是平臺來代替我們?nèi)ド赡_本、去運(yùn)行、去監(jiān)控、去報告分析。

我們的報告維度也是比較多的，包括按域名維度、主機(jī)維度、接口維度的，還有一些下游接口的報告，看這個接口它下游的響應(yīng)情況等等。如圖，這是我們監(jiān)控的快照，包括主機(jī)、數(shù)據(jù)庫這四部分。這是我們結(jié)果分析的報告頁，首先我們會把一些錯誤率比較高、響應(yīng)時間比較長的一些接口拿出來，可以看它的問題點(diǎn)，點(diǎn)進(jìn)去可以看它的單個接口，下游或者本層的響應(yīng)情況。右邊是Qps和RT的曲線，現(xiàn)在大部分的壓測工具生成報告只有最高Qps、平均Qps、平均RT這樣的數(shù)據(jù)，但是中間出現(xiàn)服務(wù)的抖動這種情況是看不到的，這種往往代表服務(wù)出現(xiàn)了一些問題，比如一次壓測結(jié)果拿了監(jiān)測值，當(dāng)我們用線上的量去評估，可能往往帶來的是一些誤區(qū)。我們的報告里可以看到本次壓測實(shí)際每秒的響應(yīng)時間的情況和Qps情況，分為按服務(wù)級別、按域名級別、按接口級別的。

這是我們一個下游API的調(diào)用情況，比如，一次壓測出現(xiàn)了，某個接口出現(xiàn)問題我們可以看它下游的情況是什么樣的，可以把下游的異常接口抽離出來并代碼級定位是在上游服務(wù)得哪行調(diào)用，和往期比，響應(yīng)時間增加了，錯誤率高了等等這種情況，我們是通過重新封裝組件來達(dá)到這一功能的。

下面來分享一個壓測過程中的實(shí)際案例，對于一個讓我們性能下降30%的性能問題，我們在10分鐘內(nèi)完成了鏈路問題的定位，并且修復(fù)上線了，當(dāng)時情況是這樣的，一次例行壓測發(fā)現(xiàn)我們系統(tǒng)的總Qps下降了30%左右，而且當(dāng)時已經(jīng)沒有一個很大規(guī)模的代碼改動，頂多是一些業(yè)務(wù)上的需求上線，我們的自動化平臺會第一時間定位出我們網(wǎng)絡(luò)服務(wù)是入口IO有異常，入口IO已經(jīng)基本上打滿了，同時接口報告里發(fā)現(xiàn)是某一個下游接口響應(yīng)時間較以往有一個很大的增長，我們可以看到這個接口的下游報告里面，下游調(diào)用的某一個接口也是響應(yīng)時間急劇增加，我們還定位到了接口的調(diào)用位置，當(dāng)時直接去那行代碼發(fā)現(xiàn)這個確實(shí)是我們本周上線的，當(dāng)時的情況是多取了一個無用的數(shù)據(jù)，可能是列表型接口，直接把詳情數(shù)據(jù)取出來了，因?yàn)閿?shù)據(jù)量比較大，直接把服務(wù)器的IO打滿了，我們當(dāng)時把這個無用字段刪除掉了，然后再重新驗(yàn)證，符合預(yù)期。

這種問題其實(shí)如果是人工調(diào)查可能周期就會比較長，因?yàn)橄窬W(wǎng)絡(luò)入口IO打滿這種問題，會導(dǎo)致所有的接口響應(yīng)時間都會增長，在NG層查load來講，每個接口響應(yīng)時間都增長了，根本很難區(qū)分或者很難定位。

我們用平臺不管在數(shù)據(jù)準(zhǔn)備還有結(jié)果定位上都大大縮減了人力還有時間，可能會有人問，我們做一個平臺什么時候做合適或者應(yīng)不應(yīng)該做？我認(rèn)為對于咱們各個業(yè)務(wù)來講，可能不一樣，不一定每個公司都需要一個這樣的平臺。比如，你們的壓測場景是單接口壓測或者單服務(wù)，定位問題比較簡單，或者用jmeter做這件事不一定比一個平臺做這件事差到哪兒去，我感覺效果有可能是一樣的，但是比如我們這種頻繁的重復(fù)化的壓測需求可能是比較適用的場景，對于測試開發(fā)工程師，最重要的不是為了開發(fā)而開發(fā)，而是要發(fā)現(xiàn)工作過程中遇到的痛點(diǎn)問題，把那些可以重復(fù)化的或者可以用機(jī)器取代的工作通過技術(shù)手段替代掉，這才是我們主要的工作方向。

希望這次的分享可以給大家?guī)硪恍椭?/p>