服务端性能保障之流量控制测试方法

      7月底最后一个周日，我们品课学院线下性能提升班第二期算是正式开课，零基础的学员不少，有测试管理经验、多年开发或者测试经验的人员也有几位，但是各个都很上进好学，不是因为学习而学习，而是有共同理想而走在一个教室，交流探讨专业知识。他们谦虚且上进、因为他们知道做着没有累积性的工作，却期望老板替你加薪？做得久也未必能领得多，一切以实力见真章，所以他们珍惜每一堂课，认真笔记，发散性的问问题，无论功能测试、测试管理、行业知识、架构设计、软硬件知识等等，的确很考验老师的知识面和实战经验。

不同期的学生，不同阶段的学习提升中，学生问的问浅题深不一，深广度不同、天南地北都有，确实很有趣，在教学交流中也提升丰富我的知识体系，也会有碰到一些问题，我在平常工作中不会考虑那么完善，也有因知识面出现缺漏，让我课后弥补，让我逐渐完善我的管理体系和各类领域专业知识，并运用到实际项目工作中，例如第二节课就有学生问道数据库表设计中char、varchar在性能上的区别与用法、不同类型磁盘的性能影响、APP弱网测试、南方与北方无线网传输异常原因、数据库试图使用场景、并发数与在线数如何估算等等，不同的技术问答题，都有不同的论证方法，都能写成一篇技术文章。

本章介绍的是系统流量控制或者说限流，也是在课堂中一个学生问到一个问题，个人觉得值得探讨，因为该问题在2012年的时候，我曾测试过一个国有大行大型项目，该系统流程复杂、规则校验多、数据量庞大、并发用户数多且集中并发度高，客户的要求与项目运维运营技术问题，确实深有体会，加上互联网交易时代，各种APP产品铺天盖地，各种营销手段层出不穷，目的就是为了抢夺市场，抢夺用户流量，这时我们无法使用正常手段进行评估系统用户数，为了提高系统的可靠性、用户体验等，软件开发会从不同架构设计角度，非功能性设计等来完善架构的性能，这也是微服务能慢慢风靡原因之一，通过微服务架构来提高系统在高并发下的高可用性、高可靠性等。

  产品需流控背景

     例如各种电商APP出现，确实对于未知的市场用户数量在性能测试过程中确实很难预估将来在线用户数、注册用户数、并发用户数，甚至游客查询产品信息用户等也会对服务产生压力，这种确实很难估算，那我们如何做呢？

    现在各类电商，美团、饿了吗、淘宝、JD等在应对秒杀、大促、双11、618等高并发性能压力场景下，对服务端的流控已经成为硬性架构设计指标要求，目的是为了保证系统在高压下能平稳运行起到高可用性、高可靠性作用。

    其实很多对外接口服务也是一样为了防止外来请求数据高于自己预估指标，会对外服务接口设置接口限流作用。特别是微服务系统，其接口请求可能来自很多外系统调用，对于这种海量接口请求的微服务，接口限流很重要。

应对哪些指标进行流量控制呢？

我们性能测试过程涉及的性能指标有吞吐率、TPS、HPS、并发用户数这些技术性指标等都可以当作流控的指标，当然业务上的某些指标也可以，例如输入验证码的时间限制、短信验证码输入次数、机构用户限制、JSF请求限制等。

   一般情况下，对请求数就是HPS进行流控比较方便，因为该值可查、可控性也高，，通过性能压力测试容易压力与定位。

场景案例介绍

   下面场景案例是本人在2012年时，协助国内一家比较大型的城商行对信贷系统进行流量控制验证性测试介绍。

  项目背景：

对某系统流量监控测试主要验证在开启监控工具进行稳定性测试对抓取响应超时的JSF与UCC时是否对系统内存等资源使用有影响；同时在开启流量访问数控制开关时针对系统并发一定数量的用户数访问特定的JSF、UCC是否进行功能性控制等验证性测试。

测试目的：

流控用户访问限制性测试主要侧重系统在并发一定用户数下集合访问某个业务交易点的压力情况下，在增加用户数时是否前端提示用户数访问限制信息提示。

测试策略：

    主要测试策略，在对某一个UCC请求超过一定数量时，验证是否弹出访问量超过流量开关控制最大访问提示信息。

  测试结果：

       在流量开启设置好业务交易控制场景和性能测试场景后，设置瞬间并发下操作某一个业务UCC服务请求，当超越该请求时应该提示如下信息，确保系统受流控成功。

并在压力测试过程检查内存回收情况、服务器资源资源利用率、session会话回收情况，确保此时的会话数的正确性和回收率的准确。

    而在loadrunner压力测试场景中，也可以看到如下错误提示信息，说明流控在并发下功能的准确性。

以上场景是针对业务请求进行流量控制，算是业务流控、而一般微服务时代是技术接口、集群部署方式的这时流量监控可能复杂性更高，例如，对每一个接口服务的调用频度而限制、调度频率的设置等进行验证下非功能性测试。