分布式链路追踪 对比
从上表可以看出，在三种链路监控组件中，skywalking的探针对吞吐量的影响最小，zipkin的吞吐量居中。pinpoint的探针对吞吐量的影响较为明显，
在500并发用户时，测试服务的吞吐量从1385降低到774，影响很大。然后再看下CPU和memory的影响，在内部服务器进行的压测，
对CPU和memory的影响都差不多在10%之内。
分布式调用跟踪系统的设计
（1）分布式调用跟踪系统的设计目标
低侵入性，应用透明：作为非业务组件，应当尽可能少侵入或者无侵入其他业务系统，对于使用方透明，减少开发人员的负担
低损耗：服务调用埋点本身会带来性能损耗，这就需要调用跟踪的低损耗，实际中还会通过配置采样率的方式，选择一部分请求去分析请求路径
大范围部署，扩展性：作为分布式系统的组件之一，一个优秀的调用跟踪系统必须支持分布式部署，具备良好的可扩展性
（2）埋点和生成日志
埋点即系统在当前节点的上下文信息，可以分为客户端埋点、服务端埋点，以及客户端和服务端双向型埋点。埋点日志通常要包含以下内容：
TraceId、RPCId、调用的开始时间，调用类型，协议类型，调用方ip和端口，请求的服务名等信息；
调用耗时，调用结果，异常信息，消息报文等；
预留可扩展字段，为下一步扩展做准备；
（3）抓取和存储日志
日志的采集和存储有许多开源的工具可以选择，一般来说，会使用离线+实时的方式去存储日志，主要是分布式日志采集的方式。典型的解决方案如Flume结合Kafka等MQ。
（4）分析和统计调用链数据
一条调用链的日志散落在调用经过的各个服务器上，首先需要按 TraceId 汇总日志，然后按照RpcId 对调用链进行顺序整理。用链数据不要求百分之百准确，可以允许中间的部分日志丢失。
（5）计算和展示
汇总得到各个应用节点的调用链日志后，可以针对性的对各个业务线进行分析。需要对具体日志进行整理，进一步储存在HBase或者关系型数据库中，可以进行可视化的查询。
链路跟踪Trace模型
一次典型的分布式调用过程，如下图所示:
Trace调用模型，主要有以下概念：
Trace：一次完整的分布式调用跟踪链路。
Span： 追踪服务调基本结构，表示跨服务的一次调用； 多span形成树形结构，组合成一次Trace追踪记录。
Annotation：在span中的标注点，记录整个span时间段内发生的事件。
BinaryAnnotation：可以认为是特殊的Annotation，用户自定义事件。
Annotation类型：保留类型
Cs CLIENT_SEND，客户端发起请求
Cr CLIENT_RECIEVE，客户端收到响应
Sr SERVER_RECIEVE，服务端收到请求
Ss SERVER_SEND，服务端发送结果
用户自定义类型：
Event 记录普通事件
Exception 记录异常事件
Client && Server：对于跨服务的一次调用，请求发起方为client，服务提供方为server
各术语在一次分布式调用中，关系如下图所示：
调用跟踪系统的选型
大的互联网公司都有自己的分布式跟踪系统，比如Google的Dapper，Twitter的zipkin，淘宝的鹰眼，新浪的Watchman，京东的Hydra等，下面来简单分析。
Google的Drapper
Dapper是Google生产环境下的分布式跟踪系统，Dapper有三个设计目标：
低消耗：跟踪系统对在线服务的影响应该做到足够小。
应用级的透明：对于应用的程序员来说，是不需要知道有跟踪系统这回事的。如果一个跟踪系统想生效，就必须需要依赖应用的开发者主动配合，那么这个跟踪系统显然是侵入性太强的。
延展性：Google至少在未来几年的服务和集群的规模，监控系统都应该能完全把控住。
处理分为3个阶段：
①各个服务将span数据写到本机日志上；
②dapper守护进程进行拉取，将数据读到dapper收集器里；
③dapper收集器将结果写到bigtable中，一次跟踪被记录为一行。
阿里-鹰眼
关于淘宝的鹰眼系统，主要资料来自于内部分享：
鹰眼埋点和生成日志：
如何抓取和存储日志，记录本地文件，使用额外的后台进程定期（时间间隔小）收集日志。这种方式的优势在于对应用的性能影响小，方便做消息堆积；但是需要在每台业务server上都部署并管理日志收集agent，运维量比较大。
鹰眼的实现小结：
注意Dapper与Eagle eye都不开源。
阿里EDAS+ARMS的立体化监控体系
通过阿里云提供的EDAS结合ARMS可以打造立体化监控体系，其中EDAS用于应用管控层面，用于控制链路和应用；而ARMS更关注业务运营层面，如电商交易、车联网、零售；实际上，监控需要全方位关注业务、链路、应用、系统，通过ARMS与EDAS相互补全，形成了立体化监控体系。
大众点评——CAT
架构简单。可以实现一个Trace系统的所有功能。架构如下图所示：
跟踪模型
Transaction是最重要的事件消息类型，适合记录跨越系统边界的程序访问行为,比如远程调用，数据库调用，也适合执行时间较长的业务逻辑监控，记录次数与时间开销。Transaction可嵌套。
跨服务的跟踪功能与点评内部的RPC框架集成，这部分未开源。
客户端接入方式
对于方法调用、sql、url请求等粒度较小的兴趣点，需要业务人员手写代码实现。
日志收集方式
直接向日志收集器发异步请求（有本地内存缓存），一台客户端会连向几个服务端，当一个服务端出问题，数据不会丢失。
当所有服务端都挂掉，消息会存入queue，当queue满了，就丢弃了，没有做数据存储本地等工作。
全量采样，系统繁忙的时候对性能影响较大（可能达到10%的影响）
最后一个稳定版本是2014年1月，之后已经失去维护。
京东-hydra
与dubbo框架集成。对于服务级别的跟踪统计，现有业务可以无缝接入。对于细粒度的兴趣点，需要业务人员手动添加。架构如下：
Hydra中跟踪数据模型
Trace: 一次服务调用追踪链路。
Span: 追踪服务调基本结构，多span形成树形结构组合成一次Trace追踪记录。
Annotation: 在span中的标注点，记录整个span时间段内发生的事件。
BinaryAnnotation: 属于Annotation一种类型和普通Annotation区别，这键值对形式标注在span中发生的事件，和一些其他相关的信息。
日志收集方式
与CAT类似。支持自适应采样，规则粗暴简单，对于每秒钟的请求次数进行统计，如果超过100，就按照10%的比率进行采样。
开源项目已于2013年6月停止维护。
Twitter—OpenZipkin
功能、数据跟踪模型与hydra类似。Zipkin本身不开源，开源社区的是另外一套scala实现，依托于finagle这个RPC框架。架构如下：
Zipkin与其他Trace系统的不同之处在于：
Zipkin中针对 HttpClient、jax-rs2、jersey/jersey2等HTTP客户端封装了拦截器。可以在较小的代码侵入条件下实现URl请求的拦截、时间统计和日志记录等操作。
日志收集
Cat是直接将日志发往消费集群；hydra是发给日志收集器，日志收集器推到消息队列；Zipkin的client将统计日志发往消息队列，日志收集器读取后落地存储；Dapper和Eagle eye是记录本地文件，后台进程定期扫描。
Trace系统现状分析
以上几款链路跟踪系统都各自满足了请求链路追踪的功能，但落实到我们自己的生产环境中时，这些Trace系统存在诸多问题：Google和alibaba的Trace系统不开源，但现阶段来说阿里是做得最好的，如果用的是阿里的服务器，可考虑直接用阿里的追踪系统以节省开发代价；
京东和点评的虽然开源，但是已经多年没有维护，项目依赖的jdk版本以及第三方框架过于陈旧等等，不适合用在生产环境中；
Twitter的OpenZipkin使用scala开发，而且其实现基于twitter内部的RPC框架finagle，第三方依赖比较多，接入和运维的成本非常高。
如果不是用阿里的服务，我们可以借鉴这些开源实现的思想, 自行开发Trace系统。那是自己从0开始开发还是基于开源方案二次开发？ 这里面也要考虑到跨平台，如NET和java环境，尽量减少原系统的侵入性或只需要更改少量的代码即可接入，在这里可以基于zipkin和pinpoint进行二次开发，功能可参考阿里的系统。
Zipkin 和 Pinpoint 选型对比
Pinpoint 与 Zipkin 都是基于 Google Dapper 的那篇论文，因此理论基础大致相同。Pinpoint 与 Zipkin 有明显的差异，主要体现在如下几个方面：
- Pinpoint 是一个完整的性能监控解决方案：有从探针、收集器、存储到 Web 界面等全套体系；而 Zipkin 只侧重收集器和存储服务，虽然也有用户界面，但其功能与 Pinpoint 不可同日而语。反而 Zipkin 提供有 Query 接口，更强大的用户界面和系统集成能力，可以基于该接口二次开发实现。
- Zipkin 官方提供有基于 Finagle 框架（Scala 语言）的接口，而其他框架的接口由社区贡献，目前可以支持 Java、Scala、Node、Go、Python、Ruby 和 C# 等主流开发语言和框架；但是 Pinpoint 目前只有官方提供的 Java Agent 探针，其他的都在请求社区支援中。
- Pinpoint 提供有 Java Agent 探针，通过字节码注入的方式实现调用拦截和数据收集，可以做到真正的代码无侵入，只需要在启动服务器的时候添加一些参数，就可以完成探针的部署；而 Zipkin 的 Java 接口实现 Brave，只提供了基本的操作 API，如果需要与框架或者项目集成的话，就需要手动添加配置文件或增加代码。
- Pinpoint 的后端存储基于 HBase，而 Zipkin 基于 Cassandra。
接入难度
因为 Brave 的注入需要依赖底层框架提供相关接口，因此并不需要对框架有一个全面的了解，只需要知道能在什么地方注入，能够在注入的时候取得什么数据就可以了。就像上面的例子，我们根本不需要知道 MySQL 的 JDBC Driver 是如何实现的也可以做到拦截 SQL 的能力。但是 Pinpoint 就不然，因为 Pinpoint 几乎可以在任何地方注入任何代码，这需要开发人员对所需注入的库的代码实现有非常深入的了解，通过查看其 MySQL 和 Http Client 插件的实现就可以洞察这一点，当然这也从另外一个层面说明 Pinpoint 的能力确实可以非常强大，而且其默认实现的很多插件已经做到了非常细粒度的拦截。
针对底层框架没有公开 API 的时候，其实 Brave 也并不完全无计可施，我们可以采取 AOP 的方式，一样能够将相关拦截注入到指定的代码中，而且显然 AOP 的应用要比字节码注入简单很多。
以上这些直接关系到实现一个监控的成本，在 Pinpoint 的官方技术文档中，给出了一个参考数据。如果对一个系统集成的话，那么用于开发 Pinpoint 插件的成本是 100，将此插件集成入系统的成本是 0；但对于 Brave，插件开发的成本只有 20，而集成成本是 10。从这一点上可以看出官方给出的成本参考数据是 5:1。但是官方又强调了，如果有 10 个系统需要集成的话，那么总成本就是 10 * 10 + 20 = 120，就超出了 Pinpoint 的开发成本 100，而且需要集成的服务越多，这个差距就越大。
从短期目标来看，Pinpoint 确实具有压倒性的优势：无需对项目代码进行任何改动就可以部署探针、追踪数据细粒化到方法调用级别、功能强大的用户界面以及几乎比较全面的 Java 框架支持。但是长远来看，学习 Pinpoint 的开发接口，以及未来为不同的框架实现接口的成本都还是个未知数。相反，掌握 Brave 就相对容易，而且 Zipkin 的社区更加强大，更有可能在未来开发出更多的接口。在最坏的情况下，我们也可以自己通过 AOP 的方式添加适合于我们自己的监控代码，而并不需要引入太多的新技术和新概念。而且在未来业务发生变化的时候，Pinpoint 官方提供的报表是否能满足要求也不好说，增加新的报表也会带来不可以预测的工作难度和工作量。
最后还要考虑日志收集（直接发送、记录到本地再上传）、日志接收（消息队列，直接进入ElasticSearch）、数据清洗（Logstach、Storm、SparkStreaming）、日志存储（Mysql、Hbase、ElasticSearch）、页面展示（自研还是直接用第三方的）。