开发者学堂课程【分布式链路追踪 Skywalking：APM 系统概述】学习笔记，与课程紧密连接，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/743/detail/13151
APM 系统概述
什么是 APM 系统
由于 Skywalking 本质上是一个 APM 系统，因此了解 APM 系统能够更好理解 Skywalking。
1.APM 系统概述
（1）APM(Application Performance Management) 即应用性能管理系统，是对企业系统即时监控以实现对应用程序性能管理和故障管理的系统化的解决方案。应用性能管理，主要指对企业的关键业务应用进行监测、优化，提高企业应用的可靠性和质量，保证用户得到良好的服务，降低总拥有成本。
APM 系统是可以帮助理解系统行为、用于分析性能问题的工具，以便发生故障的时候，能够快速定位和解决问题。
解析：APM 的英文全称是 Application Performance Management，即应用性能管理系统。主要是为了聚焦线上应用程序的一个性能指标，通过性能指标可以解决线上出现的问题，当故障发生时，通过 APM 系统能够快速定位到问题产生的位置，达到快速解决问题的效果。系统不只保障了它的高可靠性和应用的质量，同时保障了用户可以得到更好的服务，还可以降低 APM 的成本。
2.分布式链路追踪
随着分布式系统和微服务架构的出现，一次用户的请求会经过多个系统，不同服务之间的调用关系十分复杂，任何一个系统出错都可能影响整个请求的处理结果。以往的监控系统往往只能知道单个系统的健康状况、一次请求的成功失败，无法快速定位失败的根本原因。
解析：分布式链路追踪是 APM 系统的核心概念，在如今微服务架构普及的情况下，一次请求可能会经过多个系统，如图：
用户的请求可以通过后台管理系统的认证服务、消息服务和缓存服务以及访问数据库的流程。当其中的某个节点出现异常，如消息服务出现异常，此时缓存服务、调用消息服务和认证服务调用申请也会失败；
（1）分布式系统的问题
①如果要发现是消息服务出现异常，是比较困难的，因为这个链路比较长而且横跨了多个系统，收集日志的工作也会更加复杂，此时如果想解决问题需要一个系统帮助，
②系统在线上的指标是否能被评估出来，这个问题是比较困难解决的。
③系统之间的调用变得很复杂，为了方便查看认证服务有多少在被调用，调用关系是否正常，需要详细分析系统之间调用的 top 图，这是一个单靠人工无法解决的问题。
④性能分析：一个服务依赖很多服务，被依赖的服务也依赖了其他服务。如果某个接口耗时突然变长了，那未必是直接调用的下游服务慢了，也可能是下游的下游慢了造成的，如何快速定位耗时变长的根本原因呢？
⑤链路梳理：需求迭代很快，系统之间调用关系变化频繁，靠人工很难梳理清楚系统链路拓扑（系统之间的调用关系)。
为了解决这些问题，最早是 Google 发布论文 Dapper ，根据这个论文推出了一个分布式链路跟踪系统,之后各个互联网公司都参照 Google 的这套系统去实现自己的分布式链路跟踪系统，而这些系统就是分布式系统下的 APM 系统。所以 APM 系统的核心就是分布式链路追踪。
3.什么是 Open Tracing
各个互联网公司参照 Google 实现了自己的分布式链路追踪，但是各家实现的方式是不一样的，因此如果想从某家的实现替换到另外一家，替换的成本是很高的。
于是出现 Open Tracing 这种规范，类似 GP 规范，也是一种抽象的比较高级的 API ，让不同的厂商去实现，使用 GP 规范可以替换底层的实现，无需进行代码的修改，所以 Open Tracing 的普及度比较高，减少了成本。
（1）分布式链路跟踪最先由 Google 在 Dapper 论文中提出，而 OpenTracing 通过提供平台无关、厂商无关的 API，使得开发人员能够方便的添加（或更换）追踪系统的实现。
下图是一个分布式调用的例子：
客户端发起请求，请求首先到达负载均衡器，接着经过认证服务，订单服务，然后请求资源，最后返回结果。
首先能看到这个调用关系图，从客户端出发，通过负载均衡，到达权限服务、订单服务和资源服务，调用其中的接口，这张图可以很直观的看出服务之间的调用关系，但是无法告知用户调用的性能的瓶颈。比如看到这张图，有两个问题：第一，这些箭头没有标识出执行的时间，所以无法得知每次调用的耗时是多少。第二，这些调用可能有并行的情况但是在图上无法显示，我们能通过数字感知它的顺序但是并行无法判断。
所以，使用 Open Tracing 可以更好的展现一个调用过程，如图：
这张图的横轴是时间，在横轴上方每一个调用过程使用不同的色块来表示，可以看到，客户端调用过程所在的节点位置在资源的分配和提供过程上耗时最长，因为它横跨的长度是最长的，所以耗时也是最长的。而这个过程分为两个部分，一部分是容器的初始化和分配存储空间，另一部分是执行启动脚本，第一部分是一个并行执行，即容器的初始化和分配存储空间是并行执行，它们的时间也比较长，同时再执行一个执行启动脚本，加上这两个，资源的分配和提供过程就变得耗时。在这张图上可以看到服务的耗时情况以及服务的并行运行情况，基于 Open Tracing 可以直观的画出这张图，Skywalking也是基于 Open Tracing 来构建。
4.主流的开源 APM 产品
（1）PinPoint
Pinpoint 是由韩国进行开发的，最大的优点是对代码的无侵入性，即不修改代码，使用 PinPoint 来监控系统，同时 PinPoint 的UI 页面的元素非常丰富，用户体验很好。但是 PinPoint 有一个比较大的缺点，它收集了很多的数据导致整体的性能比较差。
（2）SkyWalking
SkyWalking 是 apache 基金会下面的一个开源 APM 项目，在最近几年风头很盛，版本的更迭速度很快，以及由去年的5.0版本升级到今年的6.5.0版本。它是为微服务架构和云原生架构系统设计，所以 SkyWalking 很注重性能的指标，同时它对一些 RPC 框架能够提供支持，如国产的 double 等，它通过探针自动收集所需的指标，并进行分布式追踪。通过这些调用链路以及指标，Skywalking APM 会感知应用间关系和服务间关系，并进行相应的指标统计。Skywalking 支持链路追踪和监控应用组件基本涵盖主流框架和容器，如国产 RPC Dubbo 和 motan 等，国际化的 spring boot，spring cloud。
（3）Zipkin
Zipkin 是由 Twitter 开源，是一款分布式链路调用监控系统，最大的优点是简单易用，Zipkin 本身就与 spring cloud 有很好的继承性，spring cloud 建议在 cloud 框架下
使用 Zipkin 来做分布式链路追踪。聚合各业务系统调用延迟数据，达到链路调用监控追踪。Zipkin 基于 Google 的 Dapper 论文实现，主要完成数据的收集、存储、搜索与界面展示。
（4）CAT
CAT 是由大众点评开源的项目，它的版本相对来说古老一些，但是也有自己的优点，如它的报表功能比较完全，是基于 Java 开发的实时应用监控平台，包括实时应用监控、业务监控，可以提供十几张报表展示。一个很大的缺点是它的代码有侵入性，即使用 CAT 必须进行代码的更改。对一些框架的使用进行白点，白点处理后才能进行数据的报告。
