大咖简介

李子乐（太禅），阿里巴巴资深测试开发专家。毕业于浙江大学信电系。2010 年初加入淘宝，负责 PC 自动化测试框架的设计，包括淘宝全网 Web 自动化和旺旺客户端自动化等测试体系的构建，是淘宝开源自动化测试框架 automan 的架构和主要开发人员。从 2011 年接触无线，开始搭建团队，负责设计无线自动化测试框架，及无线自动化持续集成体系，并完成阿里第一套无线自动化框架 athrun 的开源。2013 年 all in 来往，后于 2014 年加入天猫，在持续交付与前后台测试方面均有丰富的经验。本次TICA，太禅老师作为工程效能分会场出品人，给大家带来阿里巴巴、京东、高德、爱奇艺等多个公司的优秀效能实践。

   11月3号午夜，位于西溪园区8号楼的六扇门项目室里灯火通明，汇聚于此的天猫和中间件的同学，将开启时光隧道，而时光隧道的另一端通往8天后，也就是双11当天。今晚，首批数千万用户将会通过这个时光隧道下单，在那个期盼已久的双11，完成自己购物车中的心愿。这就是全链路功能，一个通过创建隔离环境并修改系统时间，让亿级买家、千万级商品提前过双11，并观察核心交易链路上的功能可用性的项目。

全链路功能诞生记

   全链路功能项目也是源自于一次双11复盘，在双11预热期会场上线前的复盘会上，我们遇到了一个难题，如何保证核心系统的数据及功能完整性，如何验证活动商品在大促期间的功能。当时大促的验证有两种方式，一是在线上造一个测试活动，活动的配置与大促类似，但是开始时间比较早；二是在预发环境中把配置或代码中涉及大促时间的地方改成比较早的时间，在当前时间就可以测试大促时的逻辑，测完再改回来。但是这两种方式都无法保证完全覆盖大促期间功能的验证，测试活动与双11活动毕竟是两个活动，测试活动验证通过不代表线上肯定没问题，改配置或改代码又怕遇到评估不全的问题，靠人的经验总不放心。为此我们还整理了一套上线后能快速进行线上检验的工具，像预热会场在11月1号上线后，就赶紧跑一下，发现问题还能改，但仍然不能完全覆盖。

   这时我们就想，能否用类似全链路压测的思路。压测提前模拟了双11的系统压力，而我们也可以模拟双11当天的用户行为，模拟用户购买参加活动的商品，智能覆盖大促的各种业务场景。这样，线上检查和验证动作就可以提前，想想也真是挺爽的。然而如何进行双11用户行为仿真？又如何做到验证提前？接下来，让我们一起看一下全链路功能的系统架构。

全链路功能的架构与技术

数据同步系统

   为了对招商活动商品进行下单，但又不影响线上用户，全链路功能使用与压测相同的影子体系。但与全链路压测不同，全链路功能对数据的真实性要求更高，创建的影子数据必须与线上一一对应，而压测可以虚构一个压测商品，只要这个商品压力效果符合预期就可以。

   另外，大数据量的同步对性能有额外要求。为了满足性能需求，我们使用愚公系统作为数据同步方案。

• 首先，利用愚公的可定制转换功能，对数据安全敏感字段进行脱敏及偏移处理。
  
• 其次，利用愚公的白名单功能，只同步需要的用户关联及商品关联数据，避免全量同步数据过大对线上数据库容量造成威胁。
  
• 第三，全链路功能数据同步平台，提供入口供业务线参与维护表字段及表与表的关联关系。
  

   数据同步系统架构如图所示。数据同步平台在双11前实现了总量5000万级别的数据同步，操作的数据变更总量为65.3亿。共使用165台机器，在12个小时内完成同步。为支撑巨大数据量的同步，系统进行了针对性的设计，包括数据范围白名单计算上云、白名单数据分批装载、Groovy转换规则缓存速等。

模型系统

   假设线上用户集合为A，线上商品集合为B，那么这两个集合的所有可能的组合为集合A和集合B的笛卡儿积。对上亿用户和千万级商品进行笛卡儿积的运算是不现实的，我们开始沉淀合适的模型系统，对数据进行一定程度的抽象，用于生成合适的测试用例，如图所示。

• 识别数据特征
  

   电商的核心交易体系是非常简单同时又是非常复杂的。一个典型的交易过程，在普通用户的视角，就是选择自己喜欢的商品，下单支付。但这个过程因为用户使用权益的不同，购买商品的不同，内部走的逻辑是完全不一样的。先从简单的下单链路开始，抽象出买家、商品两个主要维度。买家可以按照会员等级、收货地分布等进行细分，商品又有所属类目、行业、业务类型、优惠等多个维度。这些结构化的信息称为数据特征。

• 数据筛选与组合
  

   基于数据特征向量表分别过滤商品与用户，然后随机组合下单。系统会有一张特征向量表来存储每个数据符合的特征情况，对于当前系统能识别出的全部特征，符合该特征就记1，不符合就记0。两个不同的数据基于这张表，针对每个规则情况计算差值并聚合，得到的这个值，就可以简单描述出这两个数据的差异情况。系统通过对该值设定阈值调控，就可以控制最终的用户和商品的产出量级。针对立即购买链路，我们会产出等量的用户和商品，然后一一对应进行下单。购物车下单则按预估的商品用户比，进行组合下单。

隔离系统

   提前过双11是全链路功能实现的核心诉求，是不是改时间就可以了呢？然而事情也并非那么简单，这里还有一个很大的风险，如果有线上流量进入，那么像优惠价格这类敏感大促数据就会泄露到线上去，提前按双11价格下单还会造成资损。因此，需要一套完全隔离的环境，然后在这套安全的隔离环境，让同步到影子体系的用户和商品提前过大促。

• 流量隔离
  

   15年隔离平台诞生，它创建了一套隔离环境支撑白天来做全链路压测。由于线上环境的复杂性，这时候还难免有一些线上流量进来，压测本身不改时间，用户也不容易发现有什么不妥。但在隔离环境如果改了时间后，这种情况就不允许再发生了。我们仔细梳理流量进入隔离环境的各个入口，包括前端入口、接口调用，消息入口，数据同步，定时任务。

为了保险起见，我们还开发了一个隔离环境流量大图，以准实时和离线两种方式展示隔离环境中的异常流量情况。此外我们还增加了兜底保护措施，在隔离环境的数据层TDDL和TAIR上增加异常流量拦截功能，避免产生脏数据。

• 时间控制
  

   对于时间修改，由于集团应用绝大部分部署的机型都是虚拟机，虚拟机无法单独修改系统时钟，修改实体机的时钟会影响宿主机上的所有应用。并且修改系统时间不仅会影响机器上运行的主应用，还会影响到机器上各种的agent等。我们改用修改JVM时间的方式来支持应用时间的修改。

   修改JVM时间，只影响Java的应用，而集团Java基础设施相对统一，隔离和保护也容易进行。阿里JVM团队针对修改时间的需求，在阿里JDK的最新版本中增加了根据参数控制JVM时间偏移的功能。应用升级到指定版本的JDK8之后，可以在应用启动时增加参数CurrentTimeSecondsDiff，参数值为提前的秒数，让Java应用的时间提前到未来的时间，修改是通过对JVM本地方法类库的修改来实现的，所以对于JVM所有获取时间的操作都可以生效。

构造执行系统

   在环境准备好后，便可以开始全链路请求的构造生成了，简单地说就是模拟用户访问确认订单页面，生成下单请求。确认订单页有两种来源，分别是购物车下单和详情页立即购买下单，两种请求的生成比例按线上真实的比例2.6 : 1分布。下单的客户端又分为PC和无线，也按线上真实比例分布。购物车下单的时候，因为旅行、商超、生鲜的商品需要分开下单，在遇到这些商品跟普通商品混合的时候，会优先选取这些特殊的购物车类型。构造系统会选取用户可用的四级收货地址（具体街道地址经过脱敏），选取最优惠的卡券和红包，按比例使用天猫积分和淘金币。并按不同的交易类型，填写构造过程中出现的必填项，如手机号，服务门店选取，以确保流程的畅通。但在此过程中，还是会不可避免地遇到一些目前还没有支持的链路，如村淘、处方药等场景，因此构造系统还会把构造失败的请求场景记录下来，供后续进行失败原因的分析。

   在生成了请求链接后，上传数据到压测平台进行执行。执行系统与全链路压测差别不大，获取用户集进行登陆，然后带着traceid批量发起请求，以方便出错后根据traceid进行问题定位。与压测不同的是，这批数据只跑一次，不需要反复循环地跑。

分析系统

   千万级商品与亿级买家的执行结果，不会像自动化用例的校验一样做那么细。根据大数据的特点，全链路功能的分析系统分为以下几个模块。

• 错误码分析
  

阿里电商交易系统第二版(buy2)，对各种类型的错误场景，定义了一套错误码规范。不同的出错系统与出错原因，都会给出不同的错误码与相应的解释，并保存这份标准化的错误日志到特定文件。这给分析系统的设计带来了极大的便利，系统可以根据traceid在这份特定的文件中查找有没有出现错误码。

利用阿里内部成熟的一站式日志服务解决方案，我们快速搭建了服务器端日志数据采集及流式处理的平台，将符合条件的日志记录回流到全链路功能系统。

• BCP分析
  

   BCP是阿里实时业务审计平台，自2014年上线以来，BCP已经在双11当天发现多起由于数据一致性问题导致的资损或故障。每年双11各个业务线都会针对自己的功能场景，在BCP上维护最新的校验规则。

   全链路功能与BCP平台深度合作，每条BCP规则都可以定义是否需要在全链路功能中触发校验，经业务线评估支持影子链路的双11核心核验规则，都会勾选这项。在全链路功能运行的时候，会告知BCP启动针对当天运行方案的记录，运行完后，再通知BCP停止针对该运行方案的分析。然后全链路功能通过调用BCP接口，获取在此期间的所有BCP分析结果。

• Response分析
  

   我们使用压测平台提供的请求结果分析功能，对下单请求结果进行简单的校验，如果成功跳转到支付页面，就意味着下单成功。如果没有跳转到支付页面，就记一笔失败。用于与错误码结合使用，验证两种校验方式的数据一致性。由于response非常大，全部回传会给系统带来极大压力，我们的优化方案是只传输特定查找路径下的元素，将该页面元素的内容返回。从而，在提供可供问题排查的页面元素数据的同时，兼顾了数据传输的性能。

全链路功能总结

   在全链路功能实施的第一年，一共发现3个Bug，其中双11提前发现2个Bug：

1) 6.18大促bug：在6·18时，我们进行了第一次基于规则模型的运行，发现1个Bug：10个以上带“送货入户”服务的商品购物车下单，会错误地创建出多个送货上门子订单，下单页会在一个子订单上面同时展示四五个“送货入户”服务。

2) 双11大促bug：在双11前夕，我们在11月3号凌晨、11月4号凌晨，运行两次。发现两个Bug，都是正常的功能测试不容易发现的。包括淘宝海外直邮商品类型和苏宁易购商品类型，在高并发、服务超时等异常情况下，走容灾逻辑的时候，由于返回服务错误和数据不全加上配置不对，导致容灾逻辑无法生效，阻断了下单。

全链路功能是阿里巴巴第一个基于大数据、基于电商交易链路规则建模，进行大促功能可用性验证的项目。随着智能化和智慧化的深入人心，全链路功能搭建并经过验证的基础能力，包括影子数据同步能力、规则模型分析归类输出能力、隔离环境提前验证能力等，正在被越来越多的创新项目依赖和使用，成为创新的源泉。