基于SpringBoot和Zipkin的Trace系统

前言

基于springboot微服务架构，监控是不可少的， 这篇主要讲解一下目前公司采用的trace方案。当前比较主流的trace方案基本都是基于Dapper，依赖于zipkin来搭建自己的trace系统。

技术调研

目前trace的开源方案有以下几种:

1. 基于zipkin + brave 的方案，这种方案使用原始组件，可以比较方便的自己进行扩展。
2. 基于Spring-Cloud-Sleuth的集成方案，这个方案是Spring-Cloud的集成方案，底层也是基于zipkin的，只是做了一些Spring-Cloud的集成工作。
3. 基于CAT来的整套解决方案。

具体实施

1. 根据上面的技术调研， 因为方案(1)和(2)底层都没有本质的区别，加上方案(2)的解决方案，对于之前设想的trace粒度还有点差距，所以必须要进行自己的扩展，所以最终选择了相对可以自行组合的方案(1)。

2. 以前刚开始搭建系统的时候zipkin对于大规模的存储系统只提供了cassandra，所以没办法，我们的存储也只能选择cassandra了，不过现在也支持es作为底层存储了，正好es5也在最近发布了。所以准备在合适的时候进行把cassandra替换成es。

3. 但是单纯http的trace监控不能满足我们需求，我们需要额外加上mysql、redis、httpclient、okhttp、thrift等调用的监控，但是又不想对于现有的业务进行任何改动，所以就需要动态使用brave的api对trace增加而外的localspan和annotation。目前我们采用类似于NewRelic的方式通过javaagent来动态加入trace信息的补充