apm微服务选型（分布式链路调用跟踪系统）

业界大部分的应用分布式追踪的原理源自 Google 的一篇 Dapper 系统的论文。Dapper是谷歌内部使用的分布式链路追踪系统，虽然没有开源，但是Google在其2010年发布的一篇论文中对其进行了详细的介绍。可以说，Dapper是链路追踪领域的始祖，其提出的概念和理念一致影响着后来所有的分布式系统链路追踪系统，包括阿里的鹰眼系统，大众点评的cat系统，Twitter的Zipkin以及开源的Jaeger等等。

Dapper的分布式跟踪

一. 为什么需要分布式调用跟踪

随着分布式服务架构的流行，特别是微服务等设计理念在系统中的应用，系统架构变得越来越分散，如下图所示:

　　分布式服务拆分以后，系统变得日趋复杂，业务的调用链也越来越长，如何快速定位线上故障，就需要依赖分布式调用跟踪技术。可以看到，随着服务的拆分，系统的模块变得越来越多，不同的模块可能由不同的团队维护，一个请求可能会涉及几十个服务的协同处理， 牵扯到多个团队的业务系统。　　假设现在某次服务调用失败，或者出现请求超时，需要定位具体是哪个服务引起的异常，哪个环节导致的超时，就需要去每个服务里查看日志，这样的处理效率是非常低的。　　另外，系统拆分以后，缺乏一个自上而下全局的调用 ID，如何有效地进行相关的数据分析工作呢？比如电商的活动转化率、购买率、广告系统的点击链路等。如果没有一个统一的调用 ID 来记录，只依靠业务上的主键等是很难实现的，特别是对于一些大型网站系统，如淘宝、京东等，这些问题尤其突出。

二. 分布式链路调用跟踪的业务场景　　分布式调用跟踪技术就是解决上面的业务问题，即通过调用链的方式，把一次请求调用过程完整的串联起来，这样就实现了对请求调用路径的监控。　　分布式调用链其实就是将一次分布式请求还原成调用链路，显式的在后端查看一次分布式请求的调用情况，比如各个节点上的耗时、请求具体打到了哪台机器上、每个服务节点的请求状态等。　　一般来说，分布式调用跟踪可以应用在以下的场景中。

　　1）故障快速定位：通过调用链跟踪，一次请求的逻辑轨迹可以完整清晰地展示出来。在开发的过程中，可以在业务日志中添加调用链 ID，还可以通过调用链结合业务日志快速定位错误信息。　　2）各个调用环节的性能分析：在调用链的各个环节分别添加调用时延，并分析系统的性能瓶颈，进行针对性的优化。　　3）各个调用环节的可用性，持久层依赖等：通过分析各个环节的平均时延、QPS 等信息，可以找到系统的薄弱环节，对一些模块做调整，比如数据冗余等。　　4）数据分析等：调用链是一条完整的业务日志，可以得到用户的行为路径，并汇总分析。

三、分布式追踪系统

• 大众点评的CAT: 跨服务的跟踪功能与点评内部的RPC框架集成，这部分未开源且项目在2014.01已经停止维护。服务粒度的监控，通过代码埋点的方式来实现监控，比如：拦截器，注解，过滤器等，对代码的侵入性较大，集成成本较高。
• 京东的Hydra: 与dubbo框架集成，对于服务级别的跟踪统计，现有业务可以无缝接入。对于细粒度的兴趣点，需要业务人员手动添加.开源项目已于2013年6月停止维护
• PinPoint-naver，字节码探针技术，代码无侵入，体系完善不易修改，支持java,技术栈支持dubbo。其他语言社区支援中
• zipkin：java 方便集成于 springcloud，社区支持的插件也包括dubbo、rabbit、mysql、httpclient等，同时支持php、go、js等语言客户端，界面功能较为简单，本身无告警功能，可能需要二次开发。代码入侵度小。
• uber-jaeger：Jaeger支持 java、c 、go、node、php，在界面上较为完善（对比zipkin），但是也无告警功能。代码入侵度小。dubbo目前无插件支持，可二次开发。
• Apache SkyWalking：类似于 PinPoint，网上吞吐量对比中强于 pinpoint，实际未验证。本身支持dubbo。 官网 http://skywalking.apache.org/。
• SpringCloud Sleuth：它集成了 Zipkin、HTrace 链路追踪工具，用服务链路追踪来快速定位问题。