1 说明
此方案仅限于微服务之间的RPC调用链分析，前期暂时无法做到服务中的db、redis、以及其他非RPC网络连接的链路分析。
2 方案
2.1 标准
本方案采用OpenTracing标准, OpenTracing定义了一套api
通过提供平台无关、厂商无关的API，使得开发人员能够方便的添加（或更换）追踪系统的实现。OpenTracing正在为全球的分布式追踪，提供统一的概念和数据标准。
2.1.1范例
以下是一个由8个Span构成的Trace的例子:
有时用时间轴来显示Traces更容易，如下图所示:
OpenTracing参考文档《OpenTracing语义规范(中文版)》、《OpenTracing for java api》
2.2 触发
1 api网关根据配置中心配置的概率(例如：1表示100%，0.1表示10%)，随机抽取请求进行opentracing埋点；
2 api网关往公共参数中设置tracing=1表示该请求需要进行opentracing;
3 API网关的ClientInterceptor会根据tracing状态自动初始化首个span的内容；
2.3 Span定义
1 API网关的span名称为：gateway.servicename.methodname；
2 微服务的span名称为：servicename.methodname；
3 为每个请求的span都设置一个pkgid的tag，并且在每个trace生命周期中都一致；
4 span与span的关系暂时只有childof(reference暂时无法实现)；
2.4 框架设计
通过grpc的ServerInterceptor拦截器进行处理，无业务侵入性。
1 拦截器逻辑思路：获取trace -> 创建trace.buildSpan ->启动SpanBuilder.start->日志 span.log ->结束span.finish
2 trace内容在rpc调用过程中，使用zebra公共参数进行传递，然后通过Tracer进行序列号和反序列化
2.1 zipkin对接
opentracing使用zipkin进行上报，并且在zipkin中展示。
微服务server用Brave和zipkin对接；
搭建zipkin进行调用链展示;
