首次面向B端展开全链路压测！淘系高难度压测实践方案公开

2024-08-02 17:16:03

达海、追溯淘系技术

背景

“今年的双11是全球极大内容电商场的超级爆发，消费者、技术、内容与商业生态之间每一秒都在产生激烈共振，实时性、复杂性和持续峰值的叠加令其成为全球技术顶峰。2020年双11，阿里巴巴峰值交易达到了58.3万笔/秒，其背后的商家链路也承受着史无前例的压力”阿里巴巴副总裁汤兴如此描述今年的双11。

阿里商家业务域涉及集团近20条业务线，100多个场景，400+链路，部分业务深度融入在导购、交易链路中。商家链路业务涵盖淘系的上千万商家及数百家核心三方服务商的伙伴。以往由于平台和商家IT基础设施存在“水位差”，平台很难帮助商家进行系统的改造升级和全链路验收。随着阿里面向商家与生态伙伴推出了新一代数字化基建体系，借助云原生技术引擎与云IT治理能力，帮助商家与生态伙伴重构系统的高可用基线，使得越来越多的商家具备了和阿里同等量级的超大规模数据处理能力。

常规备战中各个业务依靠单链路压测，缺少互通联动，缺少全局把控，容易有质量盲点，隐患容易被忽视，风险较高。商家链路出现问题，直接影响商家生产经营能力，对商家和消费者造成重大的体验伤害。业内的全链路压测普遍面向C端场景，B端场景往往重视度不够。商家端的场景结构极其庞杂，涉及内部系统还涉及众多三方系统，开展全链路压测面临着诸多挑战。为有效预防风险，提升各个业务以及三方合作伙伴系统稳定性，提升用户体验，今年我们克服了重重困难首次面向商家链路开展了全链路压测。

挑战

▐ 核心难点

商家业务涵盖商家工具、消息、多媒体、算法等多种业务形态，各应用间调用错综复杂，如何理清核心链路的依赖，保障核心链路不遗漏是开展压测的首要挑战。

压测实施上，如何模拟数百个场景流量的叠加耦合，并留好应对突发情况的操作空间，且在同一时间批量将流量拉到峰值是压测执行的一大挑战。

商家业务涉及众多合作伙伴服务商的系统，阿里生态的复杂性，使得接入阿里平台的服务商系统架构存在异构化、多样化、性能差异大等多方面技术挑战，每个服务商对于稳定性的认知存在差异。

▐ 解决方案

针对上述挑战，我们的核心解决方案为：

统一流程规范标准、压测组织协同、统一验收复盘。
工具支撑压测一体化。
压测涵盖预案、限流、演练、监控等内容，模拟大促真实情况。

全链路压测方案

1、统一流程规范

各个业务参与全链路压测明确准入准出标准。全链路压测的基本准入原则：每个场景单链路压测通过后才能进入全链路压测。准出标准包括：系统水位、流量比例、响应时间、缓存命中率、限流、jvm指标等。服务商系统与阿里系统标准一致。

流程上统一进行场景review、链路评审、全链路压测以及复盘，复盘中的问题同步优化解决。

2、工具支撑一体化

在集团已有的压测能力基础上，我们重点在商家链路分析，流量评估，压测模型、结果校验自动化等方面建设一站式压测工具，解决商家全链路压测的核心问题。

链路分析

压测场景选取的基本原则：

大流量场景
核心链路场景
复杂业务链路场景
流量扩散场景。

参照以上原则，在我们在集团中间件支持的基础上，开发了链路分析场景推荐工具，用人工+工具check双保险的方式进行链路模型生成。示意原理如下图，应用A某接口的一次调用，我们可以获取其下游应用的trace，访问的数据库或者缓存，并且分析出1次调用对下游流量的放大。

链路示意图

其工作流程如下：

统计流量调用的服务，存储等指标，获取对下游的调用次数，得到对下游请求的放大。
获取流量大于某阈值的入口链路。
获取调用链路深度或者依赖调用大于某阈值的链路。
获取翻倍调用大于某阈值的链路。

流量评估

常规流量评估通常是根据监控和上游调用来评估接口流量，评估比较理想化，容易产生误差。如果前期流量预估不充分，会导致压测无法达到目标或远超目标值，靠压测来发现这些问题成本太高。对此我们引入了深度机器学习，利用算法能力来做智能预测，更加精确的进行流量评估。其主要的工作原理如下:

抓取应用的出入口流量、RT、QPS、错误率、应用系统水位等信息。
应用深度机器学习，对基础数据进行分析学习，产生该应用的算法模型。该模型可以根据入口流量，预估出口流量、应用系统水位等信息。效果如图所示。

接口流量模拟对比图

其核心思想为:

算法每天根据线上真实数据持续学习，持续优化，生成可靠模型。
用户输入接口预估流量，平台输出预估的下游接口流量、存储QPS、机器数和系统水位等信息。

模型构建

结合业务场景，我们建立了两种压测模型：0点模型和非0点模型。0点模型涉及场景在大促0点流量达到峰值，非0点模型场景峰值则在其他时间达到峰值，压测模型的设计不是简单的覆盖业务，还需要考虑各个业务之间的流量耦合。有上下游关系的链路，下游的压测流量也是来自上游。除了考虑商家域内的流量耦合，还要考虑集团其他域的流量耦合。因此，与之配合的还有非常多的压测预案，用以控制压测流量的准入准出。

有流量的耦合就要考虑耦合流量不足的情况，不是每次压测上游都会有充足流量打到下游。在保障能够耦合上游流量的同时，下游业务自身还要具备流量补充能力，当来自上游的流量不足时，自身可以补充足够的流量，满足自身系统的验证。

3、压测执行

压测数据准备采用淘系技术质量部自研凤凰平台[见附1]录制线上流量做“平移”，场景数据更加真实有效。录制化也提升了数据准备的效率，一次录制多次使用。场景管理上做到了1人1键执行所有的场景，极大的节约人力。每次全链路压测商家和交易、导购都会同步开展，0点流量全部打到100%，以验证跨业务域的流量依赖和叠加的情况。从压测开始到流量拉到100%时间非常有限，在压测初期，这个过程中通常会伴随着⾮常多的问题。这些问题在前期准备过程中很难发现，主要问题有以下⼏类：

压⼒分布不均。
模型紧急调整。
数据⽂件紧急修正。
个别压测机异常。
受压测管控影响，服务调⽤受限。
压测任务紧急管控。

执行⼈员需要⼀边控制不受影响的业务继续按计划加压，同时需要迅速对出现的问题作出判断，给出解决方案。对于能够快速修正的场景，⾸先将其从压测活动中单独摘掉，调整完成后重新关联到压测任务中。对于⽆法快速修正的场景，要迅速协调业务同学进⾏单链路操作。受上述问题影响，现场需要制定不同的应对策略，主要包括以下几种情况：

压测过程中某个场景需要紧急卸载压⼒，其他场景保持。
压测过程中某个场景没有达到⽬标，但系统资源已经出现瓶颈，需要保持压⼒⽔位排查问题，其余业务继续加压。
压⼒拉到100%个别业务没达到预期需要继续增加压⼒。

这⼏类问题在前期压测过程中出现频率⾮常⾼，如果前期准备不到位会阻塞压测节奏。

此外全链路压测具备从客户端（成功率、错误量、舆情等）到服务器（接口成功率、中间件成功率、水位等）的完整监控体系，避免出现只关注到服务可用性而忽视客户端及用户实际体验受损的盲区。

在数百个商家全链路压测场景中，消息、开放、小程序是几个典型的非常规压测场景，压测实施难度大，接下来重点介绍一下这几个场景的全链路压测实践。

▐ 核心场景1: IM消息体系的端到端全链路压测

传统服务端压测通常是http或者tcp类型的短链接压测，也就是客户端请求一次，拿到返回后，连接就关闭了。但是这种方式并不适用于IM消息系统的压测，IM的系统与服务端建立的是长连接，用户A发送消息给用户B的时候，用户B是被动收到服务器的推送，而不是主动拉取数据，这个模式对压测的实施非常有挑战。

为了解决这个问题，我们基于NIO开发了手淘和千牛的瘦客户端，模拟真实用户与服务端保持长连接在服务端，并将部分业务逻辑做了参数化，集成到了瘦客户端中。比如瘦客户端在收到消息推送后，回复ACK，表示收到了消息，并且根据已读比例对该消息进行已读设置。

长连接瘦客户端

消息链路压测需要模拟客户端登录后保持长连接，目前业内常规压测工具对消息场景都不适用，需要独立开发工具。核心方案如下：

开发瘦客户端集成到压测引擎中模拟端到端的场景

模拟消息回复
模拟消息已阅读
模拟消息漫游

压测引擎部署到CDN节点上模拟真实用户收发消息
创建长连接模拟用户真实保持长连接在线

长连接压测架构图

全链路消息业务打通

消息全链路除了包含消息上下行，消息已读未读，消息内容模型（文本、卡片、多媒体消息），消息漫游等基础消息业务，也在集团二方和合作伙伴三方中衍生出了如机器人智能辅助、订单核对，修改地址，智能客服等消息业务。

消息业务图

由于消息业务的复杂性，导致我们在压测的时候需要协调各个业务方的压测数据，来调整实际压测时各业务方的压力。例如某个账号开通了A业务也开通了B业务，发送给该账号的消息走到了两个业务，导致流量叠加，最后的压测结果不准确。为了解决这一问题，我们统一收口了消息业务压测脚本，通过统一分配账号，通过统一开通业务，统一发起流量等方法，解决了流量叠加互相干扰以及各业务线脚本无法复用等一系列问题。

▐ 核心场景2: 三方服务商全链路压测

淘系电商业务是一个覆盖消费者、平台、商家、三方服务商的生态链路。借助平台开放的接口，三方服务商可以开发出客户管理、订单管理、互动营销等方向的电商支持工具，帮助商家提升运营效率。要实现商家全链路保障，就需要驱动并赋能三方服务商一起参与到全链路压测中来。

淘系电商生态交互图

订单推送全链路压测

在涉及三方的众多场景中最核心的是订单场景，订单推送全链路覆盖了消费者在淘宝下单后到收到货物的整个过程。链路涵盖多个内外部系统，直接关系到消费者的购物体验，压测重要性不言而喻。

订单推送全链路交互图

订单推送全链路压测面临以下痛点：

服务商数量众多，没有统一的压测工具。
压测订单模型构造难度大、准确性差。
压测结果收集困难，数据分析工作量大、标准不统一。

为此我们开发了订单推送全链路压测平台赋能服务商，平台具有以下特点：

基于历史订单数据一键生成压测模型，方便、精准

用户只需指定历史订单的起止时间，系统会自动分析该时间段内的线上订单数据，并根据订单的买家、优惠、商品等信息模拟生成压测订单模型。

订单推送压测模型

压测结果数据自动收集、分析，全面、直观

工具会自动从监控数据中收集相关压测指标，在报告分析阶段跟历史数据进行比对、根据压测标准计算出压测质量分、产出压测结论、给出优化建议。

订单推送压测报告生成示意图

支持Service Mesh技术，生产环境压测更简单、安全

压测平台支持云原生的Service Mesh技术，对于生产环境压测改造只需修改POD节点的相关配置，无需对系统业务代码进行改造，大大降低生产环境压测成本，同时减少代码改造可能带来的安全风险

▐ 核心场景3:三方小程序压测

小程序是淘系在APP端开放的重要形式，由于三方小程序集成在手淘、千牛等淘系APP中，其稳定性关系到淘系APP的稳定和用户体验。受技术和安全上的限制，三方服务商无法自主对小程序接口进行线上压测，为此我们开发了小程序压测平台为服务商伙伴们提供高效、易用的官方压测工具。

三方小程序压测平台使用简单、易上手、自动化程度高，大大降低了技术门槛和服务商的压测成本，其核心能力如下：

系统根据线上接口流量自动分析、创建、下发压测任务。
服务商只需编辑压测参数，执行压测任务即可。
压测通过并提交报告后，系统会根据压测流量值设定限流保护值。

三方小程序压测流程图

此外，我们还组织了头部核心服务商联合预演。通过全链路压测，模拟业务峰值流量，演练了各种应急预案和沟通机制，以应对大促中可能出现的异常和突发状况，形成了压测、封网、预演的完整保障链路：

在全链路压测的同时对核心三方小程序进行压测，模拟更真实的双十一环境。
在压测的同时进行异常情况演练：人工模拟引入问题、故障。
对问题、故障进行紧急处理，演练沟通、协同机制和应急处理流程。

总结

全链路压测期间总计发现130+内部系统问题，大促前所有问题都得到了有效解决。整个大促期间商家业务系统0故障、商家问题反馈较往年降低了50%，商家以及消费者感受到了如丝般顺滑，捍卫了商家利益与体验。

一百多家核心的ISV参与了全链路压测验收，全链路压测帮助商家与生态伙伴重构了系统的高可用基线，使商家在信息处理和数据处理的水平上，和淘宝拉到同一个水位，使得商家具备了和阿里一样的超大规模数据应用能力，帮助商家系统发现并修复上千个性能问题，在效率和能力上大幅度提升商家系统稳定性。

未来我们计划将在三个方面持续优化，为商家和合作伙伴提供更优质的服务：

1、基于算法能力的智能化压测。

2、场景、预案、限流、压测结果等全方位的自动化分析。

3、多维度监控、海量告警信息的智能分析定位处理。

附1：

凤凰生态利用JVM-Sandbox提供的统一底层能力，大家奇思妙想产生模块原子能力生态，提供开放、快速的模块开发、管理、鉴权、部署能力(魔方平台)，通过对模块能力的组合，衍生出录制回放、故障注入、强弱依赖梳理、系统Mock、快速问题定位、测试质量评估等上层产品模块(凤凰平台2.0)，并对各个环节产生的数据、标准能力都开放API和能力，在业务回归、攻防演练、架构治理等领域输出方案，致力于快速、高效的提升系统整体稳定性。

开源地址：

https://github.com/alibaba/jvm-sandbox-repeater?spm=ata.13261165.0.0.11ee30bfW4qEoF

JVM-Sandbox属于基于Instrumentation的动态编织类的AOP框架，通过精心构造了字节码增强逻辑，使得沙箱的模块能在不违反JDK约束情况下实现对目标应用方法的无侵入运行时AOP拦截。