近期，由复旦大学CodeWisdom研究团队、eBay统一监控团队（UMP）和应用科研团队、北京大学软件工程研究所合作完成的论文《Graph-based Trace Analysis for Microservice Architecture Understanding and Problem Diagnosis》被ESEC/FSE Industry Track 2020录用。
这篇论文采用了基于图的思想对Trace数据进行了聚合和分析，提供了高效且丰富的Trace数据查询接口，然后在此基础上实现了多级别基本可视化、对比可视化和对比筛选过滤等功能以帮助解决企业中的架构理解和故障诊断等问题，该系统已在eBay灰度环境下部署并测试。
云原生时代，微服务架构因为独立部署、快速交付和灵活扩展等优点受到越来越来多企业的欢迎，但是天下没有免费的午餐，微服务架构在具有上述优点的同时也带来了新的问题。服务调用变得复杂而频繁，原来集中的日志数据分散在不同的实例或宿主机上，这使得使用微服务架构的系统在理解系统架构和诊断故障时比传统单体项目更为困难。
为了解决这个问题，微服务系统可观察性概念被提出，微服务可观察性一共有三个重要组成部分：Tracing，Logging和Metrics。其中Logging和Metrics目前已经有比较成熟和全面的利用方式，但是Trace的利用方式还比较简单。
如下图所示，两个服务之间的一次远程调用被视为Span，同一次请求产生的Span组成的有向无环图被视作一条Trace。
目前流行的开源分布式追踪系统如Zipkin，Jaeger，SkyWalking和PinPoint等大多基于单个Trace进行如下视图的可视化，以用于辅助开发或运维理解依赖关系和定位故障根因等。上面提到的这些工具在某些场景中确实很有用，但是随着系统规模的增加，Trace的数量指数级增长，即便经过采样Trace数据量变得非常巨大，这时就会遇到一些挑战。
为了解决这些问题，我们提出了GMTA和GMTA Explorer。GMTA采用基于图的思想对Trace数据进行聚合、处理和存储，提供高效的查询接口。GMTA Explorer在GMTA基础上提供了基本可视化视图、对比视图和错误链筛选视图等，难以理解业务、单个trace视图无用和难以定位根因范围等问题。
下图展示了GMTA的架构图，GMTA一共分为三个模块：处理模块（Processing）、存储模块（Storage）和访问模块（Access）。Trace数据在处理模块经过聚合和筛选，会被存储至存储模块。其中span数据会被存储到分析型数据库，聚合结果会被存储到图数据库中，访问层结合两种数据库对外提供多层次的高效的查询接口。
以一个例子来说明GMTA对Trace数据处理和存储的过程：下图中的小箭头代表一个Span，颜色相同的Span代表这些Span有相同的Trace ID，GMTA会先把Trace ID相同的Span拼接为Trace，同时寻找出有错误的Span组成的错误链。
然后会把路径完全相同的Trace聚合为一条Path，如图中的蓝色和黑色的两条Trace路径完全相同，被聚合为红色大箭头组成的Path，绿色大箭头组成了另一条Path。两条Path经过的一个Operation不一样。
在这个例子中，我们定义的Business Flow筛选规则是经过“createOrder”这个Operation的Path都属于购买场景，所以图中的两条Path被划分为了同一个Business Flow。
这个Business Flow对应的存储结构如下所示：经过聚合处理的span数据被存储在分析型数据库中，聚合得到的Path存储在图数据库中，通过ServiceName，OperationName和Path ID完成两个数据库的关联。
已经生成的Business Flow的信息也存储在分析型数据库中，当用户生成新的Business Flow时，会先在图数据库中完成匹配然后把映射关系存储到分析型数据库中。GMTA结合使用两种数据库的优势，可以提供多种聚合级别的数据查询，并且提高查询的效率。
下面这个表格展示了GMTA的四个主要功能以及与查询GMTA的数据的级别的对应关系，前两个功能基本可视化和变更可视化常被用于辅助架构理解，后两个功能异常对比和错误传播链查询常被用于辅助故障诊断。
架构理解下图展示了GMTA Explorer的基本可视化功能，图中方块代表Operation，颜色相同的Operation属于同一个服务，GMTA Explorer可以提供Business Flow、Path和Trace三个级别的可视化，图中的这个Business Flow一共有三个不同的Path，展开第三条Path可以看到这条Path对应的两条Trace。
接下来我们来看一看Business Flow的对比视图，在这个图里面方块仍然代表Operation，但是颜色代表平均耗时的变化，红色代表增加，绿色代表降低，颜色越深代表变化幅度越大，从Business Flow的合并视图可以明显地看出，新的时间段相较于前一个时间段Operation “coupon”升级到了“couponV2”。
基于这两个功能，架构师、开发或者SRE可以快速理解业务架构、依赖关系和具体的业务变更。
故障诊断下图展示了错误传播链的筛选功能。在微服务系统中，因为重试和异常处理机制的存在，很多错误并不会影响到用户使用就会被处理掉，这类错误被称为“软错误”，我们并不关心这类错误。有的错误会影响到用户使用，我们需要找到这种“关键错误”，但是关键错误往往淹没在数目巨大的软错误中，为故障排查带来很大的麻烦。
因此，GMTA Explorer提供了错误传播链的筛选功能，如上面这个图中当createOrder的指标出现异常时，可以借助GMTA Explorer筛选出相关的错误链，类似cuppon这种数量巨大的软错误就会被筛选掉，留下VerifyInventory这种关键错误，可以大大线上节省故障排查的时间。
GMTA Explorer提供的另一个功能是错误传播链的对比功能。
有时业务不可用了，但是错误指标湮没在了数量巨大的软错误中，导致无法确定故障排查的范围。GMTA Explorer可以对比故障时期和正常时期的错误传播链，展示在故障期间数量异常变化和新增的错误传播链，帮助开发人员或运维人员快速缩小故障排查的范围，提高故障排查的效率。下面这张图中红色字体的错误传播链就是故障时期新增或者数量变化较大的错误传播链。
实验和案例研究上面介绍了GMTA Explorer的主要功能，实现了GMTA和GMTA Explorer后，我们在eBay分别进行了实验验证和案例研究以证明GMTA和GMTA Explorer的有效性。
针对GMTA，我们设置了如下表所示的三个实验系统用于对比，其中OTD-R是常见的分布式追踪系统采用的方案：只支持最简单的Trace级别的查询; ATD-R是之前eBay实现的方案：把Trace聚合成了Path，但是没有采用基于图的存储，也没有实现Business Flow的筛选; 最后一个系统是我们所实现的GMTA。
然后我们设计了六个常见的使用场景，从下图结果可以看出，相较于OTD-R，ATD-R可以支持更多场景的查询，而GMTA可以支持所有场景的查询。这个结果说明了GMTA的有效性，它能够支持更多的查询场景。除此之外，有些查询场景虽然三个实验系统都支持，但是查询性能有所不同。
下图展示了根据指定Operation查询聚合Metrics的场景时，OTD-R和ATD-R的性能对比，因为我们使用的分析型数据库和图数据库都有热数据缓存的功能，所以查询性能按照冷和热分别展示。可以看出，ATD-R相较于OTD-R在冷查询时有65.6%的性能提升，在热查询时有24.1的性能提升。这说明聚合Path可以提升部分场景的查询性能。
下图展示了生成并且返回Business Flow时，ATD-R和GMTA的性能对比，从结果可以看出，不管是简单规则还是复杂规则，冷查询还是热查询，GMTA相较于ATD-R都有着很大的性能提升，这说明了基于图的存储结构对于查询性能的提升有着明显的帮助。上面三个系统的对比实验证明了GMTA的有效性和效率。
针对GMTA Explorer，我们为eBay监控团队和SRE团队提供了GMTA Explorer，对GMTA Explorer进行了验证实验。参与实验的一共有20名成员，其中7位是开发者，10位是SRE（Site Reliability Engineer），3位是架构师。30天后，我们对参与实验的人员进行了访谈，并且根据访谈结果整理了几个主要案例。
在参与实验的20人中：15人使用了GMTA Explorer帮助理解架构，包括2位架构师，7位开发者和6位SRE。其中13人认为GMTA Explorer相较于传统的Trace可视化工具可以提供更多的信息以帮助使用者快速理解架构和业务流程。12人使用了GMTA Explorer来理解变更，包括6位开发者和6位SRE。
其中8人认为GMTA Explorer可以有效地发现业务变更，这种变更采用其它方式很难发现和确认。11人使用了GMTA Explorer来辅助故障诊断，包括2位开发者和9位SRE。其中9人认为GMTA Explorer的错误传播链相关视图确实可以提高故障诊断的效率。
同时，我们也整理了一些使用GMTA Explorer的真实场景，接下来我们介绍其中两个真实案例。
第一个案例是一个开发者负责的业务严重依赖于另一个团队的业务，因此需要了解另一个团队业务的变更是否会影响到自己，他使用GMTA Explorer来对比了两个不同时间段内的Business Flow，从下图中可以明显看出，方框中深红色部分的Operation变更为了深绿方框中的Operation。
通过这个视图开发者了解了变更内容，并且通过点击方块查看了更多指标信息，确认了这次变更不会影响到自己的业务，他通过GMTA Explorer省去了和另一个团队交流的成本。
第二个案例是一个SRE收到了告警，服务A调用服务B的指标出现骤降，他需要尽快确定问题的根因，但是因为错误Trace数量实在太多，他查看了几条trace都没得到有效的信息，通过GMTA Explorer的错误传播链筛选功能，他通过筛选出的错误链确认了出现故障的根因不在服务A和服务B而在服务C，确定了故障排查的范围后，经过进一步排查发现最终问题根因是服务C的最近的一次发布引入了故障代码。
结论为了解决Trace数据量大和质量问题，我们实现了GMTA，采用基于图的思想，把Trace数据进行了修复并且聚合为Path,并进一步将其分组为Business Flow，并且寻找出错误传播链，结合分析型数据库和图数据库提供了三个层次的高效率的查询接口。
为了解决架构难以理解、单个Trace无用、根因难以确定等问题，我们在GMTA基础上实现了GMTA Explorer，提供了基本可视化，对比可视化，错误链筛选和对比等功能，帮助企业不同的角色来更好地理解架构和诊断故障。