1. 缘起
万物还是比较奇妙的，我本身是在研究 Spring cloud的；当学习到它的服务跟踪，我就想我们的系统也需要一套这样的东西（主要是被 zipkin 的简洁画面给吸引了）。然后百度一番，发现这方面的理论知识蛮多的，代码实现也用，版本会偏旧一点，但这不是主要原因，主要原因是我看不明白大神们的写法。。。
既然打算写这个了，那么如何并入我们的系统是关键，先谈谈我们的系统吧。我们的系统是用的 dubbo 作为 rpc框架，zookeeper 作为注册中心。整个分布式设计是分为两层，一层对外提供rest 接口，另一层作为基础模块层，供对外层调用。但实际上，由于业务的复杂性，基础模块层也在互相调用。如何能让大家接受一个这样的服务跟踪呢（并不打算在线上环境使用）？最简单的使用方式无疑是一大吸引力。所以我想我写的也只是一个工具包，引入该工具包即可。其实这样的jar包定制型太强，不太好，可拿来即用还是不错的。
2. 规划
问题点：
-
brave 如何介入web系统？
实现 servlet 拦截器即可
-
brave 如何介入 dubbo ？
实现 dubbo 拦截器即可
-
如何在不改变原有代码的基础上，使我们的工具包生效？
dubbo 的 spi 机制以及
@Activate注解；servlet 拦截器 采用注解的配置方式。
框架的可拓展性是多么的重要啊…
brave 我就不多介绍了，我也只是知道整个服务跟踪的设计想法而已，我相信这个在你百度到我这篇文章之前，已经理解到了。
zipkin 作为数据采集点，我所做的只是将它启动而已。
3. 进度
举个例子吧。有这样一个系统，A （web项目并集成了dubbo）调用了B （不对外提供接口，集成了dubbo），B 调用了 C （不对外提供接口，集成了dubbo）… 现在已能完成对这样的一个系统的追踪了。
上个图：
4. 源码
-
CurrentTraceContextFactory类：CurrentTraceContext工程类，维护线程安全的CurrentTraceContext。 -
LocalTracing类：屏蔽了CurrentTraceContext的细节，也是线程安全的。 -
HttpTracingFilter类: servlet filter 的实现，在于初始化整个跟踪服务。 -
DubboConsumerTracingFilter类：dubbo consumer 拦截器，负责传播服务跟踪需要的数据（注入器）。 -
DubboProviderTracingFilter类：dubbo provider 拦截器，负责抽取传播的跟踪数据，并初始化跟踪服务。
源码移步至 github，一年工作经验的我无法保证其可用性，欢迎提 bug 。