导读：

一个分布式系统由若干分布式服务构成，每一个请求会经过多个业务系统并留下足迹，但是这些分散的数据对于问题排查，或是流程优化都很有限，要能做到追踪每个请求的完整链路调用，收集链路调用上每个服务的性能数据，计算性能数据和比对性能指标（SLA），甚至能够再反馈到服务治理中，那么这就是分布式跟踪的目标。在业界：淘宝的鹰眼，京东的Hydra实现了这个目标，这里要介绍的是twitter 的 zipkin。

ZipKin介绍

1、ZipKin简介

1、Zipkin是一个致力于收集分布式服务的时间数据的分布式跟踪系统。

2、Zipkin 主要涉及四个组件：collector（数据采集）,storage（数据存储）,search（数据查询）,UI（数据展示）。

3、github源码地址:https://github.com/openzipkin/zipkin。

4、Zipkin提供了可插拔数据存储方式：In-Memory，MySql, Cassandra, Elasticsearch；本文为了测试方便以In-Memory方式进行存储，个人推荐Elasticsearch，关于更多的存储方式可以参考github。

5、ZipKin运行环境需要Jdk8支持。

6、下载并启动ZipKin：

下载并规划成如下目录结构，可以自行更改。

说明：bin目录为启动脚本所在目录，lib目录为zipkin-server jar所在目录。

附下Jdk8下启动脚本，存储方式不是本篇重点，要更换存储方式请参考github。

运行时参数：

通过http://XXX:9411就可以访问zipkin UI控制台

2、ZipKin数据模型

Trace：一组代表一次用户请求所包含的spans，其中根span只有一个。

Span：一组代表一次HTTP/RPC请求所包含的annotations。

annotation：包括一个值，时间戳，主机名(留痕迹)。

3�ZipKin生成调用链

把一些轻量级的TraceID和Span ID在服务之间传递，服务之间将信息报告给Zipkin，ZipKin将服务之间调用关系有效组成一个完整的调用链。

注：TraceId：全局ID, spanId-每个方法调用的id,parentSpanId-父SpanId, sampled-是否需要采样。

1、客户端：

客户端需要把Trace(traceId,spanId,parentSpanId,sampled)信息放在Request/ThreadLocal中。

如果需要进行HTTP/RPC调用，需要把Trace的信息放在协议中，例如http header/Rpc Extraparams。

2、服务端：

检查http header/Rpc Extraparams中是否存在Trace信息，如果存在就把这些信息取出来，然后存入到Request/ThreadLocal中，进而把请求串接起来。如果不存在，那么就开始一个新的Trace。

�Brave介绍

1、�Brave简介

Brave 是用来装备 Java 程序的类库，提供了面向标准Servlet、Spring MVC、Http Client、JAX RS、Jersey、Resteasy 和 MySQL 等接口的装备能力，可以通过编写简单的配置和代码，让基于这些框架构建的应用可以向 Zipkin 报告数据。同时 Brave 也提供了非常简单且标准化的接口，在以上封装无法满足要求的时候可以方便扩展与定制。

虽然Brave提供了默认的实现，结合项目实际情况，基本上是需要定制才能满足要求的，本文针对默认实现就不再啰嗦，直接针对定制进行讲解。

由于项目中用到SpringMvc,HttpClient,Jprotobuf-Rpc-Socket，本文主要介绍针对SpringMvc,HttpClient,Jprotobuf-Rpc-Socket的扩展与定制。

2、服务调用常用的两种方式

1、服务以Http方式提供Rest接口，服务与服务之间通过HttpClient互相调用，对外以Http方式提供Rest接口，这里Rest以SpringMvc为例。

2、服务以jprotobufrpcsocket方式提供Rpc接口，服务与服务之间通过RPC互相调用，对外以Http方式提供Rest接口，这里Rest以SpringMvc为例，RPC以jprotobufrpcsocket为例。

3、Brave环境准备

1、Maven引入

2、通过实现FactoryBean接口，创建Brave实例，同时为Brave实例设置Http采集器，默认采用日志打印方式。

FactoryBean：

注：FactoryBean的作用在于更灵活创建Brave实例，serviceName为对应用服务的名称，ZipkinSetting为HttpSpanCollector实例需要的参数配置，以Http方式采集数据，就需要例如超时时间等这样的参数配置。

ZipkinSetting：

Brave环境的准备就讲到这里了。

4、HttpClient装配

Brave默认提供了OkHttpClient的支持，但是对于一个完成了的项目来说并不合适，因此我需要对HttpClient定制，对Http请求增加拦截功能，能在请求前后埋点。

1、HttpInvokeInteceptor：这个接口的作用在通过HttpClient请求前和请求后埋点。

2、HTTPClient:这个类的作用在于每次请求都会调用HttpClient execute方法，因此在execute方法体，我们可以在请求前和请求后埋点实现链路跟踪；在这个类持有HttpInvokeInteceptor的引用，完成请求前和请求后拦截。

3、HTTPRequest：这个类是POST,GET,DELETE,PUT等请求的父类，这里定义了URL和Method,以便在请求前埋点处留下更清晰的足迹，目的在于在Zipkin能留下url，method信息。

4、HTTPResponse：请求返回数据，在获取到HTTPResponse以后用来在请求完成后埋点留下更清晰的足迹。

5、FormPost：HTTPRequest的子类，真实的请求类。

6、BraveHttpClientInteceptor：BraveHttpClientInteceptor是HttpInvokeInteceptor的实现类，真实的HttpClient装配的实现。

请求前通过实现ClientRequestAdapter接口，请求后通过实现ClientResponseAdapter接口完成定制。

以上完成了HttpClient的装配。

5、SpringMvc装配

Brave库本身提供了SpringMVC拦截器针对Controller处理前后埋点的支持，接下来这是在此基础上做了改写：

让埋点信息更完善

增加了访问记录采集，有了访问记录，为服务治理做好准备（服务治理不作为讲解的范畴）

BraveHttpServerInterceptor:SpringMvc标准拦截器，主要用于在Controller处理前和处理后埋点实现请求跟踪。主要用于Server端装配。

6、JprotobufRpcSocket装配

1、版本选择：JprotobufRpcSocket3.4.4

2、JprotobufRpcSocket3.4.4 BUG: 客户端拦截器不生效。

原因：

HaProtobufRpcProxyBean继承HaProtobufRpcProxy，HaProtobufRpcProxy的onBuildProtobufRpcProxy方法如下：

HaProtobufRpcProxyBean有对该方法重写，重写的方法如下：

方法重写以后对应的拦截器没有往下传，导致拦截器不可用，这个bug修复如果通过修改源代码的方式比较麻烦，建议在项目中按照下面方式修改，不会涉及到Jprotobuf-Rpc-Socket依赖的更改与管理。

FIX:

Fix后的代码结构如下：

保持包名不变，对HaProtobufRpcProxyBean更名为MatrixHaProtobufRpcProxyBean ，HaProtobufRpcProxy更名为MatrixHaProtobufRpcProxy，HaRpcProxyFactoryBean更名为MatrixHaRpcProxyFactoryBean。

MatrixHaRpcProxyFactoryBean代码做如下改动：