精准测试之分布式调用链底层逻辑

作者：京东工业 宛煜昕

概要： 1. 调⽤链系统概述； 2. 调⽤链系统的演进； 3. 调⽤链的底层实现逻辑； 4. Span 内容组成。

⼀、分布式调⽤链系统概述

客户打电话给客服说：“优惠券使⽤不了”。 -客服告诉运营⼈员 --运营打电话给技术负责⼈ ---技术负责⼈通知会员系统开发⼈员 ----会员找到营销系统开发⼈员 -----营销系统开发⼈员找到 DBA ------DBA 找到运维⼈员 -------运维⼈员找到机房负责⼈ --------机房负责⼈找到⼀只⽼⿏ ，因为就是它把⽹线咬断了。

分布式架构所带来的问题

定位⼀个问题怎么会如此复杂？竟然动⽤了公司⼀半以上的职能部⻔。但其实这只是当我系统变成分布式之后，当我们把服务进⾏细粒度的拆份之后的⼀⼩部分问题，更多问题在哪⾥？⽐如： 1. 开发成本增加。 2. 测试成本增加。 3. 产品迭代周期将变⻓。 4. 运维成本增加。

问题产⽣原因

在传统制造业，分⼯越精细，专业化程度越⾼，产能就越⾼。⽐如⼀台汽⻋平均将近 3 万个零部件，来⾃全球各个供应商，最后再由汽⻋⼚商统⼀拼装检测出⼚。不仅⼤件是精细分⼯完成，⼩件也是如此，在浙江温州 有⼀个打⽕机村，⼀个⼩⼩的打⽕机⽣产，是由 20 多个⼚家协作完成，有的做打⽕机燃料有的做点⽕器。

反观软件⾏业，这种精细分⼯很难实现， 你⻅过哪家某个系统是由⼗⼏家企业协作完成的么？你觉得淘宝的电商系统可以让⽇本⼈去开发 购物⻋模块、让法国⼈实现评论模块、让印度⼈去实现下单功能、美国⼈实现商品模块，最后在由中国⼈拼装整合？究期原因再于三个字：“标准化”，刚说的汽⻋3 万个零件，每个都有其标准化规格，所以才能够顺利的拼装成品，但软件组成很难标准，就连开发个接⼝都没有指定标准，就连⼀个规范都难于推⾏。没有标准化，不能分⼯协作，那怎么实现软件的⼤规模⽣产呢？就是⽤更多的⼈，更多⼯作时⻓去冲抵。软件开发就此成为⼀个劳动密集型产业，新⽣代信息化农⺠⼯群体诞⽣。这对企业⽽⾔是不利的，因为它要为信息化付出更多的成本。所以相应管理办法与开发⼯具都要升级，管理办法是类似于敏捿开发、⼯程师⽂化建设、开发形为准则。另外⼀个就是⼯具：⾃动化构建、⾃动化部署、⾃动化运维、⾃动化扩容等、线上链路监控等等。

分布式链路监控的作用

1. 定位线上问题； 2. 分极性能问题； 3. 降纸软件复杂度； 4. 提供决策数据⽀持。

⼆、调用链系统的演进

⼀般我们认为链路监控产品是从 2010 年 Google 发表名为 《Dapper⼤规模分布式系统的跟踪系统》论⽂开始流⾏起来的。之后出现的很多开源或者闭源的产品都是以 Dapper 为理论基础。下表列出已知的链路监控系统。

链路监控系统列表

淘宝鹰眼 鹰眼界面

鹰眼架构

Google Dapper

Dapper 界⾯

Dapper 架构图

开源链路监控

三、调用链系统的底层实现逻辑

调用链系统的本质

⼀张⽹⻚，要经历怎样的过程，才能抵达⽤户⾯前?

⽹络传输层

负载均衡层

系统服务层

调用链基本元素

1. 事件：请求处理过程当中的具体动作。

2. 节点：请求所经过的系统节点，即事件的空间属性。

3. 时间：事件的开始和结束时间。

4. 关系：事件与上⼀个事件关系。

调⽤链系统本质上就是⽤来回答这⼏问题:

1. 什么时间？

2. 在什么节点上？

3. 发⽣了什么事情？

4. 这个事情由谁发起？

事件捕捉

1. 硬编码埋点捕捉

2. AOP 埋点捕捉

3. 公开组件埋点捕捉

4. 字节码插桩捕捉

事件串联

事件串联的⽬的：

1. 所有事件都关联到同⼀个调⽤

2. 各个事件之间层级关系

为了到达这两个⽬的地，⼏乎所有的调⽤链系统都会有以下两个属性：

traceID：在整个系统中唯⼀，该值相同的事件表示同⼀次调⽤。

spanD：在⼀次调⽤中唯⼀、并展出事件的层级关系

1、怎么⽣成 TraceID

2、怎么传递参数

3、怎么并发情况下不允响传递的结果

串联的过程：

1. 由跟踪的起点⽣成⼀个 TraceId， ⼀直传递⾄所有节点，并保存在事件属性值当中。

2. 由跟踪的起点⽣成初始 SpanId，每捕捉⼀个事件 ID 加 1，每传递⼀次，层级加 1。

trackId 与 SpanId 的传递

SpanId ⾃增⽣成⽅式

我们的埋点是埋在具体某个实现⽅法类，当多线程调⽤该⽅法时如何保证⾃增正确性？

解决办法是每个跟踪请求创建⼀个互相独⽴的会话，SpanId 的⾃增都基于该会话实现。通常会话对象的存储基于 ThreadLocal 实现。

事件的开始与结束

我们知道⼀个事件是⼀个时间段内系统执⾏的若⼲动作，所以对于事件捕捉必须包含开启监听和结束监听两个动作？如果⼀个事件在⼀个⽅法内完成的，这个问题是⽐较好解决的，我们只要在⽅法的开始创建⼀个 Event 对象，在⽅法结束时调⽤该对像的 close ⽅法即可。

但如果⼀个事件的开始和结束触发分布在多个对象或⽅法当中，情况就会变得异常复杂。

⽐如⼀个 JDBC 执⾏事件，应该是在构建 Statement 时开始，在 Statement 关闭时结束。怎样把这两个触发动作对应到同⼀个事件当中去呢（即传递 Event 对象）？在这⾥的解决办法是对返回结果进⾏动态代理，把 Event 放置到代理对象的属性当中，以达到付递的⽬标。当这个⽅法只是适应 JDBC 这⼀个场景，其它场景需要重新设计 Event 传递路径，⽬前还没有通⽤的解决办法。

上传

上传有两种⽅式

1. 基于 RPC 直接上传

2. 打印⽇志，然后在基于 Flume 或 Logstash 采集上传。

第⼀种相对简单，直接把数据发送服务进⾏持久化，但如果系统流量较⼤的情况下，会影响系统本身的性能，造成压力。

第⼆种相对复杂，但可以应对⼤流量，通常情况下会采⽤第⼆种解决办法。

四、Span 内容组成

Span 基本内容

在调⽤链中⼀个 Span，即代表⼀个时间跨度下的行为动作，它可以是在⼀个系统内的时间跨度，也可能是跨多个服务系统的。下图即是 Dapper 中关于 Span 的描述。

通常情况下⼀个 Span 组成包括： 1. 名称：即操作的名称，必须简单可读性⾼，它应该是⼀个抽像通⽤的标识，不能太具体。 2. SpanId：当调⽤中唯⼀ID 3. ParentId：表示其⽗Span 4. 开始与结束时间

端到端 Span

一次远程调用需要记录几个 Span 呢？

我们需要在客户端和服务端分别记录 Span 信息，这样才能计在两个端的视角分别记录信息。比如计算中间的网络 IO。

在 Dapper 中分布式请求起码包含如下四个核⼼埋点阶段：

1. 客户端发送 cs（Client Send）：客户端发起请求时埋点，记录客户端发起请求的时间戳

2. 服务端接收 sr（Server Receive）：服务端接受请求时埋点，记录服务端接收到请求的时间戳

3. 服务端响应 ss（Server Send）：服务端返回请求时埋点，记录服务端响应请求的时间戳

4. 客户端接收 cr（Client Receive）：客户端接受返回结果时埋点，记录客户端接收到响应时的时间戳

通过这四个埋点信息，我们可以得到如下信息：

客户端请求服务端的网络耗时：sr-cs

服务端处理请求的耗时：ss-sr

服务端发送响应给客户端的网络耗时：cr-ss

本次请求在这两个服务之间的总耗时：cr-cs

以上这些埋点在 Dapper 中有个专业的术语，叫做 Annotation。如果 Dapper 论⽂中的图示你还没有看太懂的话，那么可以再看看下⾯这张图，⽐较清楚的展示出整个过程。

参考

Dapper 论文：https://research.google/pubs/pub36356/

Dapper 大规模分布式系统跟踪基础设施论文：https://storage.googleapis.com/pub-tools-public-publication-data/pdf/36356.pdf