SkyWalking-13--分布式链路追踪系统(dapper/Tracing/SkyWalking简介部署案例)

一、分布式链路追踪系统起源–dapper简介

dapper：2008年谷歌最早内部使用并经过生产环境验证，2010年发布论文：
https://static.googleusercontent.com/media/research.google.com/zh-CN//archive/papers/dapper-2010-（1）pdf

1、面临的业务环境：

业务系统是使用复杂的、大规模的分布式集群实现，并且有服务很多服务组成。
每个服务可能使用不同的软件模块或开发框架。
每个服务可能使用不同的编程语言开发。
服务可能运行在数千台服务器，并且分布在不同的数据中心运行，对管理和监控产生挑战。
因此需要有专门的工具去跟踪请求、理解整体系统的瓶颈和实时的表现，假如一个请求太慢，那么要通过工具可以快速的找到问题所在。

一个前端服务作为访问入口，用户的请求可能会被转发至多个后端服务处理，当出现系统响应慢的时候，运维工程师很难对各个请求链路都了如指掌，
因为其中每一个服务都可能是由不同的团队开发和维护的，而且不同的后端服务还可能被不同的前端进行调用，因此人工去梳理和排错将会变得非常耗时和困难。

2、针对dapper的设计要求：

（1）无处不在的部署：
任何服务都应该被监控到，任何服务出问题都要做到有据可查。
（2）持续的监控
做到7*24小时全天候监控，任何时候出了问题都要基于监控数据追踪问题根源。

3、针对dapper的设计目标：

（1）低消耗：
dapper跟踪系统对服务的影响应该做到最小，在一些高并发的场合，即使很小的影响也可能会导致服务出现延迟、负载变高或不可用，从而导致业务团队可能会停止dapper系统。
（2）对应用透明：
应用程序对dapper系统无感知甚至不知道dapper系统的存在，假如一个跟踪系统必须依赖于应用的开发者配合才能实现跟踪，也即是需要在应用中植入跟踪代码，那么可能会因为代码产生bug或导致应用出问题。
（3）可伸缩性：
针对未来众多的服务和大规模业务集群，dapper系统应该能满足未来在性能的压力和功能上的需求。

4、dapper介绍-请求链路：

图中展现的是一个有5台服务器相关的一个服务，包括：前端（A），两个中间层（B和C），以及两个后端（D和E），当一个用户（这个用例的发起人）发起一个请求时，
首先到达前端（A），然后发送两个RPC到服务器B和C，B收到请求后会马上做出响应，但是C需要和后端的D和E交互之后再返还给A，由A来响应最初的客户请求，
对于这样一个请求，简单实用的分布式跟踪的实现，就是为服务器上每一次发送和接收动作来收集跟踪标识符（message identifiers）和时间戳（timestamped events）。

5、dapper介绍-数据采集方法：

分布式追踪的设计方案主要可以分为两类：
黑盒法（black-box）和标记法（annotation-based）
（1）黑盒法：
黑盒法无需任何侵入性代码，它的优势在于无需修改代码，缺点在于记录不是很准确，且需要大量数据才能够推导出服务间的关系。
（2）标记法：
标记法需要为每个请求打标记，并通过一个全局标识符将请求途径的所有服务信息串联，复盘整个链路。
标记法记录准确，但它的缺点也很明显，需要将标记代码注入到每个服务中。
在Google内部，几乎所有应用都使用相同的threading model、control flow和RPCsystems，因此可以将打标记的工作集中在少量的公共库中，同样能够达到对应用透明的效果。

6、dapper介绍-跟踪树和span：

Span 代表系统中具有开始时间和执行时长的请求跨度，Span之间通过嵌套或者顺序排列建立逻辑因果关系。
在Dapper跟踪树结构中，树节点是整个架构的基本单元，是请求从前端到后端不同应用之间层级机构，而每一个节点又是对span的引用节点之间的连线表示的span和它的父span直接的关系。
在图中说明了span在一个大的跟踪过程中是什么样的，Dapper记录了span名称，以及每个span的ID和父ID，以重建在一次追踪过程