Blog.6 分布式会话跟踪系统架构设计与实践

调用链trace系统能够帮助技术人员快速的定位问题，查看整个请求的调用链路，及各个链路的耗时状况。方便技术人员针对性的对服务进行性能优化。

概念

参考调用链trace的设计分析的介绍，trace系统的要素包括：traceId、spanId、annotation。

1. traceId：贯穿整个调用链路，经过traceId来关联链路的全部相关日志
2. spanId：标识单次请求调用
3. annotation：记录请求调用的附加信息

简化trace日志设计

在调用链trace的设计分析文章中，系统log设计相对复杂，先从最简单的入手开始了解。

微服务A、B、C之间存在相互调用关系，咱们为每次请求记录一条log。经过log中的parnetID来肯定调用的层级关系，经过spanID来惟标识一个独立请求，经过traceID来收敛全部相关日志。最终就能够肯定请求的调用层级结构。

从SERVER-C能够看出，日志记录在C服务的总处理时间。在结合SERVER-B的发起请求时间，能够初略得出span2的网络耗时。

特别注意一下span的变化。当向下游服务发起请求时，须要生成一个新的span，并将该span的父节点设置成上一步生成的span。SERVER-B请求SERVER-C描述的就是这个过程。

而当服务收到一个请求时，只有当请求没有关联新的span时，才须要生成一个span。SERVER-C收到SERVER-B的请求，描述的是这种状况。

Other日志设计

调用链trace的设计分析文章又是如何实现的呢？文章给出的调用关系以下：

二者的区别在于：肯定层级的方式不一样。这里经过span值的建立规则来肯定调用的层级。而前者是经过借助parentID来肯定层级。

Annotation

经过基于Zipkin的Thrift服务RPC调用链跟踪文章了解到，存储span信息能够经过Annotation和BinaryAnnotation来实现。

Annotation用于记录某个时间点发生的event，对event的触发时间、类型有明确规定。而BinaryAnnotation则用来记录用户自定义的信息。也就是说：前者是公用的，后者是我的用的。

由于反向代理路径重写的缘由，客户端请求的path和服务端提供服务的path可能不相同，若是你想在系统中定位这种状况，那么你就能够将http.url追加到BinaryAnnotaion属性中。

了解一下BinaryAnnotation日志存储的数据内容：

{
    "app": "app", //所属应用
    "ip": "ip", //ip地址,冗余信息
    "key": "key", //key, 能够设为存储用户session的key, 若是是用来传递用户session信息的, 能够统一约定为: session_id
    "mname": "mname",  //方法名
    "pid": "10000", //进程id,冗余信息
    "sid": "sid", //spanId
    "sname": "sname", //服务名
    "tid": "tid", //traceId
    "timestamp": 1449038780194, //产生的时间戳, 长整型, 精确到毫秒
    "type": "type", //类型,用来区分是记录异常的仍是业务流程的等等, 默认是'common'便可
    "value": "value" //若是是传递用户session信息 ,能够直接写在该字段中.
}

参考地址：

1. 调用链trace的设计分析
2. 分布式会话跟踪系统架构设计与实践
3. 基于Zipkin的Thrift服务RPC调用链跟踪