業務背景

隨著移動開發行業的步入存量時代，App 整體架構的負載能力、以及各個環節的優化逐步成為各個開發者們關注的重點。

壓力測試就是實現以上功能的主要方案。一般可以基于壓力測試：

測試后端業務的負荷瓶頸；
評估整體架構性能；
業務穩定峰值；
排查出各節點的薄弱關系；
優化系統資源；
避免短板效應；
為運營提供準確的用戶承載量作為作證，避免活動/新應用的上線帶來的突發流量造成的用戶體驗不佳。

今天，我們將為大家介紹全鏈路壓測方案的是實現原理和實施路徑。

全鏈路壓測與原理

通常我們可以簡單的把負載性能=單機性能*機器總量這一公式套用到預估的方案中，但是在實際的場景下，常常會涉及到大量的業務節點，如DNS，網關，數據庫等環節，都有可能是導致整體業務性能的瓶頸，因而實際服務能力可能與預期存在較大誤差。

一般用戶會通過 loadrunner 等方案實現生產環境下的服務器性能壓力測試，但是在 mPaaS 應用中，復雜的部署無法通過 MGS 網關，高昂的費用等難點應運而生，為了解決這些痛點。

mPaaS 團隊這邊依據多位客戶的述求，提供出 MGS 全鏈路壓測方案。

區別于以往的測試方案，全鏈路壓測方案中最大的不同是視角上的不同，站在客戶端角度上作為切入點，將整個服務端鏈路作為一個黑盒，以真實的 request 和 response 作為評估的依據，模擬真實的業務請求，真實的數據流量，真實的用戶習慣，來達到得出盡可能真實的評估結果。

鏈路梳理

在一個標準的數據鏈路中，一般為以下模型

而在全鏈路壓測中，我們把整體的服務端實現視為一個黑盒，因而我們所需關注的焦點聚焦在前半段，重點可以概括為：

1.客戶端請求構建；

2.客戶端請求發送并通過 MGS 網關；

3.客戶端解析 MGS 網關返回的 response 并做出正確處理；

4.實現高并發的客戶端請求集群。

以上再次梳理，可以歸納出以下難點

難點1 客戶端請求構建

mPaaS 移動網關 RPC 通訊是在 HTTP 協議基礎之上的實現的一種標準化接口方式，在復用 HTTP 請求標準的前提下，定義了一套數據交換格式，采用Header，Body 作為實際區分，可以近似理解為，通過Header 中的Operation-Type做為真實api指向，將body部分依據規則封裝后進行轉發。

在該步驟中，我們以 JMeter 作為實現方案，Jmeter 靈活的腳本特性可以良好的實現客戶端的真實請求模擬。

難點2 數據加解密

mPaaS 移動網關 RPC 請求特有的數據加密方式構建請求中比較復雜的部分?？蛻魝纫延械臏y試方案不能覆蓋這部分能力，因此往往選擇關閉網關服務端驗簽和加密功能實施壓測。

這種方式的隱患在于無法估計加解密給網關服務器帶來的計算壓力。

根據經驗，不同的加解密算法配置，對網關的吞吐量有 20% ~ 40% 影響。在此階段，由金融線 SRE 團隊基于用戶生產環境定制開發的 JMeter 插件 MGSJMeterExt，該插件逆向實現了請求體的加密和解密過程，使得壓測腳本的編排可以包括加密部分。

難點3 請求簽名構建

mPaaS 移動網關 RPC 請求特有的簽名校驗機制也比較特殊。同數據加解密一樣，目前客戶側無方案可覆蓋這部分能力，往往選擇關閉接口驗簽進行測試。同樣借助 MGSJMeterExt，可以實現在 JMeter 中實現對報文的正確簽名，并通過服務端校驗。

難點4 壓測集群環境部署

對于壓測來說，需要的重點側重于真實，真實的流量入口，真實的并發數量，才能得出真實的結果，而自行實現壓測環境，高昂的集群部署費用，也成了不必要的開支.

因而我們推薦用戶采用阿里云 PTS 作為壓測平臺，基于其他方案，具有部署簡易，支持 Jmeter 腳本，流量真實等優勢，也可為用戶提供更為詳實的壓測報告。

概覽

以上模型簡單可以歸納為以下結構

全鏈路方案及實施

Part1 前期準備及調研

在前期階段，目標是為了為實際的壓測提供相關的準備和數據支撐，確立壓測目標和整體方向。

1.1 目標及數據準備

1.客戶需要明確自身的壓測目標和壓測目的，基于壓測目標，參照以往的運營數據，給出涉及到的具體業務類目和可能的用戶行為習慣，在整體的業務中各習慣所帶來的相關比重關系。

1.2 客戶端準備

1.客戶端這邊需要依據相應的業務目標，整理出在客戶端實現中可能涉及到的接口和數據流程，如是否包含前置步驟，如登陸等，是否包含強制的步驟，如首頁的刷新等，通過抓包等收集該步驟中真實的 request 和 response，以及確定符合預期的值條件。

2.該步驟涉及業務結構的不同，亦可由服務端接口端完成該準備。

1.3 服務端準備

1.服務端這邊依據1.2中統計的相關接口，做好相關的數據擋板，避免導致測試數據污染真實數據庫。

2.由于在 mPaaS 全鏈路壓測中，服務端被視為黑盒，因而需要實現對于服務端各業務的性能指標的監控，為后期的服務端調優作為依據。

1.4 MGSJMeterExt 插件準備

由于 MGSJMeterExt 需要依據實際網關環境進行定制開發，需要用戶提供以下數據：

1.工作空間相關環境數據

2.加密算法和公鑰

Q&A答疑

Q：如何實現壓測腳本？

A：會由我們的專家團隊和現場同學完成簡單場景下的壓測腳本培訓，在實際的場景下，可能涉及到業務的多個環節，如登陸 token 的獲取，一些明確的前置步驟，這一類由于涉及到復雜的業務場景，需要客戶在阿里專家團隊的協助下自行完成。

Q：為什么是全鏈路的?

A：雖然我們的壓測腳本是基于客戶端邏輯實現的，但是我們實際上是模擬了真實的數據請求，也會確認服務端的返回是否達到預期，涉及到整個完整的數據鏈路及節點。

Q：鏈路的指標如何實現埋點?

A：壓測方案的對象是基于黑盒的，通過系統的 pts 指標，請求參數與返回的回報率，校驗符合預期結果的成功率，來確認基于用戶角度下的整個架構所能負載的性能，對于一些后端的指標，由于不同的客戶采用的服務端的架構存在不少的差異，對于后端這類指標，一般對應的服務商都能提供相關的監控方案，也無需 mPaaS 這邊進行處理。

Q：為什么使用 PTS?

A：mPaaS 團隊實際上提供的是 MGS 的通訊解決方案，協助客戶完成 PTS腳本的編寫，并不強制使用 PTS，只需要能提供相關的 Jmeter 集群部署環境即可，且 PTS 相關資源需要用戶自行采購，但目前 mPaaS 團隊基于多個案列評估，相對而言，使用 PTS，有更高的性價比，且能提供更為符合預期的壓測環境，完整的壓測報告，故推薦用戶使用 PTS 進行壓測。

Q：有沒有什么詳細的標準，如2c4g情況下，或者4c8g下，應該達到怎樣的性能指標?

A：壓力測試本身即是為了明確在相關的系統資源下，可以達到的性能指標，由于服務端的架構不同，實際業務涉及的流程節點不同，不同環境下的性能存在著巨大的差異，這些即是使用壓力測試的目的，需要通過壓測才能明確真實的指標和評估各個節點的實際資源耗時。

Part2 Jmeter開發與腳本改造

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

2.1 Header 改造

在 Header 中，我們需要注意以下幾點：

1.MGS 網關協議是依賴于一些 Header 字段的，因而需要確保網關參數齊全。

2.部分參數為固定值，可直接寫死，相關的配置可以參考控制臺下載的配置文件。

3.如業務有其他的 Header 依賴如 cookide 等業務上需要使用，也可直接添加，MGS 網關不會對 Header 信息進行過濾。

2.2 Url改造

在 URL 中，我們需要注意以下幾點：

1.URL 的實際指向應為 MGS 網關，而非實際的業務服務器，相關的配置可以參考控制臺下載的配置文件。

2.目前所有到 MGS 網關的請求均為 post，如有 get 請求，也是由 MGS 進行轉發時變為 get 的，在與 MGS 的通訊中也為 post。

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

2.3 Request改造

在 Request 中，我們需要注意以下幾點：

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

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

3.下述部分一般為統一方案，主要為了實現加密和驗簽，無需修改。

2.4 Response改造

在 Response 中，我們需要注意以下幾點：

1.在這里考慮到施壓機性能，不會影響到服務端的評估能力，因此若無數據二次使用需求，或結果判斷需求，這里可不寫

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

Part3 實際壓測

大致的步驟可歸納為：

3.1 PTS 及腳本性能調優

阿里云性能測試服務（PTS）提供了方便快捷的云端壓測能力，在本次壓測服務中，借助 PTS 實現互聯網壓力流量的輸入。

有意思的點在于，加解密計算不僅給網關帶來計算壓力，也會給施壓機帶來了一定的計算壓力。因此，第一個版本的插件和壓測腳本在實施前，我們首先進行了針對試壓機進行了的“壓力測試”。

第一輪基礎測試

PTS 試壓機配置：

1.PTS 單 IP 單元配置

2.并發數 500（單機最高并發）

3.固定壓力值流量模型

4.兩分鐘壓測時常

從回收的壓測報告看，TPS 結果并不高，但返回 RT 值并不高：

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

通過對重復內容加密結果的緩存，大幅降低了計算壓力；同時，為了避免緩存設計引起內存問題，對緩存上限進行了限制。

第二輪測試

與第一輪的測試配置完全相同，僅更換了優化后的加密插件。從回收的測試報告看，場景 TPS 有 75% 的提升：

從施壓機 CPU 性能看有一個明顯的優化。

第三輪測試

有了第一輪的摸底和第二輪的優化情況，第三輪測試在配置上使用兩臺施壓機滿負荷進行壓測，觀察壓測結果：

從結果看，壓測腳本和編排過程符合預期，可以在客戶生產環境進行正式的 PTS 云端壓測。

3.2 生產環境壓測摸底

在正式壓力測試開始，進行了若干輪小規模的壓力測試，觀察后端系統的工作狀態是否符合預期。摸底期間發現如下問題：

問題一：Nginx流量轉發不均

從MGS容器的日志表現上看，部分容器始終獲取不到任何請求，經過排查發現該問題由三個原因導致：

1）DMZ區Nginx轉發配置少配了一個MGS容器IP；

2）DMZ區到每一個MGS容器IP的網絡策略均需要開通訪問權限；

3）Nginx轉發規則設置為iphash，在單IP來源的測試情況，流量僅能轉發到一個容器上。

配置了正確的IP列表、開通了網絡權限以及修改轉發規則后，該問題得到解決。

問題二：特定 MGS 容器基礎 CPU 負載過高

前期測試發現，有一臺 MGS 容器（mpaasgw-7）在靜默狀態下的 CPU 負載在25%，不符合預期。

登錄容器發現存在一個 JPS 進程，消耗了大量的 CPU。懷疑是前期調測階段調用后未正常釋放。殺掉JPS進程后問題解決，為了避免其他問題，一并重啟了該容器

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

問題三：CoreWatch 監控平臺無法訪問

CoreWatch 控制臺無法訪問，瀏覽器中報 502 錯誤。重啟 CoreWatch 容器后，頁面可以加載，但始終處于加載中狀態。

http://corewatch.*.com/xflush/env.js 一直處于pending狀態。排查發現 ALB 實例監聽配置存在錯誤，修正后問題得到解決。

3.3 生產環境壓力測試&總結

在解決了 3.2 中的所有問題后，系統具備了壓力測試的條件，正式壓測會針對“加密場景”和“非加密”場景分別做壓力測試。

由于生產數據不做外泄，以下僅對遇到的問題進行一些例舉。

“加密”情況下測試

1.壓測時發現在并發數 500 左右即出現 TPS 不做增長，代表著可能到達了瓶頸。

2.觀察 MGS 網關容器的負載情況，整體 CPU 負載達到極限。

3.同一時間段的 MCUBE 容器 CPU 負載情況健康，其他性能指標（IO、網絡等）也處于健康狀態。

4.從上述情況看，加密場景下，主要性能瓶頸在 MGS 網關上，根據經驗及流程分析，主要性能壓力由報文加解密過程中的密集計算所帶來。要解決這一瓶頸，需要對 MGS 容器進行擴容。

“不加密”情況下的測試

1.TPS 的增長在并發達到 1000 左右時停止增長。一般情況下，這種情況說明觸及了系統容量的瓶頸。

2.觀察 MGS 網關容器的負載情況，與加密情況下的情況不同，此時整體 CPU 負載均不高。

3.與此同時，根據網絡組的反饋：壓測期間互聯網到 DMZ 區的 TCP Session數量是 DMZ 區到內網區的3~4倍，交易內網段的防火墻 CPU 壓力較高。

4.結合上述三種表現，懷疑觸及網絡層面瓶頸。根據現場情況發現，DMZ 區 Nginx 轉發到內網時沒有采取長連接保持策略。修改Nginx配置，添加keepalive 1000配置，重新進行第二輪測試。

關于參數Keepalive說明：默認情況下，Nginx訪問后端都是用的短連接（HTTP1.0），每一個新的請求，Nginx 都會新開一個端口和后端建立連接，后端執行完畢后主動關閉該鏈接。Keepalive參數會告知Nginx和后端服務器之間緩存的長連接數量，當新的請求進來時，可直接復用TCP連接，減少建立TCP連接所帶來的性能影響。參見：http://nginx.org/en/docs/http/ngx_http_upstream_module.html。

總結

在上述問題優化后，非加密場景下至少有 70% 的性能提升，加密場景下 10%的性能提升，并在 MGS 擴容完成后可實現大幅的性能提升，調優的結果遠超預期。