一、什么是Tracing？
微服务的特点决定了功能模块的部署是分布式的，以往在单应用环境下，所有的业务都在同一个服务器上，如果服务器出现错误和异常，我们只要盯住一个点，就可以快速定位和处理问题，但是在微服务的架构下，大部分功能模块都是单独部署运行的，彼此通过总线交互，都是无状态的服务，这种架构下，前后台的业务流会经过很多个微服务的处理和传递，我们会面临以下问题：
分散在各个服务器上的日志怎么处理？
如果业务流出现了错误和异常，如何定位是哪个点出的问题？
如何快速定位问题？
如何跟踪业务流的处理顺序和结果？
以前在单应用下的日志监控很简单，在微服务架构下却成为了一个大问题，如果无法跟踪业务流，无法定位问题，我们将耗费大量的时间来查找和定位问题，在复杂的微服务交互关系中，我们就会非常被动。因此，我们需要对其进行追踪，而这个时候Google公司广泛使用了分布式集群，为了应对自身大规模的复杂集群环境，Google公司研发了Dapper分布式跟踪系统，并发表了论文《Dapper, a Large-Scale Distributed Systems Tracing Infrastructure》，给行业内分布式跟踪的实现提供了非常有价值的参考，该论文也成为了当前分布式跟踪系统的理论基础。
>>对于基础理论，这里涉及到OpenTracing，推荐看看吴晟的翻译的《OpenTracing文档中文版》。
二、Butterfly的基本使用 2.1 Butterfly简介Butterfly是一个使用Open Tracing规范来设计追踪数据的开源追踪组件，作者Lemon，也是AspectCore的作者。目前Ocelot已集成Butterfly，我们只需要做很少的配置即可对经过网关的所有API服务进行Tracing。不过，貌似Lemon已不打算继续维护Butterfly而是推荐使用Apache SkyWalking来做生产环境的分布式追踪，同时他也加入了SkyWalking团队共同进行SkyWalking在多语言生态的推动。不过，就学习而言，Butterfly是比较适合学习来了解分布式追踪是个神马玩意儿的，因此这里我就不再去学习ApacheSkyWalking了（因为我的目标是了解整个流程，做POC而不是能上生产环境的产品）。
这里是SkyWalking-netcore的GitHub地址：https://github.com/OpenSkywalking/skywalking-netcore
Step1.下载最新的release,目前是preview-0.0.8
Step2.解压并通过命令启动：dotnet Butterfly.Web.dll --EnableHttpCollector=true
Step3.通过默认地址和端口进行查看，如下图所示：（这里没有任何trace，因为还没有任何请求）
刚刚说到Ocelot已内集成了Butterfly，所以我们只需要做以下两个配置：
（1）配置文件配置UseTracing
"ReRoutes": [ // API01:CAS.ClientService // --> service part { ...... "HttpHandlerOptions": { "UseTracing": true // use butterfly to tracing request chain }, ...... }, // API02:CAS.ProductService // --> service part { ...... "HttpHandlerOptions": { "UseTracing": true // use butterfly to tracing request chain }, ...... }