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

前言：

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

分布式架构所带来的问题

分布式链路监控的作用

⼆、调用链系统的演进

链路监控系统列表

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

调用链系统的本质

调用链基本元素

事件捕捉

事件串联

事件的开始与结束

上传

四、Span 内容组成

Span 基本内容

端到端 Span

前言：

精准测试之分布式调用链是一种测试方法，用于验证分布式系统中各个组件之间的调用关系和性能。通过模拟真实的请求和响应流程，可以检测系统中的潜在问题和瓶颈，并进行性能优化。

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

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

分布式架构所带来的问题

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

问题产⽣原因

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

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

分布式链路监控的作用

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

⼆、调用链系统的演进

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

链路监控系统列表

公司	系统名称
Google	Dapper
阿里巴巴	鹰眼
腾讯	天机
百度	凤睛
京东	CallGraph，hydra
美团点评	CAT(Central Application Tracking)
美团	MTRace
链家	LTrace
苏宁易购	Hiro
Uber	Jaeger
Twitter	Zipkin
网易	Pylon
个人开源	PinPoint
Apache	Apache SkyWalking

淘宝鹰眼 鹰眼界面

鹰眼架构

Google Dapper

Dapper 界⾯

Dapper 架构图

开源链路监控

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

调用链系统的本质

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

⽹络传输层

负载均衡层

系统服务层

调用链基本元素

事件：请求处理过程当中的具体动作。
节点：请求所经过的系统节点，即事件的空间属性。
时间：事件的开始和结束时间。
关系：事件与上⼀个事件关系。

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

什么时间？
在什么节点上？
发⽣了什么事情？
这个事情由谁发起？

事件捕捉

硬编码埋点捕捉
AOP 埋点捕捉
公开组件埋点捕捉
字节码插桩捕捉

事件串联

事件串联的⽬的：

所有事件都关联到同⼀个调⽤
各个事件之间层级关系

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

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

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

1、怎么⽣成 TraceID

2、怎么传递参数

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

串联的过程：

由跟踪的起点⽣成⼀个 TraceId，⼀直传递⾄所有节点，并保存在事件属性值当中。
由跟踪的起点⽣成初始 SpanId，每捕捉⼀个事件 ID 加 1，每传递⼀次，层级加 1。

trackId 与 SpanId 的传递

SpanId ⾃增⽣成⽅式

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

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

事件的开始与结束

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

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

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