原文：https://www.jianshu.com/p/92a12de11f18
随着微服务架构的流行，服务按照不同的维度进行拆分，一次请求往往需要涉及到多个服务。互联网应用构建在不同的软件模块集上，这些软件模块，有可能是由不同的团队开发、可能使用不同的编程语言来实现、有可能布在了几千台服务器，横跨多个不同的数据中心。因此，就需要一些可以帮助理解系统行为、用于分析性能问题的工具，以便发生故障的时候，能够快速定位和解决问题。
全链路监控组件就在这样的问题背景下产生了。最出名的是谷歌公开的论文提到的Google Dapper[1]。想要在这个上下文中理解分布式系统的行为，就需要监控那些横跨了不同的应用、不同的服务器之间的关联动作。
所以，在复杂的微服务架构系统中，几乎每一个前端请求都会形成一个复杂的分布式服务调用链路。一个请求完整调用链可能如下图所示：
那么在业务规模不断增大、服务不断增多以及频繁变更的情况下，面对复杂的调用链路就带来一系列问题：
-
如何快速发现问题？
-
如何判断故障影响范围？
-
如何梳理服务依赖以及依赖的合理性？
-
如何分析链路性能问题以及实时容量规划？
同时我们会关注在请求处理期间各个调用的各项性能指标，比如：吞吐量（TPS）、响应时间及错误记录等。
全链路性能监控从整体维度到局部维度展示各项指标，将跨应用的所有调用链性能信息集中展现，可方便度量整体和局部性能，并且方便找到故障产生的源头，生产上可极大缩短故障排除时间。
-
请求链路追踪，故障快速定位：可以通过调用链结合业务日志快速定位错误信息。
-
可视化：各个阶段耗时，进行性能分析。
-
依赖优化：各个调用环节的可用性、梳理服务依赖关系以及优化。
-
数据分析，优化链路：
可以得到用户的行为路径，汇总分析应用在很多业务场景。
如上所述，那么我们选择全链路监控组件有哪些目标要求呢？Google Dapper中也提到了，总结如下：
APM组件服务的影响应该做到足够小。服务调用埋点本身会带来性能损耗，这就需要调用跟踪的低损耗，实际中还会通过配置采样率的方式，选择一部分请求去分析请求路径。在一些高度优化过的服务，即使一点点损耗也会很容易察觉到，而且有可能迫使在线服务的部署团队不得不将跟踪系统关停。
即也作为业务组件，应当尽可能少入侵或者无入侵其他业务系统，对于使用方透明，减少开发人员的负担。
对于应用的程序员来说，是不需要知道有跟踪系统这回事的。如果一个跟踪系统想生效，就必须需要依赖应用的开发者主动配合，那么这个跟踪系统也太脆弱了，往往由于跟踪系统在应用中植入代码的bug或疏忽导致应用出问题，这样才是无法满足对跟踪系统“无所不在的部署”这个需求。
一个优秀的调用跟踪系统必须支持分布式部署，具备良好的可扩展性。能够支持的组件越多当然越好。或者提供便捷的插件开发API，对于一些没有监控到的组件，应用开发者也可以自行扩展。
数据的分析要快，分析的维度尽可能多。跟踪系统能提供足够快的信息反馈，就可以对生产环境下的异常状况做出快速反应。分析的全面，能够避免二次开发。
埋点即系统在当前节点的上下文信息，可以分为客户端埋点、服务端埋点，以及客户端和服务端双向型埋点。埋点日志通常要包含以下内容TraceId、SpanId、调用的开始时间，协议类型、调用方IP和端口，请求的服务名、调用耗时，调用结果，异常信息等，同时预留可扩展字段，为下一步扩展做准备。
不能造成性能负担：一个价值未被验证，却会影响性能的东西，是很难在公司推广的！
因为要写log，业务QPS越高，性能影响越重。通过采样和异步log解决。
主要支持分布式日志采集的方案，同时增加MQ作为缓冲。
调用链跟踪分析：把同一TraceID的Span收集起来，按时间排序就是timeline。把ParentID串起来就是调用栈。
抛异常或者超时，在日志里打印TraceID。利用TraceID查询调用链情况，定位问题。
基本工作单元，一次链路调用（可以是RPC，DB等没有特定的限制）创建一个Span，通过一个64位ID标识它，uuid较为方便，Span中还有其他的数据，例如描述信息，时间戳，key-value对的（Annotation）tag信息，parent_id等，其中parent-id可以表示Span调用链路来源。
上图说明了Span在一次大的跟踪过程中是什么样的。Dapper记录了Span名称，以及每个Span的ID和父ID，以重建在一次追踪过程中不同Span之间的关系。如果一个Span没有父ID被称为root span。所有Span都挂在一个特定的跟踪上，也共用一个跟踪ID。
type Span struct {
TraceID int64 // 用于标示一次完整的请求ID
Name string
ID int64 // 当前这次调用span_id
ParentID int64 // 上层服务的调用span_id 最上层服务parent_id为null
Annotation []Annotation // 用于标记的时间戳
Debug bool
}
类似于树结构的Span集合，表示一次完整的跟踪，从请求到服务器开始，服务器返回response结束，跟踪每次RPC调用的耗时，存在唯一标识trace_id。比如：你运行的分布式大数据存储一次Trace就由你的一次请求组成。
每种颜色的note标注了一个Span，一条链路通过TraceId唯一标识，Span标识发起的请求信息。树节点是整个架构的基本单元，而每一个节点又是对Span的引用。节点之间的连线表示的Span和它的父Span直接的关系。虽然Span在日志文件中只是简单的代表Span的开始和结束时间，他们在整个树形结构中却是相对独立的。
注解，用来记录请求特定事件相关信息（例如时间），一个Span中会有多个annotation注解描述。通常包含四个注解信息：
-
cs：Client Start，表示客户端发起请求
-
sr：Server Receive，表示服务端收到请求
-
ss：Server Send，表示服务端完成处理，并将结果发送给客户端
-
cr：
Client Received，表示客户端获取到服务端返回信息
type Annotation struct {
Timestamp int64
Value string
Host Endpoint
Duration int32
}
-
请求到来生成一个全局TraceID，通过TraceID可以串联起整个调用链，一个TraceID代表一次请求。
-
除了TraceID外，还需要SpanID用于记录调用父子关系。每个服务会记录下parent id和span id，通过他们可以组织一次完整调用链的父子关系。
-
一个没有parent id的span成为root span，可以看成调用链入口。
-
所有这些ID可用全局唯一的64位整数表示。
-
整个调用过程中每个请求都要透传TraceID和SpanID。
-
每个服务将该次请求附带的TraceID和附带的SpanID作为parent id记录下，并且将自己生成的SpanID也记录下。
-
要查看某次完整的调用则只要根据TraceID查出所有调用记录，然后通过parent id和span id组织起整个调用父子关系。
-
调用链数据生成，对整个调用过程的所有应用进行埋点并输出日志。
-
调用链数据采集，对各个应用中的日志数据进行采集。
-
调用链数据存储及查询，对采集到的数据进行存储，由于日志数据量一般都很大，不仅要能对其存储，还需要能提供快速查询。
-
指标运算、存储及查询，对采集到的日志数据进行各种指标运算，将运算结果保存起来。
-
告警功能，提供各种阀值警告功能。
通过Agent代理无侵入式部署，将性能测量与业务逻辑完全分离，可以测量任意类的任意方法的执行时间，这种方式大大提高了采集效率，并且减少运维成本。根据服务跨度主要分为两大类AGENT：
市面上的全链路监控理论模型大多都是借鉴Google Dapper论文，本文重点关注以下三种APM组件：
-
Zipkin：由Twitter公司开源，开放源代码分布式的跟踪系统，用于收集服务的定时数据，以解决微服务架构中的延迟问题，包括：数据的收集、存储、查找和展现。
-
Pinpoint：一款对Java编写的大规模分布式系统的APM工具，由韩国人开源的分布式跟踪组件。
-
Skywalking：国产的优秀APM组件，是一个对JAVA分布式应用程序集群的业务运行情况进行追踪、告警和分析的系统。
-
探针的性能，主要是Agent对服务的吞吐量、CPU和内存的影响。微服务的规模和动态性使得数据收集的成本大幅度提高。
-
Collector的可扩展性，能够水平扩展以便支持大规模服务器集群。
-
全面的调用链路数据分析，提供代码级别的可见性以便轻松定位失败点和瓶颈。
-
对于开发透明，容易开关，添加新功能而无需修改代码，容易启用或者禁用。
-
完整的调用链应用拓扑，自动检测应用拓扑，帮助你搞清楚应用的架构。
比较关注探针的性能，毕竟APM定位还是工具，如果启用了链路监控组建后，直接导致吞吐量降低过半，那也是不能接受的。对Skywalking、Zipkin、Pinpoint进行了压测，并与基线（未使用探针）的情况进行了对比。
选用了一个常见的基于Spring的应用程序，他包含Spring Boot，Spring MVC，Redis客户端，MySQL。监控这个应用程序，每个Trace，探针会抓取5个Span（1 Tomcat，1 Spring MVC，2 Jedis，1 MySQL）。这边基本和SkywalkingTest的测试应用差不多。
模拟了三种并发用户：500，750，1000。使用JMeter测试，每个线程发送30个请求，设置思考时间为10ms。使用的采样率为1，即100%，这边与生产可能有差别。Pinpoint默认的采样率为20，即5%，通过设置agent的配置文件改为100%。zipkin默认也是1。组合起来，一共有12种。下面看下汇总表：
从上表可以看出，在三种链路监控组件中，Skywalking的探针对吞吐量的影响最小，Zipkin的吞吐量居中。Pinpoint的探针对吞吐量的影响较为明显，在500并发用户时，测试服务的吞吐量从1385降低到774，影响很大。然后再看下CPU和memory的影响，在内部服务器进行的压测，对CPU和memory的影响都差不多在10%之内。
Collector的可扩展性，使得能够水平扩展以便支持大规模服务器集群。
开发zipkin-Server（其实就是提供的开箱即用包），zipkin-agent与zipkin-Server通过http或者MQ进行通信，http通信会对正常的访问造成影响，所以还是推荐基于mq异步方式通信，zipkin-Server通过订阅具体的topic进行消费。这个当然是可以扩展的，多个zipkin-Server实例进行异步消费MQ中的监控信息。
Skywalking的Collector支持两种部署方式：单机和集群模式。Collector与Agent之间的通信使用了gRPC。
同样，Pinpoint也是支持集群和单机部署的。pinpoint agent通过Thrift通信框架，发送链路信息到Collector。
全面的调用链路数据分析，提供代码级别的可见性以便轻松定位失败点和瓶颈。
Zipkin的链路监控粒度相对没有那么细，从上图可以看到调用链中具体到接口级别，再进一步的调用信息并未涉及。
Skywalking 还支持20+的中间件、框架、类库，比如：主流的Dubbo、Okhttp，还有DB和消息中间件。上图Skywalking链路调用分析截取的比较简单，网关调用user服务，由于支持众多的中间件，所以Skywalking链路调用分析比Zipkin完备些。
Pinpoint应该是这三种APM组件中，数据分析最为完备的组件。提供代码级别的可见性以便轻松定位失败点和瓶颈，上图可以看到对于执行的SQL语句，都进行了记录。还可以配置报警规则等，设置每个应用对应的负责人，根据配置的规则报警，支持的中间件和框架也比较完备。
对于开发透明，容易开关，添加新功能而无需修改代码，容易启用或者禁用。我们期望功能可以不修改代码就工作并希望得到代码级别的可见性。
对于这一点，Zipkin使用修改过的类库和它自己的容器（Finagle）来提供分布式事务跟踪的功能。但是，它要求在需要时修改代码。Skywalking和Pinpoint都是基于字节码增强的方式，开发人员不需要修改代码，并且可以收集到更多精确的数据因为有字节码中的更多信息。
