随着公司业务的不断扩张,用户流量在不断提升,研发体系的规模和复杂性也随之增加。线上服务的稳定性也越来越重要,服务性能问题,以及容量问题也越发明显。
因此有必要搭建一个有效压测系统,提供安全、高效、真实的线上全链路压测服务,为线上服务保驾护航。
关于全链路压测的建设,业界已经有了非常多文章,但是涉及到具体的技术实现方面,却很少介绍。本文想从全链路压测系统,从设计到落地整个实践过程,来详细介绍下全链路压测系统是具体是如何设计,以及如何落地的。希望能从技术落地实践的角度,给同行业的同学一些参考和启发。
全链路压测在业内已经有了广泛的实践,如阿里的 Amazon、PTS[1][2],美团的 Quake[3][4],京东的的 ForceBOT[5],高德的 TestPG[6]等等,都为我们提供丰富的实践经验,和大量优秀的技术方案。我们广泛吸收了各大互联网公司的全链路压测建设经验,并基于字节跳动业务需求,设计开发了一个全链路压测系统 Rhino。
Rhino 平台作为公司级的全链路压测平台,它的目标是对全公司所有业务,提供单服务、全链路,安全可靠、真实、高效的压测,来帮助业务高效便捷的完成性能测试任务,更精确评估线上服务性能&容量方面风险。
因此在 Rhino 平台设计之初,我们就定下以下目标:
Rhino 是一个分布式全链路压测系统,可以通过水平扩展,来实现模拟海量用户真实的业务操作场景,对线上各种业务进行全方位的性能测试。它主要分为控制中心(Rhino Master)模块,压测链路服务模块,监控系统模块,压测引擎模块,如图。(每一个模块都是由多个微服务来完成的。如下图每个实线图都代表一个微服务或多个微服务)。
压测过程中数据构造是最重要,也是最为复杂的环节。压测数据的建模,直接影响了压测结果的准确性。
为了高效的构造特定的 Fake 压测数据,Rhino 压测平台提供大量数据构造方式:
在压测过程中,有些压测请求需要进行登录,并保持会话;此外在很多压测请求中涉及到用户账号信息 UserID,DeviceID 等数据。用户账号的构造问题,一直是压测过程中非常棘手的问题。Rhino 平台打通的用户中心,设置了压测专属的账号服务,完美地解决了压测过程中的登录态,以及测试账号等问题。具体流程和使用界面,如下图。
压测隔离中需要解决的压测流量隔离,以及压测数据的隔离。
压测流量隔离,主要是通过构建压测环境来解决,如线下压测环境,或泳道化/Set 化建设,将压测流量与线上流程完全隔离。优点是压测流量与线上流量完全隔离,不会影响到线上用户。缺点:机器资源及维护成本高,且压测结果需要经过一定的换算,才能得线上容量,结果准确性存在一定的问题。目前公司内压测都是在线上集群上完成的,线上泳道化正在建设中。
压测数据隔离,主要是通过对压测流量进行染色,让线上服务能识别哪些是压测流量,哪些是正常流量,然后对压测流量进行特殊处理,以达到数据隔离的目的。目前 Rhino 平台整体压测隔离框架如图。
压测标记就是最常见的压测流量染色的方式。
目前公司内各个基础组件、存储组件,以及 RPC 框架都已经支持了压测标记的透传。其原理是将压测标记的 KV 值存入 Context 中,然后在所有下游请求中都带上该 Context,下游服务可以根据 Context 中压测标记完成对压测流量的处理。在实际业务中,代码改造也非常简单,只需要透传 Context 即可。
Golang 服务: 将压测标记写入 Context 中。
Python 服务:利用 threading.local()存储线程 Context。
JAVA 服务:利用 ThreadLocal 存储线程 Context。
为了解决线上压测安全问题,我们还引入了压测开关组件。
线上压测中,最复杂的问题就是压测链路中涉及到写操作,如何避免污染线上数据,并且能保证压测请求保持和线上相同的请求路径。业界有很多解决方案,常见的有影子表,影子库,以及数据偏移,如图[7]。
Rhino 平台针对不同存储,有不同的解决方案:
在压测之前,需要对服务进行压测验证。对于不满足压测要求(即压测数据隔离)的服务,需要进行压测改造。
a. 尽量减少代码改动,并给出完整的指导手册及代码示例,减少 RD 的工作量,降低代码错误的可能性
b. 提供简单便捷的线上线下 HTTP&RPC 的压测请求 Debug 工具,方便代码改动的验证
c. 对于新项目,在项目开始初期,就将压测改造加入项目开发规范中,减少后期的代码改动
请求调用链,对于线上压测是非常重要的:
Rhino 平台通过公司的流式日志系统来完成调用链检索的。一个服务在被请求或者请求下游时,都会透传一个 LogID。RPC 框架会打印调用链日志(包括 RPC 日志-调用者日志,Access 日志-被调用者日志),所有日志中都会包含这个 LogID。通过 LogID 将一个请求所经过的所有服务日志串起来,就完成调用链检索。
Rhino 平台在公司流式日志系统提供的链路梳理功能基础上,进行了进一步优化,以满足压测需要:
虽然 Rhino 平台对于压测有很多的安全保障措施,但是对于大型压测,保证信息的通畅流通也是非常重要的。因此在压测周知方面,Rhino 平台也提供了很多解决方案:
在压测之前,需要开启整体链路的压测开关的,否则压测流量就会被服务拒绝,导致压测失败。
对于调用链中不能压测的服务(敏感服务),或者第三方服务,为了压测请求的完整性,就需要对这些服务进行 Mock。业界通用的 Mock 方案有:
由于字节整个公司都采用微服务架构,导致一次压测涉及链路都比较长,快速无业务入侵的 Mock
方式成为了首选。Rhino 平台是通过公司 Service Mesh 和 ByteMock 系统来实现了高效的,对业务透明的服务 Mock。
压测执行前,Rhino 平台需要向 Service Mesh 注册染色转发规则,并向 Mock 服务注册 Mock 规则。然后在压测流量中注入 Mock 染色标记,才能完成服务 Mock:
Rhino 平台中,压测 Agent 就是一个最小调度单元。一次压测任务,通常会拆分成多个子 Job,然后下发到多个 Agent 上来完成。
2020 年春节抢红包压测中,Rhino 临时扩容在 4000+个实例,支撑了单次 3kw+QPS 的压测,但日常 Rhino 平台只部署了 100+个实例,就能满足日常压测需求。
Rhino 平台默认将全链路压测分为公网压测和内网压测。公网压测主要 IDC 网络带宽,延时,IDC 网关新建连接、转发等能力;内网压测,主要是压测目标服务,目标集群的 性能,容量等。
Rhino 平台在各个 IDC 都有部署 Agent 集群。各个 IDC 内服务的压测,默认会就近选择压测 Agent,来减少网络延时对压测结果的干扰,使得压测结果更精准,压测问题定位更简单。
除了多机房部署之外,Rhino 平台还在边缘计算节点上也部署了压测 Agent,来模拟各种不同地域不同运营商的流量请求,确保流量来源,流量分布更贴近真实情况。在 Rhino 平台上可以选择不同地域不同运营商,从全国各个地区发起压测流量。
为了应对线上压测风险,Rhino 平台提供两种熔断方式,来应对压测过程中的突发事件,来降低对线上服务造成的影响。
每个压测任务,都可以关联调用链中任意服务的告警规则。在压测任务执行过程,Rhino 平台会主动监听告警服务。 当调用链中有服务出现了告警,会立即停止压测。对于没有关联的告警,Rhino 平台也会记录下来,便于压测问题定位。
自定义监控指标及阈值,到达阈值后,也会自动停止压测。目前支持 CPU、Memory、 上游稳定性、错误日志,以及其他自定义指标。
此外,除了 Rhino 平台自身提供的熔断机制以外,公司服务治理架构也提供了很多额外的熔断机制,如压测开关,一键切断压测流量;过载保护,服务过载时自动丢弃压测流量。
对于 HTTP 协议,参考了 Postman,全部可视化操作,保证所有人都能上手操作,极大降低了压测的使用门槛和成本。
对于 RPC 任务,Rhino 也自动完成了对 IDL 的解析,然后转换成 JSON 格式,便于用户参数化处理。
对于非 HTTP/RPC 的协议,以及有复杂逻辑的压测任务,Rhino 平台也提供了完善的解决方案——Go Plugin。
Go Plugin 提供了一种方式,通过在主程序和共享库直接定义一系列的约定或者接口,就可以动态加载其他人编译的 Go 语言共享对象,使得主程序可以在编译后动态加载共享库,实现热插拔的插件系统。此外主程序和共享库的开发者不需要共享代码,只要双方的约定不变,修改共享库后也不再需要重新编译主程序。
用户只要根据规范要求,实现一段发压业务逻辑代码即可。Rhino 平台可以自动拉取代码,触发编译。并将编译后的插件 SO 文件分发到多个压测 Agent。 Agent 动态加载 SO 文件,并发运行起来,就可以达到压测的目的。此外,Rhino 还针对常见 Go Plugin 压测场景,建立了压测代码示例代码库。对于压测新手,简单修改下业务逻辑代码,就可以完成压测了。这样就解决了非常见协议,以及复杂压测场景等的压测问题。
压测调度的最小单元是压测 Agent,但是实际每个 Agent 中有挂载多种压测引擎的,来支撑不同的压测场景。Rhino 平台在压测数据和压测引擎之间增加了一个压测引擎适配层,实现了压测数据与压测引擎的解耦。压测引擎适配层,会根据选择不同的压测引擎,生成不同 Schema 的压测数据,启用不同的引擎来完成压测,而这些对用户是透明的。
在压测引擎上,我们有开源的压测引擎,也有自研的压测引擎。
开源压测引擎的优点是维护人多,功能比较丰富,稳定且性能好,缺点就是输入格式固定,定制难度大。此外 Agent 与开源压测引擎之间通常是不同进程,进程通信也存在比较大的问题,不容易控制。
自研压测引擎,优点是和 Agent 通常运行在单进程内,比较容易控制;缺点可能就是性能稍微差一些。但是 Golang 天然支持高并发,因此自研和开源之间的性能差距并不明显。
由于公司监控系统,最小时间粒度是 30s,30s 内的数据会聚合成一个点。这个时间粒度对于压测来说是比较难以接受的。因此,Rhino 平台自己搭建了一套客户端监控系统。
服务端监控,直接接入了公司 Metric 系统。
在压测过程中,Rhino 平台还可以实时采集目标服务进程的性能 Profile,并通过火焰图的方式展示出来,方便用户进行性能问题分析和优化,如图。
Rhino 压测平台是一个面向全字节跳动公司的,为了所有研发同学提供的一站式全链路压测的平台。Rhino 平台的研发团队,不仅负责 Rhino 平台的研发任务,还会配合 QA&RD 来完成公司大型项目,重点业务的性能压测工作。
公司内重大项目的压测,Rhino 平台都会积极参与,全力支撑的。其中,比较典型的项目有抖音春晚,西瓜百万英雄,春节红包雨等活动。
其中字节春节红包雨活动,完成是由 Rhino 团队来负责和完成的。字节春节红包雨活动是在春节期间,所有字节客户端发起的,诸如抽卡分现金,红包锦鲤,红包雨等一系列的超大规模的红包引流活动。其流量规模巨大,流量突发性强,业务逻辑和网络架构复杂度高等等,都对 Rhino 平台提出不小的挑战。
在春节红包雨活动中,所有用户流量都经过运营商专线接入到网络边缘的汇聚机房,然后经过过滤和验证后,再转发到核心机房。其中各个 IDC 互为备份,其具体流量路线如图。在这里,不仅要验证后端各服务是否能承载预期流程,还要验证各个专线带宽,各个网关带宽及转发能力,各 IDC 承载能力以及之间带宽等等。
为此,我们将整个压测拆分成多个阶段,来简化压测复杂性,也降低压测问题定位的难度:
在这些大型项目的支撑中,Rhino 团队不仅学到了大量的业务和架构设计知识,还了解到业务研发同学如何看待压测,如何使用平台,帮助我们发现更多平台的问题,促进平台不断迭代优化。
日常压测支撑,也是 Rhino 平台非常重要的一项任务。对于日常压测中遇到的各种问题,我们采用了各种方案来解决:
Rhino 平台还实现了线上流量的定期调度,以达到线上实例自动压测的目的[8]:
其具体实现方案如下:
目前已经有 500+微服务接入,每天定时执行流量调度,来监控线上服务性能变化趋势,如下图。
Rhino 平台目前还在公司内推行常态化压测,通过周期定时化的自动化全链路压测,来实现以下目标:
目前 Rhino 平台上的常态化压测,会周期定时,以无人值守的方式,自动执行压测任务,并推送压测结果。在压测执行过程中,会根据调用链自动完成压测开关开启,发起压测流量。实时监控服务性能指标,并根据 Metric 及告警监控,自动完成压测熔断,以保证压测安全。
目前已经有多个业务方接入常态化压测,以此保证线上服务的稳定性。
服务在上线时,都会经过预发布,线上小流量灰度,线上全量发布。在这个过程中,我们可以通过线上测试 Case 以及灰度发布,来拦截服务线上功能缺陷。但是对于性能缺陷的拦截,却不够有效。
从线上故障跟踪系统里就可以发现,由于上线前没有做好性能压测,很多性能缺陷都逃逸到了线上。
为了拦截各种性能缺陷,Rhino 平台完成了 DevOps 平台的打通。将压测服务在 DevOps 平台上注册成一个原子服务 ,研发人员可以将压测节点编排在任意流水线的任意位置,实现上线前的例行压测。DevOps 流水线中的压测,不仅可以帮助 RD 发现代码中的性能问题,还能与性能基线进行 Diff,来发现代码性能变坏的味道。
Rhino 压测平台从立项到现在,不到两年的时间内,其发展已经初具规模,如图(每月压测执行统计)。这个期间,非常非常感谢公司内所有合作团队,尤其是架构团队,中台团队对压测平台的支撑,没有他们的支撑,全链路压测建设是难以完成的。
通用压测平台已经初步搭建完成,基本上能满足业务线日常压测需求。但在日常压测支撑过程中,发现不同业务线在压测时,但是仍然有大量的前置和后继工作需要人工来完成。
如何更进一步降低业务方压测改造的成本,如何减少压测环境数据预置成本,如何快速完成压测数据清理,如何快速定位出性能问题等等,Rhino 压测平台后续将更进一步深入业务,与各大业务方开展更深入的合作,提供更深度的业务定制,为研发提效,助力业务线发展。
业务目前资源是否充足,其具体容量是多少;按照目前业务增长,其机器资源还能支撑多久?
目前服务资源利用如何,是否可以优化,如何更进一步提升资源利用率,降低机器资源成本?
某大型活动,需要申请多少资源?是否不需要压测,或者自动化利用线上流量数据,或者利用日常压测数据,就可以给出上述问题的结论?
如何保证服务稳定性,如何监控服务性能劣化并及时预警,限流、超时、重试以及熔断等服务治理措施配置是否合理?以及如何配合混沌测试进行容灾演练,保证服务稳定性等等,这些 Rhino 平台都会做更进一步探索。
目前 Rhino 团队还非常小,非常缺少性能测试以及后端开发相关的研发工程师,欢迎感兴趣的同学来加入。简历投递邮箱: tech@bytedance.com ;邮件标题: 姓名 - 工作年限 - Rhino 。
[1] http://jm.taobao.org/2017/03/30/20170330/
[2] https://testerhome.com/topics/19493
[3] https://tech.meituan.com/2018/09/27/quake-introduction.html
[4] https://tech.meituan.com/2019/02/14/full-link-pressure-test-automation.html
[5] https://www.open-open.com/lib/view/open1484317425690.html
[6] https://www.infoq.cn/article/NvfJekpvU154pwlsCTLW
[7] https://tech.bytedance.net/articles/3199
[8] https://www.usenix.org/conference/osdi16/technical-sessions/presentation/veeraraghavan