轻松应对双11,大促保障利器Takin助力中通完成系统维稳任务

2021年11月26日 阅读数:2
这篇文章主要向大家介绍轻松应对双11,大促保障利器Takin助力中通完成系统维稳任务,主要内容包括基础应用、实用技巧、原理机制等方面,希望对大家有所帮助。

中通快递做为国内知名综合物流服务企业,已连续5年稳坐行业市场份额榜首。受双十一、618等大促活动影响,井喷式的业务流量对中通的系统稳定性提出了更高的要求,过去的压测方案已经没法知足业务发展的需求。测试环境等比缩放致使压测失真、庞大且复杂的系统链路梳理等都是棘手的问题,让咱们一块儿看看中通是如何利用大促系统稳定性保障利器Takin来完成这项艰巨的任务的。java

背景

目前在中通性能测试主要分为线上和线下压测两种方案,在反复实践过程当中咱们渐渐发现这两种方案都有着各自不足之处,且为压测工做带来了不少不便。如下就线上和线下压测的不足分析,谈谈中通是如何一步步改进压测方案并解决问题。web

  1. 线下压测方案中的不足

在线下压测试过程当中,为了减小与真实环境物理资源上的差别,公司采起的是针对CPU与内存进行等比缩放的策略,若是是计算密集型应用,线上环境总的CPU核数为80,线下压测环境总CPU核数为8核,则为10:1的线上线下等比缩放策略,若是是IO(目前只看内存)密集型应用,线上内存总量若是为80G,线下压测环境内存总量为8G,也一样是10:1的线上线下等比缩放策略。 很明显这种等比缩放策略在高TPS目标的压测场景下会失真,TPS目标越高,则失真越严重,由于咱们并不能对网络、中间件、数据库等一系列的因子也一样作出等比缩放。redis

  1. 线上压测方案中的不足

在线上压测时,多以读接口为主,只有至关少许的写接口会作线上压测,这少许的写接口一般也须要被压应用的开发人员进行代码改造,以免大量的压测数据对业务数据形成污染。 因此这种线上压测方式没法大范围应用,同时这种对代码硬改造的方式,也增长了压测成本与风险,致使你们一般不肯意面对线上压测,更不用提联合上下游一块儿进行线上全链路压测了,而这种不敢在线上大量压测的思惟,也致使更多压测被放在线下以等比缩放的方式进行,其后果则是压测结果的失真,在2012年,某厂正是由于测试环境等比缩放压测,致使网络流量数据失真,引起了线上故障,才促使其下决心走上了线上全链路压测的道路。数据库

  1. 引入技术解决方案

由于有上述问题,公司引入了线上全链路压测产品,其特色是使用压测JavaAgent探针以字节码方式植入应用,这样业务应用则无须硬编码,就能够自动识别和兼容压测流量,并进行分流,将缓存和存储数据存储到影子区域,实现物理隔离压测数据,避免形成生产数据污染,就技术方案上看,线上全链路压测产品最核心的功能其实就是两点:流量染色与保障数据安全,示意图以下: 压测流量链路示意图bootstrap

全链路压测部署&核心配置

  1. 线上全链路压测agent安装部署
  • 将pradar-agent.zip包上传到须要接入应用所对应的服务器/home/admin目录下,并直接解压.
  • 修改对应应用的启动脚本( 一般在发布平台中修改),将修改后的后面这个命令添加到java -jar xxx.jar 的-jar以前( -javaagent:/home/admin/pradar-agent/agent/pradar-core-ext-bootstrap-1.0.0.jar -Dpradar.project.name=该应用应用名 )
  • 从新启动应用 在pradar-web操做页面的应用管理页,查看是否成功上报: 在这里插入图片描述

agent安装彻底成后,在具体实施时,若是压测入口是http接口,则在请求头中带上“User-Agent:PerfomanceTest”,若是入口是dubbo接口,则在AttachementArgs中带上“p-pradar-cluster-test:true”,agent会将这类请求自动识别为压测流量,它会将压测标识向下游应用传递,并将数据分流到应用所配置的影子资源中,例如redis的影子key、影子数据库(表)、rocketmq上配置的影子TOPIC及消费组等等,由此将压测数据与正式数据进行隔离,避免了压测数据对正式业务数据的污染。缓存

  1. 主要影子资源的配置

缓存redis的影子资源,在探针识别为压测流量时,会自动对要写入或者查询的key前加上"PT_"前缀来进行数据隔离,而MQ的TOPIC与消费组影子资源,须要在公司的ZMS配置中心,按业务TOPIC与消费组名称,去新增出带"PT_"前缀的TOPIC与消费组名便可。数据库资源的配置会复杂一些,下面单独说明。 影子库配置以下图所示: 在这里插入图片描述tomcat

影子表配置以下图所示,都是把业务表名前加上“PT_”来表示为影子表,多个表使用逗号分隔: 在这里插入图片描述安全

  1. 挡板的配置

在线上压测时,有可能会触发到资金扣款或者短信发送等敏感方法,若是大量的压测触发了这类方法,轻则形成骚扰,重则发生严重的资损,相似这样的方法,咱们则须要在梳理压测链路时进行识别,并为此类方法加上挡板(Mock),以下图示例,如此当压测探针识别到压测请求(有压测标)时,则会执行咱们针对此方法所配置的Mock代码,若是是正式的业务流量(无压测标),则仍然会执行原来的短信发送方法而不受影响。 在这里插入图片描述服务器

链路接入与压测流程

作线上全链路压测,不少人担忧的一个问题就是,线上生产环境就这么直接压,不怕出问题么,那么除了进行错峰压测之外,中通压测团队为了安全有序的进行线上全链路压测,通过两期接入项目的摸索,已经造成了一整套保障安全压测的实施流程,流程图以下: 在这里插入图片描述网络

全链路压测能够大体分为三个阶段: 1.需求定义与链路梳理阶段; 2.测试环境部署及测试阶段; 3.线上压测及结果产出阶段。

  1. 需求定义与链路梳理

需求定义

  • 明确压测的具体业务链路与范围边界
  • 明确压测的目的,是达到指定性能指标,仍是摸高进行容量规划
  • 具体的性能指标,tps(每秒请求数)/rt(响应时间)/成功率/SA(以99%为例,指99%的请求响应时间都在设置的rt范围之类,也就是RT的达标率)

链路梳理 链路梳理是全链路压测最为重要也是最核心的环节,一般这个环节的质量,将影响全链路压测的总体实施效率。接下来详细说一下,链路梳理的目的步骤与须要拿到的关键信息

链路大图 首先须要梳理出链路调用大图,刚开始不须要太细,但须要对入口/出口/应用名/数据库/缓存/中间件/资金影响/邮件/短信等,相似这样的一些关键信息能梳理到,由于保密手册的缘由,具体的链路图,这里就不放出了,能够用本文最上面的《压测流量链路示意图》进行脑补。

详细信息收集操做手册 根据上面梳理的梳路大图,进一步明确具体细节,须要收集以下信息:

  • 应用基础信息与部署信息 在这里插入图片描述
  • 链路模块-指的是此次需求所肯定的压测链路
  • 应用名-应用名称,在jvm中设置时-Dpradar.project.name的value内容
  • 应用负责人-通常为应用的主开发人员
  • 运维-能够进行agent安装包上传与安装,并查看agent相关日志的系统运维人员
  • 测试负责人-此应用的测试人员
  • DBA-能够进行数据铺底,影子库表建立,数据库性能监控的DBA人员
  • 性能指标-本次压测的目标
  • 应用的调用链类型与接口-指的是在全链路压测中,本应用在整个链路调用中所通过的接口方法名,以及对应的接口类型,在了解这个信息时,应该要了解清楚这些接口方法的做用与逻辑,以此判断出是否须要对其加挡板(mock),是否须要进行一些测试数据初始化的准备工做。
  • 启动容器-例如tomcat或者jar方式直接启动
  • 实例数量-主要是对测试环境与线上环境的实例实进行统计,须要全部实例所有安装agent,否则可能致使压测数据流入到正式的数据库表中。
  • 应用入口信息与相关依赖信息

在这里插入图片描述

  • 入口-压测的入口
  • 数据库jdbc链接信息-主要是数据库的类型,链接的域名(或者IP),端口,数据库名称,用户名与密码等相关的信息。
  • 用到的表-发起压测后,调用流经到该数据库时,会读哪些表,会写哪些表,数据逻辑是什么,都须要搞清楚,以方便判断怎么造出测试数据,是用影子库方式仍是用影子表方式。
  • 文件路径-是否会在读写文件的相关信息.
  • redis预设值-发起压测后,调用流经redis的业务与数据逻辑,好比面单的单号是从redis中读取的,则咱们能够根据压测量,在单号存放的redis中预设(铺底)一批测试单号数据,注意对于redis中预设测试数据,须要考虑过时时间,另外测试数据的key键是在正式的key值前加上PT_来做为影子key。
  • mq的topic-若是涉及到mq,则须要创建影子topic与影子消费组,方法都是在正式的topic与消费组前增长PT_来做为影子topic与影子消费组,须要特别注意的是,影子topic/影子消费组与正式的topic/消费组都须要在同一个集群。
  • es索引-在正式的es索引前,加上PT_做为影子索引.
  • hbase-正式表前加上PT_做为影子表.
  • 不良影响-在明细信息收集过程当中,须要梳理出此应用是否会有产生实际的资金/电话短信邮件/网安数据上报等一系列,有可能因压测而形成的不良影响,针对这些不良影响的调用方法,则须要以加挡板mock的方式绕开。

至此,整个链路的业务,技术,数据信息都已经了解得基本清楚了,那么在这个基础上,则能够参考上一节中《全链路压测部署&配置》相关的内容,在测试环境将整个全链路压测环境给部署与配置稳当。

  1. 测试环境调试

全链路压测,向上追述,通常老是能找到一个页面或者APP入口,那么必然对应着一个http的接口,因此为了表示这个请求是全链路压测的影子请求,须要在http头中增长User-Agent:PerfomanceTest,若是入口就直接是一个dubbo入口的话,则在dubbo的Attachment Args里增长key:value为: p-pradar-cluster-test:true 在这里插入图片描述

当咱们在测试环境观察到压测流量都按咱们的预期,落入了相关的影子资源,而没有发生数据落入正式资源的状况后,咱们能够在测试环境进行少许数据的压测,若是一切正常,咱们就能够开始着手进入线上环境的压测流程了。

  1. 线上压测及结果产出阶段

准备阶段

  • 提早准备线上必须的影子库表,铺底数据,影子topic/影子消费组创建等须要DBA与运维部门支撑的前期事项。
  • 提早在pradar-web操做页面的应用管理页对应用的相关配置进行配置操做。
  • 按照《中通-全链路压测上线计划模板.xlsx》编写上线计划,并召集相关人员(运维,DBA,开发,测试,项目PM)评审,提早约定灰度上线,全量上线,试跑压测用例,正式压测的相关时间节点。 在这里插入图片描述

灰度验证 将agent安装包上传到相关应用的其中一台机器上,若是有预发机,最好是上传到预发机器,而后由开发在发布平台中修改jvm配置,配置好agent相关的参数,从新启动灰度机器,观察12小时以上日志,是否正常。

全量上线与试跑 若是灰度没有问题,则通知运维,将agent安装在应用的全部机器,全量重启目标机器。 若是一切正常,则可使用压测脚本进行线上试跑了,试跑方案应在上线计划中提早规划好: 在这里插入图片描述

正式压测

  • 压测场景配置

注:压测试场景配置最好在灰度发布后,就开始进行 在pradar-web操做页面的系统流程中建立一个流程(一个入口只须要建立一次): 在这里插入图片描述

在操做页面的“业务活动”中建立一个业务活动,并与上面的“系统流程”进行关联 在这里插入图片描述

在“压测管理”->“压测场景”中,建立一个压测场景,在业务活动中,将上一步中建立的业务活动增长进去,能够增长多个业务活动,以代表同时压测多个活动的场景,若是有数据文件且数据不能够重复使用的状况,能够选择多个IP后,对此csv数据文件勾选“拆分”操做,最后还须要关注的是正式压测,须要使用“阶梯递增”模式,则您的Jmeter脚本中须要以"bzm-Concurrency Thread Group"方式建立线程组。 在这里插入图片描述

  • 压测执行

确认了压测时间与相关人员后,编写压测计划,并通知到相关人员按计划执行,同时要特别注意压测入口域名是否受到CDN与防火墙的流量限制,若是有,须要提早找运维与网络的支撑人员将压力机IP加入白名单。 一切准备就绪,则按计划执行压测便可,在“压测场景”中点“启动”,正式发起压测。

压测结果 以某场景为例获得以下压测报告: 在这里插入图片描述

漏数检测 除了通常性能测试都要进行的监控之外,进行全链路线上压测试时,最大的区别是咱们大量使用了影子数据库表,影子数据库表用于与正式数据库表进行测试数据的隔离,且压测数据咱们都会加上识别标识,好比PT开头的订单号都是压测数据,但由于各类缘由,大量的压测数据可能会致使部份或者所有压测数据被错误的写入了正式数据库表,从而污染了真实环境的数据,致使各类生产故障,所以有必要实时的检测是否有测试数据被错误的写入了正式数据库表,以便及时的中止压测行为,并快速对进入正式库的错误数据进行清洗纠正,将损失降到最低。为此,咱们本身基于对数据库binlog的监听,设计了一套能实时监控压测数据对生产数据形成影响的工具,原理图以下: 在这里插入图片描述

全链路压测实践的思考

使用压测探针方式进行线上压测以来,咱们已经在订单,运单,面单等多个业务共62个应用中进行了接入,成功支持了双11&618大促与淘宝&拼多多等大流量联合线上压测的场景,虽然初步能解决原来压测中存在的问题,但也引入了一些新的问题。

  1. 组织与工做模式问题

先看看某大厂BU进行全链路线上压测的简化版组织及工做模式架构图: 图一

中通全链路线上压测组织与工做模式图: 图二

全链路压测系统接入几乎牵扯到整个产研团队的各个方面,须要开发、测试、运维及供应商等团队充分配合协同工做。 图一中某大厂因为订单全链路压测属于公司级重点项目,由上至下的推进相关系统改造和统一协调资源,各项目由开发负责人挂帅,开发、测试、运维相互配合,性能团队属于支撑团队,负责压测方案评审、工具支持、压测问题记录与答疑。 图二中咱们的模式,全链路压测属于部门级项目,由性能测试团队负责主导,对接各方推进接入工做,其余相关方属于配合工做人员,性能测试团队须要协调各方资源,工做难度较高。

  1. 其它问题

手工操做过多,自动化程度过低,好比探针的版本控制与部署,施压机的自动建立与分配等。 流程推动线下化,没有造成统一管理的配置项、检查项、评审等流程在线化推动。 测试脚本与测试数据在线化统一管理及可复用程度底。基本靠压测人员自行维护。 压测所积累的结果数据,没法在线造成压测基线自动化对比,没法达成压测结果在时间线上的可视化统计与分析。

最后

中统统过引入全链路压测,的确解决了原来压测环境等比缩放压测的失真问题,可是,在面对整个在订单,运单,面单等多个业务共62个应用的压测,单从上下游数据层面交互就是一项复杂的工做,另外还须要各个环节的人员协做等、工做量及复杂度是可想而知的。所以,此项工程并不是一天两天能所有解决的,路漫漫其修远兮,后面咱们还将经过发起性能专项创新活动,将公司性能测试整体价值推向更高阶的层次。