美图是如何搭建压测监控一体化平台的?
美图架构平台团队的主要工作,是给业务提供技术支撑,保障业务的稳定性;在减少故障方面,架构团队和 SRE 团队有比较紧密的配合和较多的实践。此前美图 SRE 团队也在 TakinTalks 稳定性社区分享了故障治理方面的经验和实践;今天换个角度,从架构团队视角,围绕压测平台的搭建,分享美图 2.409 亿月活用户的稳定性保障经验。
作者介绍
美图系统研发技术专家-陈潮兵
TakinTalks 社区专家团成员,2018 年加入美图,系统研发技术专家。目前在美图负责 Java 基础组件和配置中心、压测平台等服务,同时负责内容中台、订阅中台等中台项目。积极参与公司的架构演进,在服务高可用、稳定性保障方面有一定的经验和积累。
温馨提醒:本文约 5000 字,预计花费 8 分钟阅读。
后台回复 “交流” 进入读者交流群;
背景
起因:全年最严重的故障
2019 年的跨年夜,我们的业务出现了严重故障——由于对节假日的流量预估不足,跨年夜当天,美图核心服务出现了稳定性问题,整个故障持续了接近 2 个小时,是美图全年唯一的一次 A 级故障。
改进:加速压测平台建设
故障的原因有很多方面,根本原因我认为是当时对于节假日流量的增长没有做好预案,导致流量突增时,一些基础资源出现了瓶颈,进而导致大面积故障。在后面的故障复盘里,我们除了做链路优化和性能优化之外,还推进了一项措施,即通过线上压测来保障我们的节假日场景,做到故障的提前发现和跟进。
效果:可靠性被大规模验证
在那之后,每次大型节假日之前,我们都会进行线上服务压测,包括 2019 年的美图业务整体上云,我们也是依赖线上压测,在云上部署新服务后拷贝 IDC 的真实流量去压测,提前发现并修复了很多稳定性问题,最终我们的上云进展非常顺利。也就是,从跨年夜故障后,我们的服务再也没有出现过类似的问题了。
上面案例讲到了我们在稳定性方面的重要利器,即美图自研搭建的压测平台,我将结合一些搭建思路和压测实践给大家详细介绍。
一、压测要满足哪些业务诉求?
上面图里 9 月 10 号这天是今年的中秋节,可以看到这天我们服务的 QPS 比平常大了好几倍。美图公司有一个很重要的特点,就是节假日的流量特别大,比如说元旦、端午、中秋、国庆等节假日,节假日流量的峰值是日常流量峰值的好几倍,因为在节假日大家会有更多的照片美化、视频美化的需求。
下面是美图日常的流量情况。
大家可以看到在非节假日的时候,我们日常的场景也会存在流量突增的问题,但是整个时间其实就没有节假日那么长,它可能持续半小时左右,这种一般是由运营活动带来的。
所以美图的业务场景,总结来讲有两个,一个是节假日流量比日常大好几倍,第二个是日常流量存在突增的问题。
针对节假日流量大,日常流量突增的业务特点,要怎么去保障业务的稳定性呢?我们是通过压测来模拟复现这类场景,然后提前发现系统瓶颈,推动业务优化。
1.1 真实流量压测
在考虑如何做压测的时候,我们面临了一个问题——要采用哪种方式来进行压测?搭建一套拟真的环境,还是在真实环境上直接压测?我们的考量点是这样的——
首先,线上服务之间的依赖很复杂,调用链路众多,搭建拟真环境的难度其实是比较高的,投入会比较大。
然后,如果搭建了拟真环境,就需要在多套环境之间保证环境之间的一致性。
其次,就算能保证多套环境上部署的代码一致,但是实际上不同环境的时间还是会有差异,比如说服务依赖的网关、底层资源等等,都是会存在差异。
最后,如果只在拟真环境压测,压测成功没有问题,那线上就没有其他问题吗?这个答案其实也是否定的。
所以主要是出于拟真环境的搭建成本和维护成本,我们最后选择拷贝真实流量直接压测真实环境,基于真实流量拷贝回放是可以解决线上已有服务的压测问题的。
1.2 场景化压测
当然真实流量拷贝只能解决已有服务的压测问题,对于还未上线的服务是怎么做的?这种情况下我们一般是通过自己编排场景的需求,就是自己去编排压测场景,去构造压测流量来进行压测,我们会把这种称之为场景化压测。
所以我们的诉求是除了真实流量压测之外,还有场景化压测的需求。之前真实流量压测(拷贝线上真实流量做回放),这部分主要是由运维团队负责,自定义编排压测场景(场景化压测)主要由测试团队负责。
二、之前的压测是怎么进行的?
2.1 早期流量回放压测实践
首先是早期的流量拷贝回放的场景,下面图里是我们之前的做法。
这种压测方法,虽然可以简单地满足业务需求,但是压测过程中的主要步骤,都需要人工介入。
比如拷贝流量,需要运维先梳理这次要压哪个服务,然后找到对应服务的域名、对应域名的负载均衡机器是什么,再去起一个流量拷贝的服务,之后还要看好时间,定期去关掉这个服务,再把拷贝的流量文件做保存。在压测的时候,需要根据压测计划,手动申请施压机来进行扩容。如果压测过程中遇到压力不稳的问题,需要人工介入排查,人工去定位是什么问题导致的。
更要命的是,在压测过程中,如果被压服务出现了性能瓶颈,那这时候需要运维及时介入来停止压测。如果业务本身有降级手段还好,万一业务对应的降级措施,这时候只能依赖运维介入来做降级,那就很依赖运维的及时响应,如果运维响应不那么及时,可能就会导致因为压测造成了线上故障。
2.2 早期测试部门业务压测流程
对于自定义编排压测场景的压测,下面图里展示了我们之前的做法。
这块之前主要是测试团队负责,对于测试同学来说,首先他们需要去编辑压测脚本,然后在压测时,测试需要自己去申请施压机,然后在施压机上部署脚本去执行压测,压测结束之后他们还要自己去收集一些压测数据,观察被压服务有什么问题,有什么告警等等。整个过程其实对于测试同学来说比较复杂,执行一次压测的成本很大。
三、压测平台目标解决哪些问题?
针对早期的这些压测方法,我们总结了当时在压测方面的一些痛点,主要有下面几点——
压测的全部流程都需要人工介入,不管是在拷贝流量,或者施压机申请,压力调节,包括遇到问题怎么排查,以及最后整理报告,这些都需要人工介入。
因为人工介入的成本高,自动化程度其实就很低,压测效率低导致没办法去开展常态化的压测,所以之前一般是在大型节假日之前,我们才会做大规模的线上压测,日常没办法开展压测,因为太耗人力了。
除了压测效率的问题,我们其实还面临稳定性的问题。压测过程中我们经常会遇到压力不稳的问题,这类问题的定位比较困难。
所以总结来讲,我们有成本、效率、稳定性相关的问题,我们期望通过建设压测平台来进行优化,对于要建设的压测平台,我们有三个重要的目标——保证系统稳定性、提升效率、控制成本。
四、搭建压测平台的核心是什么?
上面说了我们期望去建设压测平台来解决我们的痛点,那下面我将会给大家介绍我们怎么去搭建压测平台。
4.1 压测流程
从系统搭建的角度,我们回顾一下压测的主要流程。
我认为压测流程主要有三个,在这三个流程中,我认为施压的部分是搭建压测平台的核心,因为它属于中间的部分,串联了压测的其他模块。
4.2 压测核心-施压机
4.2.1 选型前的思考
我会给大家介绍在施压机选型方面的一些考量点,首先在进行施压机选型时,我们考虑了几个问题——
施压机要具备哪些能力?
到底是要自研还是要借鉴社区的开源工具?
要怎么去面临技术选型的问题?
4.2.2 施压机能力
对于施压机的能力,结合压测场景,我梳理了我们认为施压机要支持的一些核心的功能。
支持 RPS/VU 压测模式:RPS 模式其实就是每秒请求数,VU 是指的是虚拟用户模式。简单讲一下这两个模式就是, RPS 模式是可以精准地控制服务打出来的压力,可以控制压测平台每秒打出来多少请求。这种模式一般是用在服务端的性能优化。比如说这个中秋节,要压的是日常的峰值的三倍或五倍,设定好压测目标之后,我们会设计好一些压测梯度,通过 RPS 模式来进行压测。VU 模式是指的虚拟用户模式,一般是用来探测系统的最大的并发数,就是系统能支持多少并发量,这种一般是用在客户端应用多一些,主要是用在客户端应用的一些压测。
支持不同压测协议:比如我们有 HTTP 的压测需求,同时也在做服务化的建设,所以还会有 RPC 的压测需求, DBA 团队、运维团队他们也有诉求,希望能够直接去压测 MySQL 和 Redis 实例,所以也有压测基础资源的需求,就需要压测平台能够支持不同的压测协议。
支持串联场景压测:对于测试团队来讲,他们一般是要自己去定义压测场景,所以需要支持一些串联场景的压测,就比如先登录再购买等等,会希望能串联起来做压测。
支持压测结果断言:对测试同学来说,他们还希望压测完去设置断言,即需要知道运行的结果对不对。
支持压测数据上报:我们需要知道施压机和被压服务的状态,所以我们需要能够支持把压测数据上报到监控平台。
支持压力调节:可以根据施压目标动态调节施压机的压力。
支持压测启停:对于施压机,我们需要能够控制施压机什么时候启动、什么时候停止。
4.2.3 选型机考量及对比维度
在选型时,我们主要会基于开发成本、扩展性、维护性这三方面来做对比。
对于施压机我们有比较多的功能诉求,在业界已经有比较成熟的实践,所以没有必要重复造轮子,所以我们着重考虑社区已有的工具来建设压测平台。我们挑选了一些社区活跃度高,且在业界有相关实践的压测工具来进行学习对比。
我们从开发语言、是不是支持分布式压测、能不能支持场景编排、能不能支持流量复制/回放、有没有压测报告、压测性能等等方面来做考量。
从上面的这个表格,能看到匹配度这几个都满足;团队熟悉度方面,测试团队基本之前都是用 JMeter 压测,JMeter 的开发语言跟团队技术栈匹配,JMeter 支持自己开发插件,业界也有一些公司有类似成功的案例,所以对于美图公司来讲,我们最终选型了 JMeter 作为施压机。
我们选型的时候就会发现 JMeter 其实存在一些问题,比如它的分布式部署成本高、施压机监控不完善、脚本维护不方便等等。而对于这些问题,我也会介绍我们是怎么去解决的。
4.3 其他关键问题
除了施压机之外,搭建压测平台其实还要考虑一些其他的关键问题。
首先是单机压力的调节问题,我们使用 JMeter 作为施压引擎,在 JMeter 之上去封装施压机,提供类似施压机启停、压力调节这些能力,通过这些能力来控制施压机的行为。
对于刚才上面有提到 JMeter 施压机分布式能力弱的问题,我们是自研调度中心来解决,后面也会给大家介绍在这方面的一些实践。
另外 JMeter 实际上有提供压测报告,但是 JMeter 监控告警能力比较弱,我们基于美图的监控平台,通过改造 JMeter 上报压测指标,来实现监控数据的打通。
对于分布式的压测来讲,会面临施压机的扩缩容问题,单机一定会有瓶颈,那么是一次性扩容好还是按需扩容、怎么去扩容?这里我们是去对接容器平台。美图有一些基础设施,而容器平台它恰好就能解决这种扩容缩容的问题,我们就把这些能力交给容器平台来做,只要去对接他们就好了。
JMeter 它的流量拷贝能力弱,这一块怎么做?我们选型了 GoReplay 来拷贝流量。选 GoReplay 主要是因为使用简单,组件性能高,GoReplay 在拷贝流量时,对负载均衡影响很小。
五、压测平台架构是怎么设计的?
我们把美图的压测平台整体是分成了四部分,首先有一个管理模块,我们把它称之为 PTS-WEB。这个管理模块里面主要有两个功能,一个是配置的管理功能,它能管理各种任务,比如流量拷贝的任务,或者是压测场景的任务、定时的任务,这些都由管理模块管理。
第二个是它会负责任务的调度。比如触发流量录制、触发压测都是由这个管理模块来触发的。这个管理模块底层数据会存储在 MySQL 和 Memcached 中,压测报表和流量文件,会存储在 OBS 中,服务底层会依赖容器平台,这个是管理模块的主要结构。
为了解决流量拷贝的问题,我们在 GoReplay 上封装了一个 Agent, 把它称为 GoReplay Agent ,是在 GoReplay 上提供了管理能力,可以通过这个 Agent 方便地控制什么时候启动流量拷贝任务,拷贝哪些流量、哪些端口、拷多久、什么时候停等等,都是在 GoReplay Agent 实现的。最后拷贝完的流量,需要去做协议的转换,最后上传到存储服务里,这些都是通过 Agent 实现。
那有了流量之后,在压测的过程中我们怎么做?在启动压测的时候,每一个压测场景的执行其实都是会起一个压测集群来负责。压测集群包括了两部分,一个是调度中心,一个是施压集群。这个调度中心我们称之为 PTS-Master ,施压集群里边的每一个施压节点,我们把它称之为 PTS-Slave,它就对应了施压机,然后 PTS-Master 对应调度中心,调度中心是用来管理一组施压机,这个是大概的一个关系。我们底层压测引擎这一部分用了 JMeter 的能力,在这个施压机之上,我们封装了像快速启停、快速调整压力的这些能力。
同时,施压机这边会去跟监控告警系统对接,通过施压机上报压测指标,上报到监控报警中心。施压机会给调度中心上报节点信息,会上报它的健康状态、预期的压力是多少、当前实际压力多少等等,然后会由调度中心来负责整个压测任务的压力调节,这个就是压测平台的一个主要的模块。
(美图压测平台展示-创建压测)
(美图压测平台展示-发起压测)
(美图压测平台展示-发起压测)
以上是美图压测平台的部分页面展示,那么在实际操作中——
1、GoReplay 如何和 JMeter 结合?
2、平台中需要开发哪些插件来辅助?
3、实操中遇到了哪些问题以及如何解决?
更多内容欢迎点击“阅读原文”,进入「TakinTalks 稳定性社区」,观看完整版视频内容。
了解更多美图压测平台细节,欢迎扫码进入「读者交流群」,和老师实时互动。
六、个人总结
最后我用两个词来概括搭建压测平台的最主要的经验——
第一个是合作共赢,要跟兄弟团队合作做资源的整合。
第二个是拥抱社区,上面我们很多的经验,是借鉴了社区的一些优秀的方案和实践,我们在社区的方案上去自研并做自己的优化。
如果能拥抱社区,基于前人的基础上搭建平台,能让我们少走很多的弯路。
回复【2202】获取讲师课件
回复【交流】进入读者交流群
声明:本文由公众号「TakinTalks 稳定性社区」联合社区专家共同原创撰写,如需转载,请后台回复“转载”获得授权。
版权声明: 本文为 InfoQ 作者【TakinTalks稳定性社区】的原创文章。
原文链接:【http://xie.infoq.cn/article/33d19e6121055e6198f17c4fe】。文章转载请联系作者。
评论