调用追踪

分布式调用追踪可以通过对服务调用链的跟踪，构建一个从服务请求开始到各个服务交互的全部调用过程的视图。用户可以从中了解到诸如应用调用的时延，网络调用的生命周期，系统的性能瓶颈等等信息。 Flare内置了对调用追踪逻辑的支持，通过不同的内置或第三方provider，可以将RPC调用情况上报至相应的管理平台。

我们只支持符合OpenTracing规范的调用追踪系统。

显然，由于各服务只上报自己的信息的天性，为了能将整个调用链路串接起来，需要整个调用链条都使用相同的调用追踪平台才能获得有意义的结果。

目前我们内置了对如下平台的支持：

• (仅内部平台)

为了实现调用追踪，框架需要底层传输协议的支持（以便传递追踪上下文）。目前对于RPC而言，我们支持如下协议上的调用追踪：

• flare协议，对应的URI为flare://...；

目前我们不支持流式RPC的调用追踪。

使用

尽管我们尽可能的避免在关键逻辑上引入过多的调用追踪相关逻辑，取决于具体服务中业务逻辑的资源开销占比，开启调用追踪仍然可能会导致明显的性能下降。因此，在线上环境启用之前应当先进行适当的性能评估。

在发生调用失败时，我们会有选择（概率性采样）的上报失败的调用链，这可能是整个调用链路中的一部分，因此可能会看到不完整的调用链。

启用调用追踪

为了使服务会上报调用链信息，需要视情况开启如下开关：

• --flare_tracing_provider=...：这一开关指定了使用的调用追踪管理平台。目前的可选项有：
  • (仅支持内部系统)
• --flare_rpc_start_new_trace_on_missing：对于调用链路最顶端的服务，还需要额外指定这个bool型参数。当这一参数被指定时，如果请求方没有携带调用追踪的上下文，则会（概率性的采样）创建一个新的调用链。对于下游服务，其通常遵照上游传下来的采样决策决定是否上报，而不应当指定这一参数，否则可能会出现不完整的（由下游自行创建的）调用链。

另外，部分监控平台上报数据时需要提供上报方的服务名用于展示，因此我们建议服务实现方在初始化时填充Server::Options::service_name字段来达到此目的。

记录业务特有信息

如果业务需要传递额外的数据以方便调试（非必须），可以通过RpcServerController的AddTracingLog(...)和SetTracingTag(...)来记录业务数据，这些数据之后将会被上报到调用追踪平台。

部分追踪平台（如天机阁）会忽略AddTracingLog(key, value)时传入的key，这种情况下可以将所有的信息写在value中，并使用任意字符串作为key。

如果多次使用相同的key调用SetTracingTag(key, value)，那么只有最后一次调用的value会生效，之前的调用会被覆盖。AddTracingLog(...)则全都会上报。

程序代码修改

如果业务代码遵照了我们的开发建议，包括但不限于下列要求，那么业务代码只需要按照上文描述开启相关开关即可，不需要针对RPC调用追踪开发逻辑。

• 可行的情况下在XxxServiceImpl::XxxMethod中直接实现业务逻辑并同步完成；
  • 调用后端时同步接口及基于Future<...>的Stub接口均可。
• 需要并发操作时通过fiber::Async创建新的fiber来进行；
• 其余情况下通过Future<T> + fiber::BlockingGet(...)等待其他任意环境（包括非flare的pthread环境）中的操作完成并获取返回值（这实质上在fiber中进行了不阻塞pthread的同步等待因此和第一条实际上类似）。

对于其他情况，请参考后文描述并在代码中自行传递调用链上下文。

程序内部上下文传递

内部而言，我们通过fiber运行时中的ExecutionContext隐式的进行了一次RPC相关的上下文传递。对于调用追踪而言，这儿的上下文对应于SessionContext::tracing。

我们在调用业务的XxxServiceImpl::XxxMethod之前，会创建对应的ExecutionContext（下称“执行上下文”）并进行初始化，并在这个执行上下文内部调用业务代码。因此业务代码中任何同步的其他函数调用（如XxxService_SyncStub::XxxMethod发起RPC）中，框架均能够识别其所属的RPC上下文（绑定到了这个执行上下文），并增加必要的调用追踪逻辑。

同时，fiber运行时中，Async、SetTimer（性能较差，不建议大量使用）内部均会捕获、并在调用业务代码回调之前，恢复执行上下文。因此，使用这些方法进行异步操作时，框架同样可以自动识别其所属的RPC并增加必要的调用追踪逻辑。

RPC完成时调用done（如果用户提供了）或调用传递给Future<...>::Then的continuation（假设未额外指定Executor）时框架已经设置好了执行上下文。

对于特殊的无法使用框架上述方法的业务逻辑而言，也可以通过如下方法自行捕获、恢复执行上下文以便使用RPC追踪（及Flare中其他依赖执行上下文的）能力：

• 在离开XxxServiceImpl::XxxMethod之前通过fiber::ExecutionContext::Capture()捕获执行上下文。
• 如果需要调用Flare的相关方法，通过ExecutionContext::Execute(...)来执行，这个方法会在执行回调（这个方法的参数）之前和之后分别启用/恢复之前捕获的执行上下文。
  • ExecutionContext::Execute(...)必须在fiber环境中执行，如果当前不属于fiber环境，则可以通过flare::BlockingGet(fiber::Async(...))来实现（注意这儿用的是pthread版本的BlockingGet，因为此时不属于fiber环境）。

内部而言，Fiber::Attributes同样允许创建fiber时指定其所属的执行上下文，但是考虑到这一类相对底层，我们不推荐普通用户直接使用Fiber类。

返回目录