在分布式服务化架构下,由于分布式服务间存在相互依赖,彼此协同来完成各类业务场景。下图是一个典型的业务场景,从前端发起一个请求,到最后的业务完成,需要经过很多环节,这些环节可能都是分布式服务的方式提供,部署在不同的服务器上进行。而在这种复杂的分布式服务场景下,为了定位问题、性能瓶颈查询、异常日志跟踪等,如果没有服务追踪和分析工具的帮助,都是非常困难的。

说到分布式追踪,当然不得不提Google为其基于日志的分布式跟踪系统Dapper发表的[论文],在这边论文里,Google介绍了他们在分布式追踪领域的经验,总体来看其核心概念有三个:
1. TraceID:用来标识每一条业务请求链的唯一ID,TraceID需要在整个调用链路上传递
2. Span:请求链中的每一个环节为一个Span,每一个Span有一个SpanId来标识,前后Span间形成父子关系
3. Annotation:业务自定义的埋点信息,可以是sql、用户ID等关键信息

图:5个span在Dapper跟踪树中的关联关系(图来自google论文)

Google论文出来后,业界出现了很多基于其思想实现的开源框架,如Twitter的zipkin,其中zipkin是严格按照来Dapper论文来设计的,他提供了完整的跟踪记录收集、存储功能,以及查询API与界面。其存储支持多种数据库:MySql、ElasticSearch、Cassandra、Redis等等,收集API支持HTTP和Thrift。

但作为服务跟踪中最难处理的一环,即跟踪埋点,zipkin并没有提供,需要使用方自己实现。业界也有Brave这样的开源项目可以使用,但是评估过后,发现Brave的实现过于复杂,依赖组件也过多,并且其实现的组件更多是支持HTTP服务的调用,对于我们的Thrift RPC服务不能支持,所以没有使用Brave,改为自己实现。自己实现服务埋点和追踪有几个问题需要解决:

1. TraceID如何生成?

由于要唯一标示每一次调用,所以TraceID需要保证全局唯一。唯一的ID,第一个想到的当然是使用UUID,UUID是一个较为高效又使用方便的唯一ID生成方式,但问题是,zipkin要求TraceID是int64类型,不能是字符串,同时,UUID还有一个问题是不能保证单调有序。对此,有两个架构方案可选:
- 使用数据库自增长ID来生成,同时需要解决以下问题:

  • 性能上,如果每次请求都访问数据库一次,会带来较大的性能损失,所以需要在客户端缓存一个区间的数字,当这个区间的数字不够时再从数据库获取。
  • 出于安全要求不能跟数据库直连的客户端不适合,如Web服务器。可以考虑使用一个中间服务作为ID分发。
    结合上面两点要求,架构方案如下:

    此方案中,ID分发服务的高可用性要求很高,如果该服务出现不可用,将影响到所有服务均不可用,增加了后续运营维护的麻烦。

- 采用分机器(进程)的方式,保证机器间(进程间)ID不冲突,同时保证单机器(进程)内ID是递增不重复的。这种方式的最大好处时不需要中心化的节点进行ID分发,省掉了系统间的依赖。对于此种方案,最常用的算法是Twitter-Snowflake算法,也是我们最终选择的算法。Snowflake核心思想是将int64的除第一位外的其他63位分成三段,前面41位为时间戳、后面10位为工作机器(进程)ID,也称为WorkerID ,最后12位为递增序列号。
(img)
当然,以上长度分段只是默认,可以根据实际情况进行区分,比如41位的时间戳,最长可以用(-1L ^ -1L<<41)/(3600 * 24 * 365 * 1000)=69年,10位的WorkerID最多支持1023台机器(进程),12位为递增序列表示每毫秒最多4095个ID,在实际中,我们为了支持更多的机器(进程),采取了16位WorkerID,4位标识序列号,即最多支持65535台机器(进程),每毫秒最多生成15个ID。该方案中,WrokerID的分配是需要特别注意的,WorkerID应该每个进程唯一,不能相同,如果相同的话就会出现低概率的ID重复

分配WorkerID最简单的办法是采取配置的方式,将WorkerID配置到程序的配置文件,但这种方式运营部署起来很麻烦,也容易沟通不到位,导致配置错误或重复。所以我们采取了通过Zookeeper动态分配WorkerID的方案,即在程序启动时,向Zookeeper发起请求,找到一个可用的WorkerID,如果找到一个可用的WorkerID,即创建一个临时子节点,利用Zookeeper临时节点可以自动释放的特性,当程序关闭时,该WorkerID就自动释放了,以达到了WorkerID的重用。只在进程启动时,访问一次Zookeeper来获取WorkeID,所以运行时不需要Zookeeper持续提供服务,性能也不会有损失。

2. 数据埋点如何做到对业务开发透明?如何在当前上下文中记录信息

所谓数据埋点,即将跟踪信息(TraceID、Span信息等)写入服务调用的上下文中,如果这个交给业务代码来完成的话,会导致业务代码变得冗余,同时如果业务代码忘记埋点,那就会丢失跟踪信息,所以在底层框架提供数据埋点,非常有必要。
数据埋点主要包括四个阶段:

  • Client Send:客户端发起请求时,如果当前线程上下文已经有Trace信息,继续透传当前Trace信息,如果没有,表示一个信息的请求,生成信息的Trace信息进行传递。
  • Server Recieve: 服务端接收到请求时间点,此时从当前请求里获取Trace信息,并将当前信息存入线程上下文。
  • Server Send:服务端处理业务完成,准备返回响应时,标记业务处理完成,同时将当前Trace信息提交归档。
  • Client Receive:客户端接收到服务端响应时,标记服务调用完成,同时将当前Trace信息提交归档。

如下的流程示例图说明各阶段埋点的位置,其中CS、SR为发起创建Trace信息到当前线程上下文的位置,CR、SS为归档提交Trace信息的位置

以上解释了在什么地方埋点和收集Trace信息,但是如何将当前上下文中的信息进行临时存储,并保证线程安全呢?这一点可以借助ThreadLocal来完成,发起创建Trace信息时,往ThreadLocal中写入记录,当前请求过程中再发起新的请求时,从ThreadLocal中获取Trace信息继续往下传递,等信息可以提交归档的时候,从ThreadLocal读取,并清除ThreadLocal中的信息。但是有一个问题需要注意,当发起异步请求时,发起请求的线程和最终被服务响应锁唤起的线程不是同一个线程,对于这种情况,如果响应线程是可由当前线程创建,使用可继承InheritableThreadLocal即可,如果不是,如由线程池来创建,则需要实现特别的线程池管理。另外还有一个办法就是,如果异步回调代码是可以注入的,那我们就可以在发起响应回调的时候注入代码即可。我们的RPC Client里就是采取这种方式。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
AsyncMethodCallback callback=new AsyncMethodCallback() {
@Override
public void onComplete(Object o) {
if (transport != null) {
closeTransport(url,transport);
}
//注入trace跟踪处理
Tracer.appendSpan(spanInfo);
Tracer.addAannotation(serviceName, url.getIpByInt(), url.getPort(), AnnotationNames.CLIENT_RECV);
Tracer.submitCurrentSpan();
//执行业务回调
resultHandler.onComplete(o);
}
};

同时,这里有个性能优化点需要注意,当Trace信息可以归档提交时,并不是往zipkin中直接写入,因为zipkin的性能有限,同时网络开销也较大,可以采取异步提交zipkin的方式,客户端归档信息后先从上下文往当前内存队列里写入,然后由单独的线程向zipkin提交记录。

3. 怎么实现Trace信息在调用链上的传递?

前文说到,服务追踪的核心是将Trace信息(TraceID、SpanID)在整个调用链上进行传递,而这些类似上下文的信息,一般不适合作为参数置于服务调用方法里进行传递。如果是HTTP调用,我们可以用HTTP Header来传递信息是非常方便的,但是Thrift服务并没有所谓的Header信息可以传递。
通过研究Thrift代码,发现在Thrift的传输协议实现里,服务端读取数据反序列化协议的入口方法是:
public abstract TMessage readMessageBegin() throws TException;
返回的TMessage对象中,有一个name的属性,其存储的是需要调用的服务方法名,比如我们调用:UserService.getUser(1),那这里的name属性值就是“getUser”。既然这里name可以传递一个公用的字符串,那我们自然可以在此进行扩展,在name属性上传递更多信息。将name按一个文本格式协议,组装成一个header信息进行传递。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
//读取消息头
TMessage message = iprot.readMessageBegin();
// 提取Header文本
int index = message.name.lastIndexOf(TMultiplexedProtocol.SEPARATOR);
String headersValue = message.name.substring(0, index);
//采取Http Header文本格式传递
Headers headers = Headers.parseHeaders(headersValue);
String traceID = headers.get(Constants.TPROTOCOL_HEADER_TRACE_ID);//arr[1];
String spanID = headers.get(Constants.TPROTOCOL_HEADER_SPAN_ID);//arr[2];
....
//将message.name还原,继续走thrift标准处理流程
int len = headersValue.length() + TMultiplexedProtocol.SEPARATOR.length();
String methodName = message.name.substring(len);
TMessage standardMessage = new TMessage(
methodName,
message.type,
message.seqid
);
actualProcessor.process(new SomeProtocol(standardMessage))

关于此种扩展方式,Thrift标准库为了实现同一个server里host多个服务Processor,也采取了这种方式,只是标准库只扩展了一个ServiceName字段进行传递而已。具体可以参考Thrift标准库的TMultiplexedProtocol 与TMultiplexedProcessor的代码。

总结:

本文介绍了从原理到实现上介绍了如何实现RPC服务追踪的细节,其关键基于调用链的概念。但是在实现上为了做到业务开发透明,还要不影响业务性能,还是需要很多谨慎考虑的。同时,我们其实还有很多未尽事宜需要继续优化,如提供安全的、埋点Tarce上下文的线程池,提供其他多种埋点客户端等等。同时,当Trace信息变成海量后,怎么存储这些信息,以及快速分析,从中挖取更多有意义、有价值的信息,将会成为我们新的挑战。