淘系技术部的全景

录制回放机制诞⽣之后，淘系技术部解决了全景回放的第一个问题，即流量自动录制回放，下面淘系技术部就来解决第二个问题，即全景的获取。首先，淘系技术部先思考两个问题。第一个，将所有的线上流量连续录制很长一段时间，得到的全部流量是不是就是全景。答案是约等于，理论上录制的时间越长，越接近于全景，但不可能等于。第二个，通过这种方式获取的全景是不是可接受的。答案是不可接受，准确地说是投入产出比不可接受，这样的全景中包含了大量的重复场景，而这些重复场景需要占用大量的存储空间和排查时间。那么淘系技术部需要在全景和成本之间寻求一个平衡，淘系技术部在尽量保障全景的情况下，去掉重复场景，去掉的方法就是利用行调用链路识别技术对场景进行去重操作。

2017年，淘系技术质量在JVM-Sandbox的基础上，利用LineEvnet实现了行调用链路识别和标记的模块，即JVM-Sandbox-Trace(尚未开源)，该模块有效地提升了回放的精准度和效率，降低了全景回放的成本。

1. 全景到链路的蜕变

首先需要明确行调用链路这个概念，一次请求依次走过代码行，可以得到一个有序的类和行号组成的链路，即行调用链路。对于两个不同的请求，淘系技术部如果行调用链路是相同的，则认为是同一场景。在这一原则下，淘系技术部采集一段时间内请求的行调用链路信息(以下简称链路)，并计算其唯一值，然后通过唯一值进行去重操作。每个唯一值，即代表一个场景，当收集的时间够长时，收集的场景可趋近于全景，淘系技术部可以简单地称其为链路式全景。通过收集链路的方式获取的全景将自带链路热度的属性，其可以帮助淘系技术部区分场景的重要程度。如图所示的是链路获取与热度分析图示。

链路获取与热度分析

2. 链路到全景的演进

那么，是不是链路就等于全景了呢，答案当然是否定的，为了尽量接近全景，淘系技术部还需要对链路全景进行扩充和缩容。

（1）  参数式全景扩充

链路全景只是趋近于全景，在实际的业务中，存在行调用链路相同，参数不同，则场景不同的情况，所以需要根据参数对链路式全景进行扩充。扩充的方法一般有2种：按照参数信息(入参或返回值)进行扩充、智能化扩充。淘宝天猫用得比较多的是第一种，第二种方法尚处于探索阶段，所以淘系技术部详细介绍这种方式。

利用录制回放里的参数信息，对同一链路进行扩充，并补充不足之处，即对于同一个行调用链路，当某个参数不一致时，不对链路做去重操作。这种情况多发生在具有规则引擎的应用中，规则引擎多为非Java代码，无法进行行调用链路收集，需要通过这种方式进行扩充。

（2）  特殊全景扩充

这里的特殊场景指的是通过短时间录制无法采集到的场景，例如，异常流，或者像双11预售业务这种在特定时间内才会使用的业务。为了降低全景获取的成本，这些场景最好是由淘系技术部测试人员在测试环境中进行录制，然后加入到全景里。

（3）  无效全景缩容

链路全景还存在场景重复的问题，比如，一个100次的循环，第1次循环与第99次循环没有差异，那么在采集的过程中就会存在98个场景是重复的问题。针对重复场景，需要对采集的链路数据进行处理，然后再计算链路全景。

完成上述扩充和缩容操作之后，淘系技术部得到了一个投入产出比可接受的近似的全景。与录制回放结合之后，淘系技术部就可以做全景回放了。

3. 全景的用途

（1）业务梳理与识别

·        梳理：利用接口、参数、链路的信息制定规则，对全景进行自动打标。

·        识别：对未被标记的场景进行业务识别，制定新的规则，对全景进行自动打标。

规则积累得越多，业务逻辑就会越清晰，这样就可以完成一次业务梳理。

（2）场景重要程度分析

行调用链路不仅能够获得场景，还可以统计行链路的热度，如果链路的热度越高，那么这个链路就越重要，越是需要重点保障。