本文主要是介绍考试查分场景重保背后，我们如何进行可用性测试，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
作者：暮角
随着通过互联网音视频与知识建立连接的新学习方式在全国范围内迅速普及，在线教育/认证考试的用户规模呈井喷式增长。但教育容不得半点马虎与妥协，伴随用户规模不断增长，保证系统稳定性、有效避免千万考生考试时遭遇故障风险，成为行业认证机构/部门解决的首要难题。
在某次行业认证考试后，考生登陆查分系统时遭遇白屏、卡顿等问题。因此，行业认证机构/部门开始探索系统稳定性评估的路径。不同于传统线下行业可模拟出对等的生产环境，在线教育/行业认证的压测难以实现同级别的服务集群。数据构造不真实、场景不符实际使用都会造成压测任务与真实场景的偏差。此外，压测工具缺乏安全性、人力成本、IT 成本投入大等问题亦亟待解决。因此，想要完美承受高压检验，就需要进行细致的调研与准备工作。
为了帮助更多在线教育、认证机构/部门避免以上问题，我们完整复盘如何进行一次完整性能测试，涵盖部署架构资源风险输出与优化、应用实时监控与告警（可观测性）、系统容量评估与性能优化（压测）、活动远程保障与事后项目复盘。
第一步：需求调研与目标制定
为了更好的协调多方力量及保证项目执行足够聚焦，先设定一个业务目标。面对一个存在“白屏、卡顿”等问题的 Web 系统，与业务团队沟通初步制定「系统可以支撑 5 万 QPS 访问量」的目标。由于即将来临新的业务高峰，本次压测的初衷并不是在两周内对应用系统进行大幅度技术改造，而是通过压力测试发现应用的重大性能瓶颈并对之进行优化改造，并通过流量摸高方式了解系统真实服务能力，辅以分流等手段保障服务的可用性。
第二步：资源评估
（一）工具评估
进行高并发服务保障，除了对应用的服务能力进行一定扩容之外。由于行业认证机构/部门此前在云上未进行过压力测试，因此需要购买压测工具以及相应的监控工具，这里使用了阿里云性能测试 PTS、应用实时监控服务 ARMS，这里需要注意的是：
- 性能测试 PTS， 工具本身不收费，根据流量进行收费，所以需要根据压测规模、压测目标、压测次数，提前预估压测资源包的额度。首次开通性能测试 PTS，赠送 5000 VUM 免费额度，可以用来帮助团队熟悉工具的使用或进行初次测试。
- 应用实时监控服务 ARMS， 目前按照数据写入量进行计费，提供每个月 50 GB 免费额度，这个数据写入量与 JVM 进程数量、存储时间相关，免费额度基本满足本次压测需求。
- Web 应用防火墙 WAF， 由于本次压力测试是在真实生产环境进行，流量会过 WAF。由于 WAF 按照流量计费，压测目标超过用户所购买的 WAF 规格包。WAF 3.0 版本，当前规格带宽 100M，5K QPS，压测目标 5 万 QPS，超出部分按量计费，不使用不收费，按 45K QPS 估算，0.15/QPS/天，按 3 次压测+分数查询首日，共 4 次预估费用 2.7 万元。
（二）资源梳理
- 与研发团队对齐业务系统架构、业务资源容量情况及压测环境、压测工具和业务接口信息沟通。
- 关键业务接口梳理完成 (非全量，关键 API）。
- 重保压测资源与费用评估。以 5 万 QPS 为目标，系统压力测试费用评估，包括测试所需的 ECS 、PTS、ARMS、WAF 等费用。
- 确定最终资源使用规划。按生产等比配置测试环境，机器数量 6 台，升级新购资源费用，初步费用评估完成。
第三步：压测摸高
（一）第一轮压测：问题初现
在完成压测环境、系统数据准备以及压测场景配置之后。开通 ARMS 完成 Java 应用接入，同时提供压测环境的服务器清单，开始 PTS 压测环节。其中，因为域名所属行业特殊，PTS 压测域名需要开白才可以。我们开始第一轮压测。
【压测结果】
「登录-查分」并发用户数 3000，平均 RT 1631ms，平均 TPS 1964，错误数 1.7 万。
【问题发现】
应用压测过程中有大量的 5s 超时问题，后续调整 PTS 超时时间。
【问题发现】
概览所有环节中，验证码环节耗时最长，RT 平均能达到 7s 。
调整 GTM 主备配置互换，启动第一轮压测，最高 3K QPS 不及预期。同时，调整 tomcat 应用连接池大小至 4096。因为与生产环境共用，只能业务空闲时间进行压测，导致压测进度与预期不符，调整 SLB 转发规则并指向测试服务器组。同时，阿里云建议后续研发团队可将验证码信息存储到 Redis 中来提升性能。从压测情况看研发侧优化效果较好，但 RT 波动较大。云原生应用平台团队给出一些优化建议后，RT 波动问题明显改进。
（二）第二轮压测：持续改进
在优化了一些中间件优化之后，我们基本逐渐提升并发用户数继续进行第二轮测试，并持续改进。
【压测结果】
「登录-查分」并发用户数 1 万，平均 RT 1560ms，平均 TPS 6082，错误数 6.2 万。
「登录-查分」并发用户数 2 万，平均 RT 2916ms，平均 TPS 6831，错误数 3390。
【问题发现】
通过对比测试，我们发现应用承载能力就是 1 万并发用户数、平均 RT 1.5s。提升 1 倍并发用户后，服务器平均 TPS 没有提升，只是 RT 增加了 1 倍。
针对上述问题，研发团队进行了优化。通过在内网使用 Jmeter 测试，看到单台服务器性能有明显提升，并发现 Redis 存在可优化点。进一步分析发现，很多慢请求都是访问用户的自建 Redis，但研发团队反馈 Redis 延时很小，并且切换到阿里云 Redis 后未发现改进。因为之前验证码环节性能很差，压测环境都跳过该环节。目前这部分优化已经完成，在测试增加了验证码环节。验证码环节压测需要特殊配置，配置好后继续测试。当天结果瓶颈还未找到，QPS 稳定在 1.2 万、RT 2-3s，再加大压到 5 万，无明显改善。
（三）第三轮压测：问题突破
因为目前整体服务承载能力多次优化后，稳定无法提升，阿里云建议尝试通过增加服务器数量压测，由此判断是应用服务器性能，还是数据库服务器性能导致目前瓶颈。如果横向扩展应用服务器性能能提升，就是应用服务器问题，否则就是数据库这种单点服务的问题。应用服务器从 6 台增加到 8 台，服务能力并未看到线性上升，QPS 增加到 1.3 万左右。结合此现状，可以判断是单点问题限制，推断可能是 Oracle 数据库、Redis，但研发团队反馈压测时两个产品链接不多，响应速度在毫秒级。经过对压测报告的分析，发现滑块验证处理比较慢，耗时较长，研发团队将滑块验证改为字符验证码。并发起新一轮的压测。
【压测结果】
添加 Redis 后，3 万用户，3 分钟，性能几乎翻倍。
「登录-查分」并发用户数 3 万，平均 RT 1514ms，平均 TPS 20145，错误数 2960。
「登录-查分」并发用户数 5 万，平均 RT 4552ms，平均 TPS 13744，错误数 21.6 万。
【问题发现】
通过对比测试，发现应用服务器的承载能力在翻倍提升后，稳定在 2 万 TPS。即便把并发提升到 5 万，该指标也未能再继续提升。Redis 扩容后(64c 128g *3)，性能提升 1 倍，RTS 稳定在 2.2 万，RT 1-2s 。尝试使用阿里云 Redis（7c8g 4db）压测，但与自建 Redis 相比规格小太多，测试结果性能提升不大。
应用 8 台服务器最高 QPS 到 2.5 万，按照 5 万 QPS，届时分流需要拆分 2.5 万到静态页面。测试压测单台分流服务器静态页面 RTS 支撑能力为 4 万，静态页面使用 404 页面是否合理待评估。「
登录-繁忙」并发用户数 2.5 万，平均 RT 582ms，平均 TPS 41772，错误数 10.9 万。
SLB 负载不均是健康检查失败导致的，静态页返回 404，SLB 层面不会抑制请求转发，会正常分发请求给该应用服务器。
第四步：上线保障
在上述多轮压测以及优化之后，我们进行最后一轮压测：业务服务器+静态页面 压测达到预期业务目标 5 万 QPS，按 3 : 1 比例分发请求，度过业务高峰后快速关闭静态页服务器。
【压测结果】
「登录-查分」并发用户数 2.5 万，平均 RT 1030ms，平均 TPS 22965，错误数 44（6 台生产机器总体处理能力）。
「登录-查分」并发用户数 2.5 万，平均 RT 396ms，平均 TPS 64887，错误数 72.2 万。
【压测摸高】
10 台应用服务处理能力最高 2.5 万 TPS，其中 3 台应用服务器上同时部署静态页面，应用程序和静态页面权重比例 1 : 1压测。并发 4 万、RT 396ms、TPS 64887ms、达到预期目标 5 万 TPS。最后一次持续高并发压测，并发 2.5 万，RT有抖动，TPS 维持在 2 万，成功率 99% 以上。通过最后的压测结果，结合资源现状进行保障方案落地：开放查分入口首日，静态页面与应用程序权重比例调整为 100 : 30 ，总体处理能力 3 万 TPS。
【开放查分】
晚 23 时开放查分，流量小于预期，系统平稳运行度过峰值 QPS 1.6W。
第五步：优化总结
经过多轮的压测以及前期优化，应用及架构找到多个瓶颈点并进行改造优化，比如验证码模块性能差、单 Redis 改为集群 Redis、应用多线程处理能力、业务处理能力随资源增加而线性提升等都进行相应的验证和优化。在现有条件下，优化后的应用和架构的健壮性大幅提升，积累了该应用的资源容量评估经验，后续可以随着业务量增减，有数据依据的增减资源，日常保持好水位线即可。同时，我们梳理了诸多日常优化方案，其中包括：
一、安全风险预警。
重保期间请求流量尚未经过 Web 应用防火墙，缺失常见攻击防御能力，后续考虑请求流量过 WAF 且动静资源分离，静态资源通过 CDN 加速分发。一方面，减轻业务服务器对静态资源处理压力和带宽压力；另一方面，有效降低 WAF 带宽压力与成本。
二、数据库产品存在单点风险与升降配不灵活问题。
在 ECS 云服务器上的自建 Oracle 数据库存在单点故障风险，一旦单个服务出现异常整个平台会彻底不可用。自建的 Oracle 数据库与 Redis 服务，无法灵活改配，不便于日常使用与重保期间进行能力切换。后期计划通过改造使用云上的数据库，加强可用性的同时，灵活升降配，进一步贴近当前业务需求。
三、应用存在大规格服务器资源无法利用问题。
目前应用单体架构耦合度高，无法经济的单独部署更多涉及性能瓶颈的模块。后续计划对应用内部模块进行拆分，以便让应用可以有更合理的部署架构。另外，针对目前问题，后续重保期间扩容的应用服务器采用更多低规格服务器来提升性能。从现在的 64C128G 变为 16C32G，从而获得 4 倍应用服务能力。
四、在日常研发中使用 PTS 进行持续压测。
通过本次重保压测，研发团队已经在阿里云 PTS 产品团队支持下充分掌握该工具的使用方法。该工具拥有的快速创建多地压测节点的能力充分利用的阿里云平台的多地域优势，能快速模拟实际业务场景进行全链路压测，大大的节约了应用问题发现与改进时间。是本次重保环节中的核心功臣。
五、继续在日常应用服务环节使用 ARMS 监控。
通过 ARMS 应用监控，在压测过程中发现很多细节问题，为快速的定位问题提供极大便利，大大提升问题定位效率，是不可多得的运维必备工具。
第六步：查漏补缺
一、PTS 是一款非常容易上手且便捷的压力测试工具，使用 PTS 可以迅速提升测试效率；
1）使用自带的录制控件可以快速录制场景，自动捕捉需要压测的接口；
2）产品公共云值班同学能耐心给予产品问题解答，即便是新手也可以立即上手使用；本次测试过程中，研发团队是第一次使用该产品，交付团队也不是熟手，但是使用十分丝滑，整个过程中并未觉得不顺手；
二、通过压测发现系统瓶颈的过程是一个持续寻找问题的过程，压测能给系统压力然后暴露出系统的瓶颈；
1）单 Web 服务器并发能力需要第一步得到答案。分布式架构或者单体架构都没关系，重要的是要获取每个服务角色的单机能力。服务器的规格并不是越大越好，比如这次我们最后都无法给予一个 64C128G 的 Web 服务器超过 50% 压力，合适的规格是业务规划最重要的评估项。
2）确认单 Web 服务节点的能力后，就可以提升服务器数量进行整体压测，这样扩展下去就能知道在达到压测目标的情况下，每个服务器角色需要多少台。除非是严重的 Web 服务角色节点性能问题，短期内提升服务器数量都可以大规模提升服务能力。
3）想要更快的暴露系统架构中的单点瓶颈，可以横向扩展的服务器扩展到一定规模。这种单点瓶颈一般就是数据库，例如关系型数据库、缓存数据库、分布式数据库。如果压测到单点瓶颈，优化关系型数据库最简单的方式就是提升服务器规格；如果无可提升就需要使用读写分离来分担压力。如果使用可以横向扩展的数据库，就可通过扩容节点来提升能力，使系统整体服务能力提升。在高并发场景下，使用内存数据库无疑是提升能力的快速通道，尤其是考试查分这种只读场景。
三、短时间内能做的事情十分有限，重保这种高并发场景要做的就是保障系统可用性；
1）我们本次压测的系统是一个适用于传统自建 IDC 机房并有一定技术历史包袱的系统，采用 Windows + Oracle + 单体架构，想要在短期内改变架构很难。为了保障近期重要的高并发场景，研发团队聚焦于把解决严重的性能缺陷，扛过保障时点。
2）服务分流是保障系统可用性的最简单手段，8 台 Web 服务器测试得到的应用最高 QPS 才 2 万余，单台 Web 服务器能承载的繁忙页 QPS 就能达到 1 万 QPS。所以，关键时刻保障部分用户可用即可。在完全不可用与排队间取舍，一起排队用已是最优解。
3）上线前一定要做好保障演练。前端 SLB 最大能承载的流量就是 5 万 QPS，这也是本次演练的目标。因此设计了正式应用服务器承载 3 万 QPS 流量，繁忙页承载 2 万 QPS 流量，在 SLB 端配置权重比例。ARMS 应用监控是秒级监控且调整 SLB 权重实时生效，但只对新连接请求生效，原有长连接不受新权重影响。
这篇关于考试查分场景重保背后，我们如何进行可用性测试的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
