7月底最後一個周日，我們品課學院線下性能提升班第二期算是正式開課，零基礎的學員不少，有測試管理經驗、多年開發或者測試經驗的人員也有幾位，但是各個都很上進好學，不是因為學習而學習，而是有共同理想而走在一個教室，交流探討專業知識。他們謙虛且上進、因為他們知道做著沒有累積性的工作，卻期望老板替你加薪？做得久也未必能領得多，一切以實力見真章，所以他們珍惜每一堂課，認真筆記，發散性的問問題，無論功能測試、測試管理、行業知識、架構設計、軟硬件知識等等，的確很考驗老師的知識面和實戰經驗。

不同期的學生，不同階段的學習提升中，學生問的問淺題深不一，深廣度不同、天南地北都有，確實很有趣，在教學交流中也提升豐富我的知識體系，也會有碰到一些問題，我在平常工作中不會考慮那麽完善，也有因知識面出現缺漏，讓我課後彌補，讓我逐漸完善我的管理體系和各類領域專業知識，並運用到實際項目工作中，例如第二節課就有學生問道數據庫表設計中

本章介紹的是系統流量控制或者說限流，也是在課堂中一個學生問到一個問題，個人覺得值得探討，因為該問題在2012年的時候，我曾測試過一個國有大行大型項目，該系統流程復雜、規則校驗多、數據量龐大、並發用戶數多且集中並發度高，客戶的要求與項目運維運營技術問題，確實深有體會，加上互聯網交易時代，各種APP產品鋪天蓋地，各種營銷手段層出不窮，目的就是為了搶奪市場，搶奪用戶流量，這時我們無法使用正常手段進行評估系統用戶數，為了提高系統的可靠性、用戶體驗等，軟件開發會從不同架構設計角度，非功能性設計等來完善架構的性能，這也是微服務能慢慢風靡原因之一，通過微服務架構來提高系統在高並發下的高可用性、高可靠性等。

產品需流控背景

例如各種電商APP出現，確實對於未知的市場用戶數量在性能測試過程中確實很難預估將來在線用戶數、註冊用戶數、並發用戶數，甚至遊客查詢產品信息用戶等也會對服務產生壓力，這種確實很難估算，那我們如何做呢？

現在各類電商，美團、餓了嗎、淘寶、JD等在應對秒殺、大促、雙11、618等高並發性能壓力場景下，對服務端的流控已經成為硬性架構設計指標要求，目的是為了保證系統在高壓下能平穩運行起到高可用性、高可靠性作用。

其實很多對外接口服務也是一樣為了防止外來請求數據高於自己預估指標，會對外服務接口設置接口限流作用。特別是微服務系統，其接口請求可能來自很多外系統調用，對於這種海量接口請求的微服務，接口限流很重要。

應對哪些指標進行流量控制呢？

我們性能測試過程涉及的性能指標有吞吐率、TPS、HPS、並發用戶數這些技術性指標等都可以當作流控的指標，當然業務上的某些指標也可以，例如輸入驗證碼的時間限制、短信驗證碼輸入次數、機構用戶限制、JSF請求限制等。

一般情況下，對請求數就是HPS進行流控比較方便，因為該值可查、可控性也高，，通過性能壓力測試容易壓力與定位。

場景案例介紹

下面場景案例是本人在2012年時，協助國內一家比較大型的城商行對信貸系統進行流量控制驗證性測試介紹。

項目背景：

對某系統流量監控測試主要驗證在開啟監控工具進行穩定性測試對抓取響應超時的JSF與UCC時是否對系統內存等資源使用有影響；同時在開啟流量訪問數控制開關時針對系統並發一定數量的用戶數訪問特定的JSF、UCC是否進行功能性控制等驗證性測試。

測試目的：

流控用戶訪問限制性測試主要側重系統在並發一定用戶數下集合訪問某個業務交易點的壓力情況下，在增加用戶數時是否前端提示用戶數訪問限制信息提示。

測試策略：

主要測試策略，在對某一個UCC請求超過一定數量時，驗證是否彈出訪問量超過流量開關控制最大訪問提示信息。

測試結果：

在流量開啟設置好業務交易控制場景和性能測試場景後，設置瞬間並發下操作某一個業務UCC服務請求，當超越該請求時應該提示如下信息，確保系統受流控成功。

並在壓力測試過程檢查內存回收情況、服務器資源資源利用率、session會話回收情況，確保此時的會話數的正確性和回收率的準確。

而在loadrunner壓力測試場景中，也可以看到如下錯誤提示信息，說明流控在並發下功能的準確性。

以上場景是針對業務請求進行流量控制，算是業務流控、而一般微服務時代是技術接口、集群部署方式的這時流量監控可能復雜性更高，例如，對每一個接口服務的調用頻度而限制、調度頻率的設置等進行驗證下非功能性測試。

服務端性能保障之流量並發控制方法