商业背景

互联网技术的发展极大地降低了直播的门槛，让直播技术由庙堂之高走向普罗大众。近年来视频直播行业发展非常迅猛，但是直播风光的背后却有着不少的行业挑战，例如访问流量的峰谷效应、日益严峻的安全形式、网络威胁和攻击、不可控的用户监管问题等等，都困扰着直播行业。

本次我们介绍的是卓见云针对某直播类型客户的直播性能优化以及测试方案的案例。

业务现状

现网架构不足：

• 架构较为简单，没有按业务进行分模块建设，难以应对未来复杂的运维操作。同时ECS服务器不具备弹性伸缩功能，难以应对不可欲知的业务高峰；
• 经典网络，阿里云自动分配的ip地址，有一定的规律性，那么黑客也就可以利用内网ip进行局域网攻击，虽然在阿里云的安全体系下有些难度，但事实也证明了有被攻击的可能性；
• 安全防护较为单薄，仅部署了DDoS高防IP功能，没有防数据泄漏、恶意注册、软件漏洞、鉴黄鉴恐等安全功能；
• 数据库占用率抖动，需要进行专业的数据库优化服务。

优化后架构：

预期实现目标：

• 模块化建设，业务分块设计，升级方便，运维灵活
• 业务能力弹性化，可按需动态扩容服务能力,支持灵活弹性业务架构，满足快速、高效、移动化、无空间限制的业务需求
• 边界安全，经典网络换专有网络，二层隔离
• 网络安全防护，在云上建设云清洗中心，应对 4~7 DDoS攻击
• 服务器应用安全，使用WAF防护服务，应对黑客入侵、数据泄漏、服务器漏洞等服务器安全风险。同时部署先知服务，对白帽子发现漏洞进行修复及奖励
• 未知威胁防护，使用态势感知服务，在云上主机安装安骑士感知安全风险，通过安全大数据技术，综合各安全系统数据，在攻击前、攻击中、攻击后进行威胁感知，提前检测0DAY攻击

本次架构优化从弹性和安全两个方面着手，应对客户的10万用户并发问题，目前架构处于提炼优化阶段，通过阿里云性能测试产品进一步验证该架构承载能力。

二、  产品介绍

2.1 产品介绍

性能测试（Performance Testing）是全球领先SAAS化性能测试平台，具有强大的分布式压测能力，可模拟海量用户真实的业务操作场景，让应用的性能问题无所遁形。 性能测试是集测试脚本管理、测试场景管理、测试结果管理为一体的性能云测试平台。性能测试基于阿里云计算平台研发，可提供超大规模并发压力，满足任意规模系统的性能测试需求。性能测试在工作时会通过施压机产生压测流量，用户如果对施压的流量、地域等有更多要求，性能测试施压机可动态扩展在全球范围进行部署。 性能测试平台提供压测机，无须安装压测软件，海量并发唾手可得。模板化的脚本编写轻轻松松跑性能测试，可视化的脚本调试回放让应用协议层的每个细节都清晰无比，脚本录制插件极大地提高脚本创作效率，手工脚本解决复杂业务测试，实现性能测试的无限潜能。丰富的性能指标，准确的测试结果，让性能测试成为性能调优的利器。 可以使用性能测试对自身系统性能状况进行整体评估，一方面可以找到系统性能瓶颈从而优化系统，另一方面可以充分了解系统性能指标便于未来扩容。性能测试保障企业应用性能和稳定性，提升用户体验，促进业务发展，最大程度实现企业的商业价值。 性能测试还拥有强大的性能支撑体系和权威的性能专家服务，可迅速提升性能测试人员技能，实现企业和员工双赢。

2.2 产品优势

专业: 分布式并发压测，施压能力无上限;模拟业务场景，性能缺陷暴露无疑;阿里性能专家在线服务，测试无忧。

易用: 平台提供压测机，无需安装软件;脚本场景监控简单化，省时、省力;1分钟上手，轻轻松松做性能测试。

经济: 提供包月和按量付费两种计费方式，满足持续回归和爆发式业务，更经济实惠、多用多省、放心压测;提前容量评估，促进业务快速发展;提升用户体验，快速扩大市场份额。

可靠: 服务高质量容灾，可用性高达99.99%; 测试结果真实准确无误; 多种安全防护措施，保障数据安全。

三、  测试架构

3.1 系统架构

阿里云性能测试可以针对阿里云内机器应用系统或非阿里云（外部）机器应用系统进行性能测试；不仅支持http/https，TCP/UDP，webservice等协议，而且通过手工编写代码支持更复杂的协议。

测试整体架构图

3.2 基础技术架构

TPS基础技术架构

性能测试控制中心：用户使用性能测试的接口，它是集环境管理、性能测试、性能监控、性能分析、性能报告为一体的 SaaS 平台；它可以将性能测试任务传递给消息服务器 MQ ；并且有外部接口供客户进行调用。
控制消息服务器：接收控制中心任务消息传递给分布式压测集群进行运行，而且接收分布式引擎传递回来的数据并传递给控制中心。
分布式压测集群：由两台 Controller 和十台 Agent 组成，Controller 接收到任务以后，将任务传递给 Agent 进行施压；智能调度和动态分配由 Controller 进行。目前分布式压 测集群部署地华东1(杭州)、华北2(北京)、华北1(青岛)、华南1(深圳)、香港，未来将在其他国内城市和国外城市进行部署。

3.3 功能模块

性能测试控制台

各项功能

• 脚本管理：提供简单易用的性能测试脚本模板。
• 场景管理：提供多种模拟真实场景的施压方式，提供丰富的性能指标监控和多种操控方式。
• 监控集：提供公网非阿里云监控机维护入口。
• 结果报表：提供完善的性能结果报表和强大的性能分析日志。

模块

• 脚本：脚本是执行性能测试的基础，脚本里包括需要压测的服务器地址、压测的url、压测的参数和压测的类型。
• 场景：场景需要绑定脚本来运行，一个场景可以绑定多个脚本，可以在场景中设置并发压测用户数、施压模式，场景开始执行后可以实时查看性能指标。
• 环境：可选择公网非阿里云服务器作为监控机。
• 结果：结果自动保存可随时查看。

四、测试方案

4.1 测试目标

本次测试目标如下：

• 容量测试：核心业务(核心业务1+核心业务2)+非核心业务基线（非核心业务1+非核心业务2+非核心业务3+非核心业务4+非核心业务5+非核心业务6）混合交易容量
• 稳定性测试：混合交易稳定性
• 突变测试：非核心业务突变3倍，对核心业务的影响
• 对比测试：和线上同等压力下，线上和线下资源消耗和响应时间对比。
• 恢复性测试：模拟网络攻击

系统架构主要有如下服务器：

• HTTP服务器：核心业务1和核心业务2业务
• TCP服务器：核心业务使用人员终端心跳业务
• MongoDB服务器：非结构化数据库存储
• Redis服务器：信息推送
• MySQL服务器：结构化数据库存储

4.2 测试指标

• 容量测试：核心业务1 TPS>=600笔/秒,核心业务2 TPS>=1200笔/秒
• 稳定性测试：至少在核心业务1 TPS等于300笔/秒和核心业务2 TPS等于600笔/秒能稳定运行8小时
• 突变测试：非核心业务突变3倍，基本对核心业务无影响
• 线上线下资源消耗对比测试：在跟线上核心业务1 TPS等于150笔/秒和核心业务2 TPS等于120笔/秒同等压力下，测试环境的MonogoDB和Redis CPU Load小于5%,磁盘利用率小于0.1%
• 线上线下存储访问时间对比测试：在核心业务1 TPS等于200笔/秒和核心业务2 TPS等于400笔/秒的情况下，应用观察到的存储访问平均耗时不超过4ms，最大耗时不超过100ms。
• 恢复性测试：系统能恢复，TPS无变化。

4.3 业务模型

4.3.1 分析

通过生产上高峰业务量分析得出，核心业务1和核心业务2除了双12外，比例占比1：1.5左右，通过系统整个趋势观察，发现核心业务2业务量有明显增长趋势，因此核心业务1和核心业务2的占比为1：2。高峰时候核心业务总的TPS只有50~200笔／秒。
核心业务量：
**非核心业务量：
** 非核心业务1+非核心业务2+非核心业务3+非核心业务4+非核心业务5+非核心业务6

编号	业务	TPS	占比
1	非核心业务1	400	16.4%
2	非核心业务2	500	20.5%
3	非核心业务3	833	34.2%
4	非核心业务4	210	8.6%
5	非核心业务5	300	12.3%
6	非核心业务6	190	8%
合计		2433	100%

4.4 模型**

模型1

此模型用于容量测试、稳定性测试和恢复性测试。

模型2

此模型用于突变测试。

模型3

此模型用于线上线下资源消耗对比测试。

模型4

此模型用于线上线下存储访问时间对比测试

4.5 脚本设计

经过调研，发送后台的业务均是URL+自定义Body方式，因此在性能测试里面，新增一个脚本，上传参数化文件，定义事务，设置连接和Body就行了，注意尽可能多的进行参数化。

4.6 测试结果

4.6.1 容量测试

4.6.2 测试场景

按照模型１，设置用户数比例和步调时间(保持业务占比，不偏模型)，运行20分钟，进行负载测试。

4.6.3 测试结果及分析

第一轮测试
按照核心业务1 1000笔/秒和核心业务2 2000笔/秒目标发起压力，发现不能达到目标，TPS曲线不稳定，运行到１分钟的时候，下降非常厉害，抖动也非常厉害，通过监控，发现FULL GC非常频繁，达到１秒１次，经过与架构师沟通，这是由于实现机制导致的，核心业务1的机制是将内容放到队列里面，队列长度是2147483647,后台只有64个线程（不能修改）在消化，消费者（消化）处理速度的比生产者（核心业务1）慢，导致队列长度越来越大，内存很快被消化完了，导致FULL GC频繁，这属于架构问题，不能进行修改。
核心业务2：

第二轮测试 按照核心业务1 600笔/秒和核心业务2 1200笔/秒发起压力，运行20分钟，TPS基本保持稳定，通过监控发现，order应用连接MongoDB连接数报已满的异常错误、logserver IO过高、MongoDB locked DB值高于75%。   
按照核心业务1 800笔/秒和核心业务2 1600笔/秒目标发起压力，不能达到此目标，TPS曲线非常不稳定。

第三轮测试 mongoDB 只有表锁没有行锁，导致locked值非常高，这个是产品问题，没办法进行调优。 将order应用MongoDB连接数从250调到1000;logserver　磁盘换成效率更高SSD磁盘；重新按照核心业务1 800笔/秒和核心业务2 1600笔/秒目标发起压力，运行20分钟，TPS曲线基本稳定。

核心业务1：

核心业务2：

4.6.4 测试结论

系统的容量为核心业务1 800笔/秒和核心业务2 1600笔/秒，满足核心业务1 600笔/秒和核心业务2 1200笔/秒目标要求。

4.7 线上线下资源消耗对比测试

4.7.1 测试场景

按照模型3发起压力，在核心业务1 150TPS和核心业务2 120TPS压力情况下，运行20分钟，资源消耗对比。

4.7.2 测试结果及分析

MongoDB 和 Redis CPU Load均小于0.5, CPU 利用率均小于10%,磁盘利用率均小于0.1%,　这些指标结果比线上资源消耗结果略好。

4.7.3 测试结论

在跟线上同等压力的情况下，阿里云环境各项指标结果略好于目前线上环境资源消耗。

4.8 线上线下存储访问时间对比测试

4.8.1 测试场景

按照模型４发起压力，在核心业务1 200笔/秒和核心业务2 400笔/秒的压力下，运行20分钟，观察存储访问的时间。

4.8.2测试结果及分析

在xflush上面观察到的存储耗时值小于3ms，最大值不超过100ms

4.8.3 测试结论

满足目标平均耗时不超过4ms，最大耗时不超过100ms的需求。

4.9 突变测试

4.9.1 测试场景

按照模型２，在核心业务1 TPS 400笔/秒和核心业务2 TPS 800笔/秒的情况下，平稳运行５分钟后，将非核心业务按照基线的３倍进行突变，运行５分钟，观察核心业务TPS曲线的变化，然后将非核心业务恢复到基线，观察核心业务TPS曲线的变化。

4.9.2 测试结果及分析

核心业务1：

核心业务2：

从图中可以看出，当非核心业务突变3倍以后，对核心业务1和核心业务2有轻微的影响（核心业务1和核心业务2 TPS下降），但马上能恢复，突变的整个过程对核心业务基本无影响。

4.9.3 测试结论

非核心业务突变３倍对核心业务基本无影响，满足目标要求。

4.10 恢复性测试

4.10.1 测试场景

按照模型１，在核心业务1 800笔/秒和核心业务2 1600笔/秒的压力下，平稳运行５分钟后，断开所有mysql服务网络5秒，观察核心业务TPS曲线变化，然后恢复mysql网络，观察核心业务TPS曲线变化，接着断开所有MongoDB服务网络5秒，观察核心业务TPS曲线变化，然后恢复所有MongoDB服务网络，观察核心业务TPS曲线变化。

4.10.2 测试结果及分析

核心业务1：

核心业务2：

从图中可以看出，断开MySQL和MongoDB网络5秒的瞬间，核心业务1和核心业务2的TPS有轻微的下降，随后能恢复到正常水平，因此对核心业务基本没有影响。

4.10.3 测试结论

模拟网络攻击，对核心业务基本没有影响，满足目标要求。

4.11 稳定性测试

4.11.1 测试场景

按照模型1和最大容量的80%左右发起压力(核心业务1:600笔/秒和核心业务2：1200笔/秒)，运行8小时，观察系统是否能稳定运行。

4.11.2 测试结果及分析

核心业务1：

**核心业务2：

** 运行到35分钟后，核心业务1和核心业务2 TPS开始有轻微大幅度波动，运行到45分钟后，核心业务1和核心业务2 TPS开始大幅度波动，比较频繁，并且不能恢复到初始水平（过一段时间，TPS逐渐在下降），经过分析发现是FULL GC导致，详见7.1.2测试结果及分析。 因此将压力降为一半（核心业务1：300笔/秒，核心业务2：600笔/秒），重新运行稳定性测试。

核心业务1：

核心业务2：

系统在核心业务1 300笔/秒和核心业务2 600笔/秒的压力下，基本能稳定运行8小时，但随着时间推移，Full GC次数越来越多，长时间运行下去将会导致系统处理能力大幅度下降（详见7.1.2测试结果及分析）

4.11.3 测试结论

在核心业务1 300笔/秒和核心业务2 600笔/秒的压力下，系统基本能稳定运行8小时，满足目标要求。

转载自：卓见云对某客户直播性能优化及测试方案