几种分布式调用链监控组件的实践与比较（二）比较
https://blog.csdn.net/ityouknow/article/details/82393102
引言：继上篇《几种分布式调用链监控组件的实践与比较（一）实践》后，本篇将会讲下几种APM选型的比较与性能测试。
1. 前文回顾
上一篇文章主要讲了三种分布式调用链监控组件的实践。问题的背景由微服务架构展开，微服务的好处已经不用多说，而微服务的多了之后，千头万绪，下面这张图经常被用到。
系统的复杂度因此提升。系统越复杂，越难解决问题，例如系统失败或者性能问题。在三层架构中找到解决方案还不是太难，仅仅需要分析3个组件比如web服务器，应用服务器和数据库，而服务器数量也不多。但是，如果问题发生在n层架构中，就需要调查大量的组件和服务器。另一个问题是仅仅分析单个组件很难看到大局;当发生一个低可见度的问题时，系统复杂度越高，就需要更长的时间来查找原因。最糟糕的是，某些情况下我们甚至可能无法查找出来。
上面其实已经提到存在的故障定位问题，基于微服务体系之下构建的业务系统存在的问题基本上分为三类：
-
故障定位难，一个简单操作，其背后可能是由十几个微服务共同完成的，这些微服务也由不同的团队去负责。一旦出现问题，最坏情况下我们也许需要这十几个团队一起来解决问题。
-
链路梳理难，应用没有形成应用拓扑，不知道自己的服务下游会影响其他哪些人。
-
资源浪费多，容量预估难。对于一些服务，其消耗的cpm和memory可能连10%不到，远远没有充分利用物理机。这其实和容量预估关联，过大或者过小估算峰值的机器容量，都是浪费。
APM主要的目的就是解决上面所说的这四个问题，主要的手段是通过收集、存储、分析、分布式系统中的调用事件数据，协助开发运营人员进行故障诊断、容量预估、性能瓶颈定位以及调用链路梳理。第一篇其实已经讲过链路监控组件的需求：
-
代码的侵入性
-
探针的性能消耗
-
全面的调用链路数据分析
-
可扩展性
这边列一下pinpoint在其wiki中提到的几点：
-
分布式事务跟踪，跟踪跨分布式应用的消息
-
自动检测应用拓扑，帮助你搞清楚应用的架构
-
水平扩展以便支持大规模服务器集群
-
提供代码级别的可见性以便轻松定位失败点和瓶颈
-
使用字节码增强技术，添加新功能而无需修改代码
下面我们沿着这些需求，看一下这几种分布式调用链监控组件。
2. AMP比较
上面列了需求，但是不够通用，笔者将需要对比的项提炼出来：
-
探针的性能
主要是agent对服务的吞吐量、CPU和内存的影响。微服务的规模和动态性使得数据收集的成本大幅度提高。 -
collector的可扩展性
能够水平扩展以便支持大规模服务器集群。 -
全面的调用链路数据分析
提供代码级别的可见性以便轻松定位失败点和瓶颈。 -
对于开发透明，容易开关
添加新功能而无需修改代码，容易启用或者禁用。 -
完整的调用链应用拓扑
自动检测应用拓扑，帮助你搞清楚应用的架构
笔者根据主要的需求，提炼出如上五点。
2.1 探针的性能
笔者其实也是比较关注探针的性能，毕竟APM定位还是工具，如果启用了链路监控组建后，直接导致吞吐量降低过半，那也是不能接受的。笔者对skywalking、zipkin、pinpoint进行了压测，并与基线（未使用探针）的情况进行了对比。
选用了一个常见的基于Spring的应用程序，他包含Spring Boot, Spring MVC，redis客户端，mysql。 监控这个应用程序，每个trace，探针会抓取5个span(1 Tomcat, 1 SpringMVC, 2 Jedis, 1 Mysql)。这边基本和skywalkingtest的测试应用差不多。
模拟了三种并发用户：500，750，1000。使用jmeter测试，每个线程发送30个请求，设置思考时间为10ms。使用的采样率为1，即100%，这边与产线可能有差别。pinpoint默认的采样率为20，即50%，通过设置agent的配置文件改为100%。zipkin默认也是1。组合起来，一共有12种。下面看下汇总表。
从上表可以看出，在三种链路监控组件中，skywalking的探针对吞吐量的影响最小，zipkin的吞吐量居中。pinpoint的探针对吞吐量的影响较为明显，在500并发用户时，测试服务的吞吐量从1385降低到774，影响很大。然后再看下CPU和memory的影响，笔者是在内部服务器进行的压测，对CPU和memory的影响都差不多在10%之内。
2.2 collector的可扩展性
collector的可扩展性，使得能够水平扩展以便支持大规模服务器集群。
-
zipkin
在前一篇文章中，我们开发了zipkin-Server（其实就是提供的开箱即用包），zipkin-agent与zipkin-Server通过http或者mq进行通信，http通信会对正常的访问造成影响，所以还是推荐基于mq异步方式通信，zipkin-Server通过订阅具体的topic进行消费。这个当然是可以扩展的，多个zipkin-Server实例进行异步消费mq中的监控信息。
-
skywalking
skywalking的collector支持两种部署方式：单机和集群模式。collector与agent之间的通信使用了gRPC。 -
pinpoint
同样，pinpoint也是支持集群和单机部署的。pinpoint agent通过thrift通信框架，发送链路信息到collector。
2.3 全面的调用链路数据分析
全面的调用链路数据分析，提供代码级别的可见性以便轻松定位失败点和瓶颈。
-
zipkin
zipkin的链路监控粒度相对没有那么细，从上图可以看到调用链中具体到接口级别，再进一步的调用信息并未涉及。
-
skywalking
skywalking 还支持20+的中间件、框架、类库，比如主流的dubbo、Okhttp，还有DB和消息中间件。上图skywalking链路调用分析截取的比较简单，网关调用user服务，由于支持众多的中间件，所以skywalking链路调用分析比zipkin完备些。
-
pinpoint
pinpoint应该是这三种APM组件中，数据分析最为完备的组件。提供代码级别的可见性以便轻松定位失败点和瓶颈，上图可以看到对于执行的sql语句，都进行了记录。还可以配置报警规则等，设置每个应用对应的负责人，根据配置的规则报警，支持的中间件和框架也比较完备。
2.4 对于开发透明，容易开关
对于开发透明，容易开关，添加新功能而无需修改代码，容易启用或者禁用。我们期望功能可以不修改代码就工作并希望得到代码级别的可见性。
对于这一点，Zipkin 使用修改过的类库和它自己的容器(Finagle)来提供分布式事务跟踪的功能。但是，它要求在需要时修改代码。skywalking和pinpoint都是基于字节码增强的方式，开发人员不需要修改代码，并且可以收集到更多精确的数据因为有字节码中的更多信息。
2.5 完整的调用链应用拓扑
自动检测应用拓扑，帮助你搞清楚应用的架构。
上面三幅图，分别展示了APM组件各自的调用拓扑，都能实现完整的调用链应用拓扑。相对来说，pinpoint界面显示的更加丰富，具体到调用的DB名，zipkin的拓扑局限于服务于服务之间。
3. 总结
本文讲了三种分布式调用链监控组件的比较，主要从五方面着手，笔者对每一项都进了对比。至于具体选用哪款组件，大家可以根据实际的业务需求和场景进行选型，上面比较的数据仅供参考。这三款都是开源项目，一般公司都对针对实际情况进行一些二次开发，比如增加一些组件的支持、对接现存的大数据平台等等。
最后，看了eagleEye的相关介绍，想提下监控系统如何从被动报警转化为主动发现，其实和AIOps很密切。链路监控数据量很大，尽管可以通过压缩比来降低传输的数据量，但是我们真的需要存储每一条链路吗？是不是只需要识别每一个链路当中出现异常的情况。时序指标当中的异常点，那个时间点我们要识别出来。识别完了之后，对异常进行关联，定位出最后的问题。当然这个涉及到业务和应用系统层面，很复杂，但笔者认为是后面AIOps的大趋势。
参考：
-
Technical Overview Of Pinpoint
-
阿里微服务之殇及分布式链路追踪技术原理
