前言
前幾天還在北京出差時候，微信群有個同學問了一個問題，為什么800並發壓測，服務器還沒有報錯？當時群里其他同學提了很多觀點，比如：
- 並發不夠，加並發！
- 要不要考慮首頁進來多少人？
- 是不是有限流，流量都被攔截了？
- 我看CPU都打滿了，壓測要關注硬件指標！
- 是不是你壓測機配置比較低，無法發起這么多並發？
- ............
林林總總感覺說了很多，又感覺都沒說到位。正好周四時候，從同事那里聽到一個性能需求，說來也蠻有意思的，需求大致是這樣：
網關要驗證在跨可用區情況下，支撐20W的TPS。就這一句話，我當時有點詫異（因為以我對我們公司目前業務及技術架構的理解，根本不需要20W的TPS）。
那么，問題來了：如果是你，聽到這樣的“一句話需求”，你會如何評估分析，然后制定壓測方案呢？
這篇文章，聊聊我對這個需求的一些理解和分析，以及我會如何設計性能測試方案。
需求評估分析
先來聊聊如何分析這個性能需求，關於性能需求分析，我總結下面幾點roadmap：
接下來，按照上述思維導圖，我會通過幾個不同問題的解答，來描述我的分析思路。
誰提的需求，目的是什么？
流量網關的研發同學提了一個性能測試需求：網關要驗證在跨可用區情況下，支撐20W的TPS。
做個關鍵字提取：流量網關、跨可用區、20W的TPS。
什么是流量網關？
簡單來說，流量網關就是所有請求的流量入口，承載了所有用戶請求。如下圖所示：
如何理解跨可用區？
一般來說，雲服務的可用區，可以理解為同一個機房的不同虛擬機集群。
為了避免某個可用區由於網絡硬盤等原因損壞導致服務不可用，跨可用區的服務部署是一種常見的容災手段。
流量網關有什么特點？
負載均衡：跨多個服務的動態負載均衡；
身份驗證：即用戶的身份鑒權，登錄態、黑白名單等；
限流限速：基於速率、請求數、並發等維度進行流控；
其他特點：加解密、A/B測試、灰度發布、監控告警、服務治理等功能；
壓測流量網關有什么難點？
網關是用戶請求流量的入口，因此訪問壓力會很大，即我們常說的QPS很高。那么在壓測時，要考慮下面幾點：
- 需要能支撐發起很多並發請求的工具；
- 網關服務的應用需要部署集群，來應對高並發；
- 由於只是跨可用區，一般雲服務可控制在0.5ms以內；
在什么場景下為誰提供服務？
上面介紹了流量網關的特點，這里的場景指的是業務場景或者說測試場景，即：驗證網關的哪些功能場景下的性能表現。上述的網關特點中，一般需要壓測驗證的場景有鑒權、加解密、身份驗證。
目前系統架構調用關系是怎樣的？
做性能測試，最怕的是不了解系統架構就開始無腦高並發！
了解系統架構及服務間的調用關系，才能設計合理的壓測場景，准備對應的腳本和數據。
如何搭建滿足需求的性能測試環境？
根據上面的分析，跨可用區的網關應用集群，在搭建環境時，需要考慮的有下述幾點：
- 集群均勻分布在不同可用區；
- 網關應用的單機配置（比如8C16G）；
- 虛擬機型保持一致（內核版本、計算型/IO型）；
- 需要綁定專門的域名，SLB和帶寬需要大於預期的指標；
- 壓測工具需要盡可能的支撐更高的並發流量發起（比如Wrk）；
- 因為涉及到鑒權和身份驗證，需要提前預熱相關的auth、token數據到緩存；
如何評估性能需求的技術指標是否合理？
上面提到了性能指標是20W的TPS，那這個指標是否合理呢？
首先，性能需求的技術指標是否合理，要結合實際的業務場景和目前峰值流量及未來增長趨勢來綜合評估。
假設流量網關被所有業務接入，業務對RT比較敏感，業務請求RT的目標是10ms；目前的線上峰值QPS是5W-QPS，預計未來半年增長到10W的QPS。
那這個時候，如何評估技術指標，或者說設定合理的技術指標呢？我們可以結合實際情況討論，得到下面這樣的一個技術指標：
- ART&99RT：≤2ms；
- 安全水位下的QPS：≥10W；
- TPS：統計核心業務的核心鏈路當前吞吐能力，做聚合計算，保持一定上浮；
當然，上述的指標有個前提：業務不接受有損。
如果業務接受有損，那么性能的技術指標無須這么苛刻（因為可以限流降級）；
性能測試方案
說到了性能測試方案，我偶然翻出了19年6月份畫的一個性能測試流程職責說明表，見下圖：
聊到這里，該如何設計性能測試方案呢？答案已經在上述的需求分析里了。