grpc java+opentracing调用链方案思路简介

1 说明

此方案仅限于微服务之间的RPC调用链分析，前期暂时无法做到服务中的db、redis、以及其他非RPC网络连接的链路分析。

2 方案

2.1 标准

本方案采用OpenTracing标准, OpenTracing定义了一套api

通过提供平台无关、厂商无关的API，使得开发人员能够方便的添加（或更换）追踪系统的实现。OpenTracing正在为全球的分布式追踪，提供统一的概念和数据标准。

2.1.1范例

以下是一个由8个Span构成的Trace的例子:

image.png

有时用时间轴来显示Traces更容易，如下图所示:

image.png

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中展示。

1. 微服务server用Brave和zipkin对接；

2. 搭建zipkin进行调用链展示;