百亿级交互服务的容量测试实践

本文作者孙玉，科大讯飞测试架构师，将于 MTSC2019 大会分享《 科大讯飞百亿级交互业务的缺陷预防之路 》议题，  8 折售票本周截止， 报名方式见文末 ！

一、背景

科大讯飞广告业务起始于 2014 年 10 月，经过 4 年发展，当前已呈现破竹之势；业务的快速发展给我们带来红利的同时，也给我们测试技术上带来了诸多挑战，如：

1. 超敏捷的业务迭代演进挑战：时间就是钱，早一秒上线，多一秒流水，2018 全年预计累计迭代逾 1000 个版本，带来了常规版本功能测试保障上的巨大挑战；

2. 流量安全水位线的容量挑战：现网稳定是生命线，特别是面对电商大促，能够稳定承载的流量范围是我们必须要掌控的；

3. 降本增效上的技术团队挑战：稳定性和成本就像是天平的两端，在成本尽可能低的情况下，我们的系统需要跑到合理的水位，既能保障业务的正常运转，又不出现局部明显的资源浪费；

以上第 2 和第 3 个挑战都离不开当前要说的容量测试。

ADX（Ad Exchange 的简称，即广告交易平台）是讯飞广告业务中最核心重要的组成部分之一；2018 年 6 月，ADX 服务集群单日处理请求流量交互已突破 100 亿次 +，在如此庞大量级的流量下，对服务性能能力自然有极高的要求；现网服务集群的容量能力更是需要重点评估的能力，通过容量评测数据可夯实提升技术信心。

本文主要介绍讯飞广告业务百亿级交互服务-ADX 服务的容量测试实践，即基于 ADX 业务服务自身复杂的使用场景：

• 如何剖析构建贴近现网整体环境的集群测试环境

• 如何挖掘现网数据指导测试场景选型

• 如何进行 工具 选型和实施

• 如何借助更加完整立体的内部数据量化评估服务性能表现

• 以及最终如何量化整体集群容量能力

下文将为你一一解答。

二、容量测试的相关实践

容量测试需要关注哪些内容，如何更好的开展容量测试？这里我们提供以下 5 个方向经验供借鉴参考。

2.1 如何剖析构建贴近现网整体环境的集群测试环境

构建更真实的容量测试环境，首先我们要清楚熟悉并剖析现网整体集群环境的结构，了解部署架构、完整的业务链路；通过业务链路也评估各依赖组件对应的机器资源选择（数量、配置、风险提出防控），构建贴近现网整体环境的最小单元化集群；切记直接 1：1：1 的方式部署，根据实际的已知的能力来全局规划，对于具备强悍性能的组件可适当共用部署；

ADX 容量测试集群主要从 5 点进行规划，

1. 核心配置一致性： 被测核心服务所在的测试服务器一定要尽可能的保持与现网资源相同的硬件配置；切忌线上物理机，线下虚拟机，线下结果不具备没有参考价值；拿到机器后还要保持系统配置一致性要求，如内核参数调优、CPU 超频开启；部署的组件版本等软环境更不需要说了；

2.  入口环境模拟： 避免压测工具直接施压被测试对象，模拟线上 Nginx 入口环境，通过真实 nginx 转发实现后端流量呈现；这里做还有个好处，可摸底不同硬件配置的服务器在相同流量压力下的性能表现；比如你线上还有虚拟机，入口 nginx 可增加请求虚拟机节点，方便比对；

3.  第三 方服务模拟： 对我们来说是最重要最核心的依赖，该依赖我们调用了研发花了完整 3 周进行开发和实际优化，外部服务我们实际部署时采用分布式多服务器多节点部署以提供足够强悍的外部依赖能够满足实际测试；

4.  出口环境模拟： ADX 业务是非常重网络交互型的业务；请求实际分发到外部，需要掌握流量带宽使用数据；可通过此环境模拟，了解入口流量和出口流量的关系；更重要的是能够通过此机制解决第三方模拟服务多服务器多节点访问难题；更可以模拟外部网络丢包或外部网络带宽占满情况下，服务性能的表现；

5.  实时数据处理集群： Spark 集群，对实时压测过程产生的数据进行内部量化分析；这个集群的目的在后面介绍；

以上的几点，有一些是需要协同团队处理的；所以针对大的工作开展，在前期尽可能树立重大攻关项目，届时可快速有效的获取资源和相关支撑；

2.2 如何利用现网数据挖掘指导测试场景选取？

很多业务这块的选取或典型代表性场景提取要比我们简单的多；来看看我们的复杂性，现网 1 万多个广告位，每个广告位的自身特点和运营配置不同，也就是代表着现网约一万种具体请求场景；去选择其中任何 1 个场景都不合适，必须要输出代表性符合整体表现的场景；我们如何解决这个问题呢 ?

我们这里主要通过现网爬取 5 个重要场景要素的数据提取现网典型场景，第一个我们从 10 余种广告类型中抽取出请求量占比最高的广告类型；通过入口请求和出口请求之间的关系并结合现网日志、运营调研、top 平台，获取到广告位的上游平台配置关系；通过现网分时段响应时间数据、历史电商节前后性能表现输出平台时间控制和整体广告请求时间控制；通过现网分时段填充数据和历史电商节填充表现输出平台填充和整体广告请求填充控制；通过专门大数据任务分析、离线数据、结合现网日志和运营调研输出轮数分布；

以上内容提取完之后，更重要是需要通过多种变量控制训练出目标场景，目标场景具有典型充分代表性；通过训练时，摸底单一变量变化是对场景的影响，输出多个多样场景满足更丰富的场景容量摸底；

2.3 如何进行性能测试工具选型和实施

为什么要把这个单独拎出来作为一块内容呢？！开展大型复杂的性能测试工作，最常用的两种用于产生负载的性能测试工具就是 LoadRunner 和 JMeter。

不同的实施者有不同的选择；还有对资源使用监控的系列工具，如 nmon；不一例外，产生负载的性能测试工具我们选择的是其中的 JMeter，但资源使用监控的工具我们选型的是 Hadoop 生态中 cloudera manager；选择这些是基于下图左侧 3 点的考量结果；

1.  稳定控制进入流量 是我们容量测试要满足的第一要务 。

通过以往的经验和再次摸底调研，我们选取了 JMeter，因 JMeter 社区上提供丰富的插件库能够满足此场景的创建实施，我们可通过插件快速的配置所期望的稳定的流量进入量级。

2.  团队搭建复用成本 。

为什么要考虑成本呢？因为我们知道 LR 对 win 操作系统有要求，同时在指定操作系统下安装指定的 LR 版本也会产生一些或多或少的问题；但 JMeter 不同，其出色的跨平台能力，能够直接迁移到我们 Linux Ubuntu 操作系统上，特别适合我们服务端的测试，部署成本、调试成本、维护成本其实对我们实施来说更便捷；这里要说明的一点是尽量不要再 win 机器上使用 JMeter 进行并发施压，因为 Java 比较吃内存，占 CPU，很容易发生 JMeter 本身被卡死的情况；所以若采用 JMeter 进行性能压测，尽量采用 Linux 运行环境。

业务侧在实施这样的工程时，目标是把工程完成；但我们还要能够尽可能的顾忌到其实可以更好的选择那些更有利于团队快速复用的技术，在能实现相同目标目的的基础上，能够以更少的学习成本快速上手，后期工程实施时有一部分新人可参与，帮助团队成长；JMeter 一直是团队常用的接口功能测试工具，大家在日常接口测试功能上的玩的比较溜了，但性能这块积累还相对较少；选择 JMeter 也是对团队认知实践的一种补充。

3.  集群资源全局监控

我们在压测时使用的最频繁的 linux 客户端的资源监控工具可能就是 nmon 了，但 nmon 对于压测中整个集群资源的监控做起来比较费时，也难以有效分析；比如压测时我们不仅要关注被测核心服务的资源使用，我们还要关注关联组件或链路所在的服务器的资源使用情况，以帮助我们更好的分析问题瓶颈。

通过借助 cloudera manager 这种平台化的资源监控工具，可解决此问题。cloudera manager 提供了丰富的资源监控指标，CPU、内存、资源、网络、网卡、文件描述符，信息比较完整；直接可通过时间查询压测期间整个集群每个服务器当时的资源表现。类似的平台化资源监控系统还有很多，比如小米的 open-falon、开源社区里的 Zabbix；若涉及到集群监控，建议使用这类平台；网上的部署教程也比较多，具体不在此展开。

容量测试环境采用清一色的 linux Ubuntu 操作系统，我们通过 cloudera manager 可查看任何一台服务器的资源使用情况；这种平台化的资源监控系统为我们后期分析省心省力不少；

2.4 如何借助更加完整立体的内部数据量化评估服务性能表现？

我们根据 JMeter 和资源监控平台的压测数据是否就可以直接量化出我们期望的结果数据？不，对于有的业务还不够，我们需要借助更完整的业务内部数据进行综合分析；不能只看外部工具呈现，外部工具对于业务自身来说算是一种外部表象；我们需要关注业务自身出现了什么样的表现，既内外兼顾；

我们在容量测试实践的过程中不止关注性能工具给出的量化数据，我们还关注了实时数据量化，在介绍构建测试环境时提到了我们的实时数据分析集群，通过这个集群我们可以窥探实际进入到核心服务的流量各维度状态，包括核心服务处理性能、填充率等指标，这些指标的结果也决定了是否达不达标。

同时我们也可以利用这个集群分析瓶颈所在，服务整体链路各逻辑环节有专门的时间埋点，通过整合的埋点数据，我们可以定位出容量瓶颈时是哪个具体逻辑环节出现了异常；

另外，我们也会结合压测时重要服务的日志关注压测过程中的状态，若服务具备良好的服务日志输出规范，如日志的输出内容、日志的阶段产出量级，我们通过日志也可以分析到有价值的信息；

总体来说，我们就是通过这种三位一体的维度去整体量化评估我们服务的性能表现，这样得到的最终分析结果会更精准更有效。若业务上存在这样的数据，压测时也建议重点关注分析；必要时，都可以推进业务增加这些埋点；

2.5 如何量化整体集群容量能力

上文讲了量化服务性能表现，那么我们怎么去量化整体集群容量能力呢？我们针对我们业务自身的特点，制定了高可用基准红线，不满足其中任何 1 个都为未达标状态；

这个图给出了广告位配置上游平台不变，整体填充率不断变化的情况下，单个物理集群能够呈现的容量表现；我们可掌握填充率对吞吐能力的影响关系，同时借助于对测试环境实际的分析，并结合现网物理环境的特点（清一色的物理机，核心服务机器资源配置的一致性），我们就可以预估出现网核心服务的容量能力；

有种情况可能是有的业务存在的，就是现网集群的物理环境配置差异非常大，有的物理机有的虚拟机，这样的情况容量评估就复杂了，需要兼顾考虑虚拟机容量的能力；权重配置都会影响整体现网容量表现；

测试环境输出的单机容量或整体集群容量不是就结束了；测试环境的数据最多也只是 1 个借鉴或评估参考；测试环境输出的数据，对于我们进行现网论证也有比较大的参考价值；

这里提供了两种现网验证方式， 第一种 阶梯式线上引流，通过 Nginx 配置使某现网节点不断承载性能环境容量水位，可通过这种方式实际的探测出现网单个机器的容量能力，帮助我们校正评估更到位的整体容量；

第二种是通过测试环境结果数据下掉一些节点，使线上流量处于线上机器评估容量的安全水位，可得到线上集群容量（同样权重配置的不合理也会影响最终容量）；这种线上压测绝对不能影响用户体验，要对整个压测过程进行精准、实时的控制，对异常情况有完备的容灾能力。

三、结果及意义

通过容量测试不仅夯实了技术侧的信心，通过容量测试数据指导了电商节线上扩容，系统平稳的承载了电商节流量；同时我们也通过容量测试，识别了容量瓶颈，指导了核心服务的进一步改造优化。

关于 科大讯飞百亿级交互服务的质量管理最佳实践 更多信息，笔者将于 MTSC2019 测试开发大会 上做全面详细的介绍，期待届时能与各位同行现场交流。 （end）

MTSC2019|8 折售票倒计时

MTSC2019   第五届中国移动互联网测试开发大会 将于  2019 年 6 月 28-29 日 在北京国际会议中心举行，50+ 来自 Google、BAT、TMD 等一线互联网企业的测试大咖分享精彩议题，涵盖 移动自动化测试、服务端测试、质量保障 QA、高新测试技术（AI+、大数据测试、IOT 测试），游戏测试，工程效率提升 等专题。

MTSC2019 大会日程即将发布， 8 折门票倒计时最后一周！

大会官网 ： http://2019.test-china.org/

报名地址 ：https://www.bagevent.com/event/2202999?bag_track=YT

TesterHome 福利时间

转发文章到朋友圈，抽奖赠送 TesterHome 定制版精美礼物（卫衣／图书等）、MTSC2019 测试开发大会门票或优惠折扣，以及其他福利等！

• Step1: 转发本文到朋友圈，扫描二维码加小助手微信；

• Step2 : 回复「 福利 」入群抽奖；

• SteP3 : 回复「 组团 」入群，以 团购优惠价 购买 MTSC2019 门票；
  

P.S. 对于  MTSC  往届参会者 ，可享受 7.5 折福利 ，请进群咨询；

扫描二维码，或点击“ 阅读原文 ” ，抢购 8 折 门票！