1.2：Dapper
1.2.1：设计要求
1、无处不在的部署： 任何服务都应该被监控到，任何服务出问题都要做到有据可查。2、持续的监控：做到7*24小时全天候监控，任何时候出了问题都要基于监控数据追踪问题根源。
1.2.2：设计目标
1、低消耗：dapper跟踪系统对服务的影响做到最小，在一些高并发的场合，即使很小的影响也会导致服务出现延迟，负载变高或者不可用，从而导致业务团队可能会停止对dapper使用。2、对应用透明应用程序对dapper无感知甚至不知道dapper系统存在，假如一个跟踪系统必须依赖于应用的开发者配合才能实现跟踪，也即需要在应用程序中植入跟踪代码，那么可能会因为代码产商bug或导致应用出问题。3、可伸缩性针对未来众多的服务和大规模业务集群，dapper系统应该能满足未来在性能的压力和功能的需求。
1.2.3：dapper介绍–请求链路
图中展现的是一个有5台服务器相关的一个服务，包括：前端（A），两个中间层（B和C），以及两个后端（D和E）。当一个用户发起一个请求，首先到达前端（A），然后发送两个RPC到服务B和C，B收到请求后，马上响应。但是C需要和后端D和E交互后返回A，由A响应最初的客户请求。对于这样一个请求，分布式跟踪就是为服务器每一次发送和接收动作来收集跟踪标识符和时间戳。
1.2.4：Dapper介绍–数据采集方法
分布式追踪的设计方案主要可以分为两类： 黑盒法和标记法
黑盒法：无需`任何侵入性代码，它的优势在于无需修改代码，缺点在于记录不是很准确，且需要大量数据才能推导出服务间的关系。
**标记法：**需要为每个请求打标记，并通过一个全局标识符将请求途径的所有服务信息串联，复盘整个链路。标记法记录准确，但它的缺点很明显，需要将标记代码注入每个服务中。
在Google，几乎所有应用都使用相同的threading model、control flow和RPC system，因此可以将打标记的工作集中在少量公共库，同样能够达到对应用透明的效果。
1.2.5：Dapper介绍–跟踪树和span
Span代表系统中具有开始时间和执行时长请求跨度，Span之间通过嵌套或者顺序排列建立逻辑因果关系。在Dapper跟踪树结果中，树节点是整个架构的基本单元，是请求从前端到后端不同应用之间层级机构，而每一个节点又是对span引用，节点之间的连线表示span和fuqispan之间直接关系。图中说明span在一个大的跟踪过程中是什么样的，Dapper记录了span的名称，以及每个span ID和父ID,以重建在一个追踪过程中不同span之间的关系。如果一个span没有父ID称为root span，所有span都挂在一个特定的跟踪上，也公用一个trace id.
任何一个span可以包含来自不同的主机信息，这些也要记录下来，事实上每一个RPC span可以包含客户端和服务端两个过程注释，使得连接两个主机span会成为图中所说的span，由于client和server的时间戳来自不同的主机，还必须考虑到时间偏差，在分析工具就利用了时间偏差。即RPC客户端发送一个请求之后，服务器端才能接收到，对于响应也一样。这样server端就有一个开始和结束的时间戳，然后就可以计算出时间损耗。
1.2.6：Dapper介绍—traceid、spanid、parentid示意图
1.2.7：dapper介绍–植入点
Dapper可以实现对应用开发者近乎零侵入的成本，主要通过通用组件库实现；
当一个线程在处理跟踪请求链路的过程中，Dapper把这次跟踪的上下文在ThreadLocal进行存储，追踪上下文记录了SPanID和traceid。
几乎所有的Google的进程间通信是建立在一个用C++和Java开发的RPC框架。我们把跟踪植入该框架来定义RPC所有的span，spanid和traceid会从客户端发送到服务端。
1.2.8：dapper介绍–采样率
低损耗是Dapper的一个关键的设计目标，因为如果这个工具价值未被证实但又对性能有影响，就不会部署。
因此，除了把Dapper的收集对基本组件性能损耗限制尽可能小之外，我们还有进一步控制损耗的办法，那就是遇到大量请求只记录其中一小部分。
1.2.9：dapper介绍—跟踪收集的实现步骤
Dapper的跟踪记录和收集管道的过程分为三个阶段：
1、span数据写入本地日志文件
2、然后Dapper的守护进程和收集组件把这些数据从生产环境的主机读取
3、最终写到Dapper的数据仓库中一次跟踪被设计成Bigtable的一行，每一列相当于一个span。
1.2.10：Dapper介绍-跟踪的代价
在生产环境的跟踪数据处理中，dapper的守护进程从来没有超过0.3%的单核cpu使用率，而且只有很少量的内存使用，另外还限制了Dapper守护进程为内核scheduler最低优先级。
Dapper也是一个带宽资源的轻量级消费者，每一个span在我们仓库传输只占了426byte.
创建root span：204纳秒，创建一般span：176纳秒
建立一个annotation：40纳秒
写到本地磁盘
Dapper本地进程：《0.3%CPU，《0.01%网络
1.2.11：Dapper介绍—应用场景
性能分析：开发人员针对请求延迟的目标进行跟踪，并对容易优化的地方定位。
正确性分析：发现一些只读请求应该访问从库，但是却访问了主库类似的业务场景。
理解系统：全局优化系统，理解每个查询整体代价
测试新版本：发现新版本的bug和性能问题。
解决依赖问题：找到服务之间的依赖关系。
