随着移動開發行業的步入存量時代，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 請求特有的資料加密方式建構請求中比較複雜的部分。客戶側已有的測試方案不能覆寫這部分能力，是以往往選擇關閉網關服務端驗簽和加密功能實施壓測。
這種方式的隐患在于無法估計加解密給網關伺服器帶來的計算壓力。
根據經驗，不同的加解密算法配置，對網關的吞吐量有 20% ~ 40% 影響。在此階段，由金融線 SRE 團隊基于使用者生産環境定制開發的 JMeter 插件 MGSJMeterExt，該插件逆向實作了請求體的加密和解密過程，使得壓測腳本的編排可以包括加密部分。
難點3 請求簽名建構
mPaaS 移動網關 RPC 請求特有的簽名校驗機制也比較特殊。同資料加解密一樣，目前客戶側無方案可覆寫這部分能力，往往選擇關閉接口驗簽進行測試。同樣借助 MGSJMeterExt，可以實作在 JMeter 中實作對封包的正确簽名，并通過服務端校驗。
難點4 壓測叢集環境部署
對于壓測來說，需要的重點側重于真實，真實的流量入口，真實的并發數量，才能得出真實的結果，而自行實作壓測環境，高昂的叢集部署費用，也成了不必要的開支.
因而我們推薦使用者采用阿裡雲 PTS 作為壓測平台，基于其他方案，具有部署簡易，支援 Jmeter 腳本，流量真實等優勢，也可為使用者提供更為詳實的壓測報告。
概覽
以上模型簡單可以歸納為以下結構
在前期階段，目标是為了為實際的壓測提供相關的準備和資料支撐，确立壓測目标和整體方向。
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：壓力測試本身即是為了明确在相關的系統資源下，可以達到的性能名額，由于服務端的架構不同，實際業務涉及的流程節點不同，不同環境下的性能存在着巨大的差異，這些即是使用壓力測試的目的，需要通過壓測才能明确真實的名額和評估各個節點的實際資源耗時。
我們歸納出了 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 回參的二次處理
大緻的步驟可歸納為：
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 擴容完成後可實作大幅的性能提升，調優的結果遠超預期。
本文作者：阿裡雲 mPaaS TAM 團隊（王澤康，北默，東雷，榮陽）
END