業(yè)務(wù)背景

隨著移動(dòng)開發(fā)行業(yè)的步入存量時(shí)代，App 整體架構(gòu)的負(fù)載能力、以及各個(gè)環(huán)節(jié)的優(yōu)化逐步成為各個(gè)開發(fā)者們關(guān)注的重點(diǎn)。

壓力測(cè)試就是實(shí)現(xiàn)以上功能的主要方案。一般可以基于壓力測(cè)試：

測(cè)試后端業(yè)務(wù)的負(fù)荷瓶頸；
評(píng)估整體架構(gòu)性能；
業(yè)務(wù)穩(wěn)定峰值；
排查出各節(jié)點(diǎn)的薄弱關(guān)系；
優(yōu)化系統(tǒng)資源；
避免短板效應(yīng)；
為運(yùn)營(yíng)提供準(zhǔn)確的用戶承載量作為作證，避免活動(dòng)/新應(yīng)用的上線帶來的突發(fā)流量造成的用戶體驗(yàn)不佳。

今天，我們將為大家介紹全鏈路壓測(cè)方案的是實(shí)現(xiàn)原理和實(shí)施路徑。

全鏈路壓測(cè)與原理

通常我們可以簡(jiǎn)單的把負(fù)載性能=單機(jī)性能*機(jī)器總量這一公式套用到預(yù)估的方案中，但是在實(shí)際的場(chǎng)景下，常常會(huì)涉及到大量的業(yè)務(wù)節(jié)點(diǎn)，如DNS，網(wǎng)關(guān)，數(shù)據(jù)庫等環(huán)節(jié)，都有可能是導(dǎo)致整體業(yè)務(wù)性能的瓶頸，因而實(shí)際服務(wù)能力可能與預(yù)期存在較大誤差。

一般用戶會(huì)通過 loadrunner 等方案實(shí)現(xiàn)生產(chǎn)環(huán)境下的服務(wù)器性能壓力測(cè)試，但是在 mPaaS 應(yīng)用中，復(fù)雜的部署無法通過 MGS 網(wǎng)關(guān)，高昂的費(fèi)用等難點(diǎn)應(yīng)運(yùn)而生，為了解決這些痛點(diǎn)。

mPaaS 團(tuán)隊(duì)這邊依據(jù)多位客戶的述求，提供出 MGS 全鏈路壓測(cè)方案。

區(qū)別于以往的測(cè)試方案，全鏈路壓測(cè)方案中最大的不同是視角上的不同，站在客戶端角度上作為切入點(diǎn)，將整個(gè)服務(wù)端鏈路作為一個(gè)黑盒，以真實(shí)的 request 和 response 作為評(píng)估的依據(jù)，模擬真實(shí)的業(yè)務(wù)請(qǐng)求，真實(shí)的數(shù)據(jù)流量，真實(shí)的用戶習(xí)慣，來達(dá)到得出盡可能真實(shí)的評(píng)估結(jié)果。

鏈路梳理

在一個(gè)標(biāo)準(zhǔn)的數(shù)據(jù)鏈路中，一般為以下模型

而在全鏈路壓測(cè)中，我們把整體的服務(wù)端實(shí)現(xiàn)視為一個(gè)黑盒，因而我們所需關(guān)注的焦點(diǎn)聚焦在前半段，重點(diǎn)可以概括為：

1.客戶端請(qǐng)求構(gòu)建；

2.客戶端請(qǐng)求發(fā)送并通過 MGS 網(wǎng)關(guān)；

3.客戶端解析 MGS 網(wǎng)關(guān)返回的 response 并做出正確處理；

4.實(shí)現(xiàn)高并發(fā)的客戶端請(qǐng)求集群。

以上再次梳理，可以歸納出以下難點(diǎn)

難點(diǎn)1 客戶端請(qǐng)求構(gòu)建

mPaaS 移動(dòng)網(wǎng)關(guān) RPC 通訊是在 HTTP 協(xié)議基礎(chǔ)之上的實(shí)現(xiàn)的一種標(biāo)準(zhǔn)化接口方式，在復(fù)用 HTTP 請(qǐng)求標(biāo)準(zhǔn)的前提下，定義了一套數(shù)據(jù)交換格式，采用Header，Body 作為實(shí)際區(qū)分，可以近似理解為，通過Header 中的Operation-Type做為真實(shí)api指向，將body部分依據(jù)規(guī)則封裝后進(jìn)行轉(zhuǎn)發(fā)。

在該步驟中，我們以 JMeter 作為實(shí)現(xiàn)方案，Jmeter 靈活的腳本特性可以良好的實(shí)現(xiàn)客戶端的真實(shí)請(qǐng)求模擬。

難點(diǎn)2 數(shù)據(jù)加解密

mPaaS 移動(dòng)網(wǎng)關(guān) RPC 請(qǐng)求特有的數(shù)據(jù)加密方式構(gòu)建請(qǐng)求中比較復(fù)雜的部分?？蛻魝?cè)已有的測(cè)試方案不能覆蓋這部分能力，因此往往選擇關(guān)閉網(wǎng)關(guān)服務(wù)端驗(yàn)簽和加密功能實(shí)施壓測(cè)。

這種方式的隱患在于無法估計(jì)加解密給網(wǎng)關(guān)服務(wù)器帶來的計(jì)算壓力。

根據(jù)經(jīng)驗(yàn)，不同的加解密算法配置，對(duì)網(wǎng)關(guān)的吞吐量有 20% ~ 40% 影響。在此階段，由金融線 SRE 團(tuán)隊(duì)基于用戶生產(chǎn)環(huán)境定制開發(fā)的 JMeter 插件 MGSJMeterExt，該插件逆向?qū)崿F(xiàn)了請(qǐng)求體的加密和解密過程，使得壓測(cè)腳本的編排可以包括加密部分。

難點(diǎn)3 請(qǐng)求簽名構(gòu)建

mPaaS 移動(dòng)網(wǎng)關(guān) RPC 請(qǐng)求特有的簽名校驗(yàn)機(jī)制也比較特殊。同數(shù)據(jù)加解密一樣，目前客戶側(cè)無方案可覆蓋這部分能力，往往選擇關(guān)閉接口驗(yàn)簽進(jìn)行測(cè)試。同樣借助 MGSJMeterExt，可以實(shí)現(xiàn)在 JMeter 中實(shí)現(xiàn)對(duì)報(bào)文的正確簽名，并通過服務(wù)端校驗(yàn)。

難點(diǎn)4 壓測(cè)集群環(huán)境部署

對(duì)于壓測(cè)來說，需要的重點(diǎn)側(cè)重于真實(shí)，真實(shí)的流量入口，真實(shí)的并發(fā)數(shù)量，才能得出真實(shí)的結(jié)果，而自行實(shí)現(xiàn)壓測(cè)環(huán)境，高昂的集群部署費(fèi)用，也成了不必要的開支.

因而我們推薦用戶采用阿里云 PTS 作為壓測(cè)平臺(tái)，基于其他方案，具有部署簡(jiǎn)易，支持 Jmeter 腳本，流量真實(shí)等優(yōu)勢(shì)，也可為用戶提供更為詳實(shí)的壓測(cè)報(bào)告。

概覽

以上模型簡(jiǎn)單可以歸納為以下結(jié)構(gòu)

全鏈路方案及實(shí)施

Part1 前期準(zhǔn)備及調(diào)研

在前期階段，目標(biāo)是為了為實(shí)際的壓測(cè)提供相關(guān)的準(zhǔn)備和數(shù)據(jù)支撐，確立壓測(cè)目標(biāo)和整體方向。

1.1 目標(biāo)及數(shù)據(jù)準(zhǔn)備

1.客戶需要明確自身的壓測(cè)目標(biāo)和壓測(cè)目的，基于壓測(cè)目標(biāo)，參照以往的運(yùn)營(yíng)數(shù)據(jù)，給出涉及到的具體業(yè)務(wù)類目和可能的用戶行為習(xí)慣，在整體的業(yè)務(wù)中各習(xí)慣所帶來的相關(guān)比重關(guān)系。

1.2 客戶端準(zhǔn)備

1.客戶端這邊需要依據(jù)相應(yīng)的業(yè)務(wù)目標(biāo)，整理出在客戶端實(shí)現(xiàn)中可能涉及到的接口和數(shù)據(jù)流程，如是否包含前置步驟，如登陸等，是否包含強(qiáng)制的步驟，如首頁的刷新等，通過抓包等收集該步驟中真實(shí)的 request 和 response，以及確定符合預(yù)期的值條件。

2.該步驟涉及業(yè)務(wù)結(jié)構(gòu)的不同，亦可由服務(wù)端接口端完成該準(zhǔn)備。

1.3 服務(wù)端準(zhǔn)備

1.服務(wù)端這邊依據(jù)1.2中統(tǒng)計(jì)的相關(guān)接口，做好相關(guān)的數(shù)據(jù)擋板，避免導(dǎo)致測(cè)試數(shù)據(jù)污染真實(shí)數(shù)據(jù)庫。

2.由于在 mPaaS 全鏈路壓測(cè)中，服務(wù)端被視為黑盒，因而需要實(shí)現(xiàn)對(duì)于服務(wù)端各業(yè)務(wù)的性能指標(biāo)的監(jiān)控，為后期的服務(wù)端調(diào)優(yōu)作為依據(jù)。

1.4 MGSJMeterExt 插件準(zhǔn)備

由于 MGSJMeterExt 需要依據(jù)實(shí)際網(wǎng)關(guān)環(huán)境進(jìn)行定制開發(fā)，需要用戶提供以下數(shù)據(jù)：

1.工作空間相關(guān)環(huán)境數(shù)據(jù)

2.加密算法和公鑰

Q&A答疑

Q：如何實(shí)現(xiàn)壓測(cè)腳本？

A：會(huì)由我們的專家團(tuán)隊(duì)和現(xiàn)場(chǎng)同學(xué)完成簡(jiǎn)單場(chǎng)景下的壓測(cè)腳本培訓(xùn)，在實(shí)際的場(chǎng)景下，可能涉及到業(yè)務(wù)的多個(gè)環(huán)節(jié)，如登陸 token 的獲取，一些明確的前置步驟，這一類由于涉及到復(fù)雜的業(yè)務(wù)場(chǎng)景，需要客戶在阿里專家團(tuán)隊(duì)的協(xié)助下自行完成。

Q：為什么是全鏈路的?

A：雖然我們的壓測(cè)腳本是基于客戶端邏輯實(shí)現(xiàn)的，但是我們實(shí)際上是模擬了真實(shí)的數(shù)據(jù)請(qǐng)求，也會(huì)確認(rèn)服務(wù)端的返回是否達(dá)到預(yù)期，涉及到整個(gè)完整的數(shù)據(jù)鏈路及節(jié)點(diǎn)。

Q：鏈路的指標(biāo)如何實(shí)現(xiàn)埋點(diǎn)?

A：壓測(cè)方案的對(duì)象是基于黑盒的，通過系統(tǒng)的 pts 指標(biāo)，請(qǐng)求參數(shù)與返回的回報(bào)率，校驗(yàn)符合預(yù)期結(jié)果的成功率，來確認(rèn)基于用戶角度下的整個(gè)架構(gòu)所能負(fù)載的性能，對(duì)于一些后端的指標(biāo)，由于不同的客戶采用的服務(wù)端的架構(gòu)存在不少的差異，對(duì)于后端這類指標(biāo)，一般對(duì)應(yīng)的服務(wù)商都能提供相關(guān)的監(jiān)控方案，也無需 mPaaS 這邊進(jìn)行處理。

Q：為什么使用 PTS?

A：mPaaS 團(tuán)隊(duì)實(shí)際上提供的是 MGS 的通訊解決方案，協(xié)助客戶完成 PTS腳本的編寫，并不強(qiáng)制使用 PTS，只需要能提供相關(guān)的 Jmeter 集群部署環(huán)境即可，且 PTS 相關(guān)資源需要用戶自行采購，但目前 mPaaS 團(tuán)隊(duì)基于多個(gè)案列評(píng)估，相對(duì)而言，使用 PTS，有更高的性價(jià)比，且能提供更為符合預(yù)期的壓測(cè)環(huán)境，完整的壓測(cè)報(bào)告，故推薦用戶使用 PTS 進(jìn)行壓測(cè)。

Q：有沒有什么詳細(xì)的標(biāo)準(zhǔn)，如2c4g情況下，或者4c8g下，應(yīng)該達(dá)到怎樣的性能指標(biāo)?

A：壓力測(cè)試本身即是為了明確在相關(guān)的系統(tǒng)資源下，可以達(dá)到的性能指標(biāo)，由于服務(wù)端的架構(gòu)不同，實(shí)際業(yè)務(wù)涉及的流程節(jié)點(diǎn)不同，不同環(huán)境下的性能存在著巨大的差異，這些即是使用壓力測(cè)試的目的，需要通過壓測(cè)才能明確真實(shí)的指標(biāo)和評(píng)估各個(gè)節(jié)點(diǎn)的實(shí)際資源耗時(shí)。

Part2 Jmeter開發(fā)與腳本改造

我們歸納出了 MGS 通訊方案的特殊側(cè)重點(diǎn)，因而我們需要在 Jmeter 完成這幾點(diǎn)的改造

2.1 Header 改造

在 Header 中，我們需要注意以下幾點(diǎn)：

1.MGS 網(wǎng)關(guān)協(xié)議是依賴于一些 Header 字段的，因而需要確保網(wǎng)關(guān)參數(shù)齊全。

2.部分參數(shù)為固定值，可直接寫死，相關(guān)的配置可以參考控制臺(tái)下載的配置文件。

3.如業(yè)務(wù)有其他的 Header 依賴如 cookide 等業(yè)務(wù)上需要使用，也可直接添加，MGS 網(wǎng)關(guān)不會(huì)對(duì) Header 信息進(jìn)行過濾。

2.2 Url改造

在 URL 中，我們需要注意以下幾點(diǎn)：

1.URL 的實(shí)際指向應(yīng)為 MGS 網(wǎng)關(guān)，而非實(shí)際的業(yè)務(wù)服務(wù)器，相關(guān)的配置可以參考控制臺(tái)下載的配置文件。

2.目前所有到 MGS 網(wǎng)關(guān)的請(qǐng)求均為 post，如有 get 請(qǐng)求，也是由 MGS 進(jìn)行轉(zhuǎn)發(fā)時(shí)變?yōu)?get 的，在與 MGS 的通訊中也為 post。

3.Body 部分如無特殊需求建議如圖所示即可。

2.3 Request改造

在 Request 中，我們需要注意以下幾點(diǎn)：

1.這里的加密/驗(yàn)簽，依賴于 MGSJMeterExt 文件，需要引用該文件。

2.一般情況下僅需修改 //config 部分即可。

3.下述部分一般為統(tǒng)一方案，主要為了實(shí)現(xiàn)加密和驗(yàn)簽，無需修改。

2.4 Response改造

在 Response 中，我們需要注意以下幾點(diǎn)：

1.在這里考慮到施壓機(jī)性能，不會(huì)影響到服務(wù)端的評(píng)估能力，因此若無數(shù)據(jù)二次使用需求，或結(jié)果判斷需求，這里可不寫

2.如有相關(guān)需求，可在這里完成 Response 回參的二次處理

Part3 實(shí)際壓測(cè)

大致的步驟可歸納為：

3.1 PTS 及腳本性能調(diào)優(yōu)

阿里云性能測(cè)試服務(wù)（PTS）提供了方便快捷的云端壓測(cè)能力，在本次壓測(cè)服務(wù)中，借助 PTS 實(shí)現(xiàn)互聯(lián)網(wǎng)壓力流量的輸入。

有意思的點(diǎn)在于，加解密計(jì)算不僅給網(wǎng)關(guān)帶來計(jì)算壓力，也會(huì)給施壓機(jī)帶來了一定的計(jì)算壓力。因此，第一個(gè)版本的插件和壓測(cè)腳本在實(shí)施前，我們首先進(jìn)行了針對(duì)試壓機(jī)進(jìn)行了的“壓力測(cè)試”。

第一輪基礎(chǔ)測(cè)試

PTS 試壓機(jī)配置：

1.PTS 單 IP 單元配置

2.并發(fā)數(shù) 500（單機(jī)最高并發(fā)）

3.固定壓力值流量模型

4.兩分鐘壓測(cè)時(shí)常

從回收的壓測(cè)報(bào)告看，TPS 結(jié)果并不高，但返回 RT 值并不高：

接下來觀察施壓機(jī)的性能表現(xiàn)，可以看到施壓機(jī)的 CPU 使用率水位一直比較高，因此有理由懷疑加密計(jì)算壓力給施壓機(jī)的壓力釋放帶來比較大的影響。

通過對(duì)重復(fù)內(nèi)容加密結(jié)果的緩存，大幅降低了計(jì)算壓力；同時(shí)，為了避免緩存設(shè)計(jì)引起內(nèi)存問題，對(duì)緩存上限進(jìn)行了限制。

第二輪測(cè)試

與第一輪的測(cè)試配置完全相同，僅更換了優(yōu)化后的加密插件。從回收的測(cè)試報(bào)告看，場(chǎng)景 TPS 有 75% 的提升：

從施壓機(jī) CPU 性能看有一個(gè)明顯的優(yōu)化。

第三輪測(cè)試

有了第一輪的摸底和第二輪的優(yōu)化情況，第三輪測(cè)試在配置上使用兩臺(tái)施壓機(jī)滿負(fù)荷進(jìn)行壓測(cè)，觀察壓測(cè)結(jié)果：

從結(jié)果看，壓測(cè)腳本和編排過程符合預(yù)期，可以在客戶生產(chǎn)環(huán)境進(jìn)行正式的 PTS 云端壓測(cè)。

3.2 生產(chǎn)環(huán)境壓測(cè)摸底

在正式壓力測(cè)試開始，進(jìn)行了若干輪小規(guī)模的壓力測(cè)試，觀察后端系統(tǒng)的工作狀態(tài)是否符合預(yù)期。摸底期間發(fā)現(xiàn)如下問題：

問題一：Nginx流量轉(zhuǎn)發(fā)不均

從MGS容器的日志表現(xiàn)上看，部分容器始終獲取不到任何請(qǐng)求，經(jīng)過排查發(fā)現(xiàn)該問題由三個(gè)原因?qū)е拢?/p>

1）DMZ區(qū)Nginx轉(zhuǎn)發(fā)配置少配了一個(gè)MGS容器IP；

2）DMZ區(qū)到每一個(gè)MGS容器IP的網(wǎng)絡(luò)策略均需要開通訪問權(quán)限；

3）Nginx轉(zhuǎn)發(fā)規(guī)則設(shè)置為iphash，在單IP來源的測(cè)試情況，流量?jī)H能轉(zhuǎn)發(fā)到一個(gè)容器上。

配置了正確的IP列表、開通了網(wǎng)絡(luò)權(quán)限以及修改轉(zhuǎn)發(fā)規(guī)則后，該問題得到解決。

問題二：特定 MGS 容器基礎(chǔ) CPU 負(fù)載過高

前期測(cè)試發(fā)現(xiàn)，有一臺(tái) MGS 容器（mpaasgw-7）在靜默狀態(tài)下的 CPU 負(fù)載在25%，不符合預(yù)期。

登錄容器發(fā)現(xiàn)存在一個(gè) JPS 進(jìn)程，消耗了大量的 CPU。懷疑是前期調(diào)測(cè)階段調(diào)用后未正常釋放。殺掉JPS進(jìn)程后問題解決，為了避免其他問題，一并重啟了該容器

注：JPS, Java Virtual Machine Process Status Tool)，是java提供的一個(gè)顯示當(dāng)前所有java進(jìn)程pid的命令，參見：https://docs.oracle.com/javase/7/docs/technotes/tools/share/jps.html ）。

問題三：CoreWatch 監(jiān)控平臺(tái)無法訪問

CoreWatch 控制臺(tái)無法訪問，瀏覽器中報(bào) 502 錯(cuò)誤。重啟 CoreWatch 容器后，頁面可以加載，但始終處于加載中狀態(tài)。

http://corewatch.*.com/xflush/env.js 一直處于pending狀態(tài)。排查發(fā)現(xiàn) ALB 實(shí)例監(jiān)聽配置存在錯(cuò)誤，修正后問題得到解決。

3.3 生產(chǎn)環(huán)境壓力測(cè)試&總結(jié)

在解決了 3.2 中的所有問題后，系統(tǒng)具備了壓力測(cè)試的條件，正式壓測(cè)會(huì)針對(duì)“加密場(chǎng)景”和“非加密”場(chǎng)景分別做壓力測(cè)試。

由于生產(chǎn)數(shù)據(jù)不做外泄，以下僅對(duì)遇到的問題進(jìn)行一些例舉。

“加密”情況下測(cè)試

1.壓測(cè)時(shí)發(fā)現(xiàn)在并發(fā)數(shù) 500 左右即出現(xiàn) TPS 不做增長(zhǎng)，代表著可能到達(dá)了瓶頸。

2.觀察 MGS 網(wǎng)關(guān)容器的負(fù)載情況，整體 CPU 負(fù)載達(dá)到極限。

3.同一時(shí)間段的 MCUBE 容器 CPU 負(fù)載情況健康，其他性能指標(biāo)（IO、網(wǎng)絡(luò)等）也處于健康狀態(tài)。

4.從上述情況看，加密場(chǎng)景下，主要性能瓶頸在 MGS 網(wǎng)關(guān)上，根據(jù)經(jīng)驗(yàn)及流程分析，主要性能壓力由報(bào)文加解密過程中的密集計(jì)算所帶來。要解決這一瓶頸，需要對(duì) MGS 容器進(jìn)行擴(kuò)容。

“不加密”情況下的測(cè)試

1.TPS 的增長(zhǎng)在并發(fā)達(dá)到 1000 左右時(shí)停止增長(zhǎng)。一般情況下，這種情況說明觸及了系統(tǒng)容量的瓶頸。

2.觀察 MGS 網(wǎng)關(guān)容器的負(fù)載情況，與加密情況下的情況不同，此時(shí)整體 CPU 負(fù)載均不高。

3.與此同時(shí)，根據(jù)網(wǎng)絡(luò)組的反饋：壓測(cè)期間互聯(lián)網(wǎng)到 DMZ 區(qū)的 TCP Session數(shù)量是 DMZ 區(qū)到內(nèi)網(wǎng)區(qū)的3~4倍，交易內(nèi)網(wǎng)段的防火墻 CPU 壓力較高。

4.結(jié)合上述三種表現(xiàn)，懷疑觸及網(wǎng)絡(luò)層面瓶頸。根據(jù)現(xiàn)場(chǎng)情況發(fā)現(xiàn)，DMZ 區(qū) Nginx 轉(zhuǎn)發(fā)到內(nèi)網(wǎng)時(shí)沒有采取長(zhǎng)連接保持策略。修改Nginx配置，添加keepalive 1000配置，重新進(jìn)行第二輪測(cè)試。

關(guān)于參數(shù)Keepalive說明：默認(rèn)情況下，Nginx訪問后端都是用的短連接（HTTP1.0），每一個(gè)新的請(qǐng)求，Nginx 都會(huì)新開一個(gè)端口和后端建立連接，后端執(zhí)行完畢后主動(dòng)關(guān)閉該鏈接。Keepalive參數(shù)會(huì)告知Nginx和后端服務(wù)器之間緩存的長(zhǎng)連接數(shù)量，當(dāng)新的請(qǐng)求進(jìn)來時(shí)，可直接復(fù)用TCP連接，減少建立TCP連接所帶來的性能影響。參見：http://nginx.org/en/docs/http/ngx_http_upstream_module.html。

總結(jié)

在上述問題優(yōu)化后，非加密場(chǎng)景下至少有 70% 的性能提升，加密場(chǎng)景下 10%的性能提升，并在 MGS 擴(kuò)容完成后可實(shí)現(xiàn)大幅的性能提升，調(diào)優(yōu)的結(jié)果遠(yuǎn)超預(yù)期。