性能压测|负载均衡

在性能压测的过程中测试工程师第一要素需要做的是输出性能测试方案和能够清楚被压测的服务它的完整请求链路通过方案阐述自己性能压测的目标、场景、策略等完整链路主要应用于在性能压测的过程中出现TimeOut等情况能够分析是哪个环节出问题。在这个过程中性能压测是无法绕过负载均衡的环节如果被测的服务在应用集群 中有N个副本整体的链路如下。在应用应用集群中之所以针对被测的目标服务按照多副本的模式来进行部署 是因为单副本无法满足来自客户端的高并发请求把一个服务实例通过多副本的部署模式这样能够有效的降低服务端本身的压力把来自客户端高并发的请求流量分发到不同的服务来进行消费而负载均衡它的任务就是把来自客户端高并发的请求结合负载均衡的能力分发到服务实例。通过负载均衡解决了服务端在高并发下承载的性能压力和可能出现的单点故障这样为服务的水平扩展提供了可弹性的伸缩空间。NGINX 具备反向代理与负载均衡的能力一般云厂商也是提供了ELB来承载负载均衡的能力而NGINX只承载反向代理的特性。在实际测试的服务中每个公司都有自己不同的部署模式。在测试的角度而言核心的在性能压测的过程中期望被压测的目标服务能够承载来自客户端的高并发请求并且相关的任务和API响应时间在可接收的范围内。以PHP代码为案例使用云厂商的ELB负载均衡应用服务它的完整链路如下所示。如果在压测的过程中服务从单副本增加到了N个副本怎么判断所有的副本都是在消费的呢因为很有可能新增加的副本根本就没有消费。最简单的判断方式就是看日志试想下一个服务如果没有消费那么也就不会打印具体的日志信息所以在新增加副本的情况下重新发送请求在日志系统中使用“podName”来进行过滤查看如果podName显示的副本数与期望的副本数一致并且都进行了消费那么说明新增加的副本数都是在消费的。某些云厂商的负载均衡基于信息安全的考虑使用的是“IP哈希”的策略在压测的场景下新增加的副本并没有消费还是由一个副本来接收压测引擎的请求并进行消费。所以在新增副本的情况下首先判断是否都在消费是很重要的。下面详细地阐述下负载均衡常用的策略。RR轮询RR具体指的是Round RobinRR轮询指按照客户端请求的顺序轮流分配到不同的服务器RR轮询适合平均分配的思想也就是期望服务端每个副本数能够平均的消费来自客户端的请求以性能压测为场景假设每秒并发是1万副本数是3个理论上每个副本数消费3333个请求具体如下图所示。加权轮询加权轮询指的是给每个服务实例分配不同的权重这种策略主要适用于后端服务在性能分配不均的情况下可以使用该策略根据该策略可以在实际企业运行的过程中分配不同的比例让性能好的服务实例承载更多的流量通过这样的方式来提升服务端整体的吞吐能力。依然以压测场景为案例让每个副本数消费不同来自客户端高并发的请求比例具体如下所示。加权轮询的策略下不建议每个副本数的资源是一致的。IP哈希IP哈希策略主要指的是根据客户端的请求地址来计算哈希值然后把请求分配给特定的服务器保证相同IP的客户端请求始终发送到同一个服务器上。在压测中特别需要注意如果策略是IP哈希策略有可能实际的请求是这样的具体如下所示。之所以出现这种情况是因为压测引擎没有使用IP的欺骗技术所以它发送的所有请求IP地址是相同的根据IP哈希策略把所有的请求分配给了其中某一个服务实例其他的服务实例并没有进行消费。如果想要彻底解决这个问题有两种方式第一是负载均衡把IP哈希策略调整为RR轮询第二种是不调整负载均衡策略而是压测引擎使用IP欺骗技术。最小连接在应用集群中的服务与客户端的连接大多数情况下分为两种协议 的模式来进行连接第一种是HTTP的协议还有一种就是RPC的长连接模式。最小连接模式主要主要应用于长连接的模式最小连接具体指的是把请求分配给当前连接数最小的服务器负载均衡通过最小连接的策略机制来保障服务端的可用性和避免服务端出现性能下降的趋势。最短响应时间最短响应时间指的是负载均衡把请求分配给响应时间最短的服务实例这样的目的是确保客户端连接服务成功后能够快速的把响应结果信息返回给服务端来提升用户的体验所以它的应用场景是对响应时间有很高的要求同时需要实时监听每个服务实例的响应时间。在负载均衡中每种策略都是有它的优势与劣势我们更多采用的是RR轮询的模式的也是期望每个服务实例都能够均衡的处理来自客户端的请求当然具体公司产品目标根据具体策略来制定。感谢您的阅读后续持续更新。最后下方这份完整的软件测试 视频教程已经整理上传完成需要的朋友们可以自行领取【保证100%免费】​​​软件测试面试文档我们学习必然是为了找到高薪的工作下面这些面试题是来自阿里、腾讯、字节等一线互联网大厂最新的面试资料并且有字节大佬给出了权威的解答刷完这一套面试资料相信大家都能找到满意的工作。