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

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

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

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

大家好，我是VIPKID的寧浩然，很高興在這里給大家?guī)?lái)本次分享，我分享的主題是《千萬(wàn)級(jí)約課系統(tǒng)自動(dòng)化壓測(cè)實(shí)踐》。我會(huì)基于VIPKID的特點(diǎn)，分析我們?cè)阪溌穳簻y(cè)過(guò)程中遇到的問(wèn)題和挑戰(zhàn)有哪些，簡(jiǎn)單介紹一下開(kāi)發(fā)的自動(dòng)化壓測(cè)平臺(tái)是如何解決代碼級(jí)定位鏈路上的性能問(wèn)題，以及我們?nèi)绾胃以跓o(wú)人值守的情況下完成自動(dòng)化壓測(cè)。

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

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

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

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

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

我們?nèi)绾慰焖俚臏?zhǔn)備呢？這個(gè)我會(huì)放在后面來(lái)說(shuō)。

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

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

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

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

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

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

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

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

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

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

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

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

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

希望這次的分享可以給大家?guī)?lái)一些幫助。