Reactive Streams

OpenTracing是一款为应用和开源软件包设计的，新的开源分布式追踪标准。具有构建大规模微服务经验的开发人员了解分布式追踪的作用和重要性。即便每个进程都有自己的日志系和指标监控，
但在分布式系统中它们之间都无法联成一个整体。

第一篇关于分布式追凶系统的学术论文已有几十年了，从谷歌内部开始使用Dapper算也有12年了，Dapper论文发布也过去6年了，Zipkin也开源4年了。这个概念并不新颖。但你还在是为复杂的
服务架构，花费大量人力开发追踪系统。

如果分布式追踪这么有价值，为什么大家还没运用呢？因为它在目前为止还是不够完善

因为需要在进程内和进程间传递上下文信息，所以分布式追踪是不容易实现的，若要实现，上下文需要在这些地方之间相互传递：
1.开源服务（如Nginx、Cassandra、Redis等）
2.被用于自定义服务的开源库（如grpc、ORMs等）
3.业务逻辑

还有一个困难点：无法要求全部的开源服务和开源库或者自定义业务逻辑使用单一提供商的追踪库，这样也就无法把服务之间的调用链路组织起来。

因为我们需要一个标准机制来描述系统的行为

了解OpenTracing

OpenTracing就是那个「单一且标准的机制」。OpenTracing允许应用代码的开发者、开源库，开源服务不需要绑定特定提供商的追踪代码来实现链路追踪串连。
以下是这套标准：
1.标准化管理span：接口有开始和完成，以及描述定时任务的功能（span是Dapper和Zipkin里的术语）
2.标准化进程间的传递：接口有辅助进程间的追踪上下文传递
3.活跃span的标准化管理：接口可以在单个进程内，在不同包之间保存和获取活跃span
4.