微服务应用性能分析实战08 工匠精神：熟悉 APM 产品的能力是 RD 的分内之事

这一讲我将带你横向回顾下模块一各个章节的关键知识点，并简单铺垫下之后的章节。

在前面的章节，我带你学习了 7 个 APM 开源产品的学习方案和落地实践。由于章节有限，很可能课程所讲述的 APM 产品没有命中你们的选型。但没有关系，APM 协议与存储模型，以及关键模块的设计都大同小异，我会在接下来的章节中继续与你分享。

今天这一课时，我会围绕以下四个问题展开，告诉你“熟悉 APM 产品的能力是每个开发人员的分内之事”这一道理。

需要部署全部 APM 产品吗？
部署前对 APM 如何选型？
APM 是如何体现工匠精神的？
如何高效学习 APM？

服务集群需要部署全部 APM 产品吗？

在学习任何一门新技术前，我们都会想要通过简短的“白话”，来了解这门技术是什么。所以在深度钻研 APM 前，让我们先回答“APM 到底是什么”这个问题。

你可以结合日常所接触的 APM 产品，以及前面章节对热门 APM 的学习进行几分钟思考，心中先有份自己的答案。

那我给出的答案是：APM 是应用性能管理（Application Performance Management）的缩写。从宏观角度上看，面向解决产品（对用户）体验不好的行为，都可以称为 APM，因此 APM 涉及的范畴非常广泛。大到前 7 个课时所讲述的 APM 各个领域的优秀开源产品，小到一线开发人员通过规范应用日志来提升定位问题的效率，这些都是在进行 APM 的建设。

APM 生态如此庞杂，为了让 APM 产品的功能建设更有目的性，也让问题定位时挑选 APM 产品更有针对性，所以 APM 细分了很多的领域。由于细分领域太多，下面我针对前面章节提及的APM 产品，来讲述这些产品都涉及哪些 APM 领域：

APM 产品	涉及的 APM 领域
Apache SkyWalking	指标监控集群拓扑链路追踪性能剖析日志监控集中报警
点评 CAT	指标监控链路追踪（不推荐使用） BI 监控（不推荐使用）集中报警
Alibaba Arthas	性能剖析在线故障排查 JVM 监控
Alibaba Sentinel	集群可用性流量可塑性
Java VisualVM	性能剖析在线故障排查 JVM 监控
Kibana	应用日志可视化
Grafana	监控数据可视化集中报警

可以看到，这些 APM 产品间涉及的领域都是有交集的，由于每个领域的生态都很大，所以每个 APM 产品对每个领域的实现是截然不同的，有足够的差异化。但具体到领域某个点的实现原理上却是大同小异，所以懂得原理可以让我们对 APM 的相应领域一通百通；并且熟悉差异化的产品实现可以让我们在定位问题时，能够挑选到合适的工具去剖析问题。

以性能剖析领域中的线程剖析为例，我们体会下上面这段话。

Apache SkyWalking
- 通过链路追踪页面获取慢链路的 Endpoint；
- 再通过性能剖析页面上的输入框，描述你要剖析的 Endpoint；
- 最后 SkyWalking 会通过抽样展示这个 Endpoint 关联的线程堆栈信息。
Endpoint（端点），SkyWalking 通过端点这个术语来定位要剖析的线程，你可以简单认为是请求，在“15 | 数据磐石：APM 收集端的存储模型”中我会再详细讲述。
Alibaba Arthas
- 通过日志上的数据面板（dashboard）命令或线程（thread）命令，获取想要 Dump 的线程 ID；
- 再通过线程命令，追加线程 ID 参数获取线程的堆栈信息；
- 最后通过各种在线故障排查命令，从而去诊断问题。
Java VisualVM
- 通过应用服务使用日志框架中打印的线程名称，或 VisualVM 可视化客户端的线程选项卡展示的应用名称，从而获取线程实时工作状态；
- 再通过线程名称，使用 Threads intspector 插件获取线程的堆栈信息；
- 最后使用各种插件进行问题诊断。

综上，产品呈现上的差异造就了不尽相同的使用场景，但原理上都是通过一定的手段（滑动窗口、线程名称、线程 ID）去找到线程，对线程进行 Dump，最终得到堆栈信息。通过对底层原理的组合封装，就可以构造出十八般兵器。

那我们的服务集群需要部署全部的 APM 产品吗？答案是否定的。

过多 APM 产品在运维上，会给 SRE 带来大量的维护工作量；在提效上，一线开发人员在日常需求开发之余，需要抽出更多时间去学习各种 APM 产品；从全局角度看，多数人基本会学一个忘一个，更别提学以致用了。

所以这时候更需要去精简 APM，在部署前注重选型，在落地后注重本地化建设。 本地化建设我会在之后的章节详细与你讨论，这里我主要讲述下部署前的选型。

部署前对 APM 如何选型？

选型我也建议使用竞品分析法，但竞品分析需要建立在了解自身的需求和一定程度的掌握 APM产品的基础上。

了解自身需求，你可以根据调查问卷收集和故障积累，来分析出内部诉求那些 APM 领域的产品；
之后通过本专栏的学习以及网上博客的竞品分析，你就可以开展选型方案了。

以下有一些我总结的实践，方便你避坑。

1.不正确的选型思路

囫囵吞枣式选型 ×
忽略自己的需求和忽略 APM 产品涉及的领域进行竞品分析，网上的博客也不胜枚举。比如将点评 CAT 与 Apache SkyWalking 进行对比就不合适。两个产品虽然涉及领域存在部分交集，但在部署方式、关键技术栈、核心领域的实现上却大相径庭。随便选出一个差异点就开始进行选型对比，这是一种错误行为，这种情况并不适合做竞品分析。

所以反过来，使用 Apache SkyWalking 和 Pinpoint 进行竞品分析就很有代表性，从 Agent 的接入方式、轻量级内核、插件化生态的对比，到链路跟踪模型、仪表盘指标都有相似的地方。这种情况就比较适合开展竞品分析，并最终确定适合自身的选型。

性能主导式选型 ×
选型追求极致的性能，这种选型思路也是不可取的。就国内现状，所有的应用服务几乎都是运行在中水位线以下；随着现阶段的服务上云化，应用服务的部署会获得更多弹性。所以现阶段 APM 选型应更注重产品能力而非性能指标。

而且目前活跃的 APM 产品几乎都有 Apache、Alibaba 等顶级社区的背书，其质量我也不需要过多赘述。所以我们选型时的关注点要适合当下，并着眼未来的进行。

完全自建型 ×
每个产品都不是完美无缺的，正因为这样我们才可以动手参与社区共建。也正是这样，才会有更多人和我一样，从中得到成长成为 Apache 和 Alibaba Committer，这个成长路径也是本专栏我要和你分享的内容之一。说回来，我也看过很多自建型的 APM，即使有专业性的团队，也绕不开首次落地实践过长、被质疑闭门造车这两个问题。

2.比较好的选型思路

量化历史包袱 √

比如好多月都没有上线老项目、老架构了，这些老项目表象上看依然在为企业带来收益。但由于长期不迭代，就会出现维护人员薄弱的情况。这时便没人能评估应用服务接入 APM 后会不会出现问题，以及接入 APM 带来的收益。

这些具备历史包袱的项目是影响 APM 选型的重要指标之一，因为应用集群接入 APM 覆盖度越高、数据完整度就越高，报警定位就会更准确。

为了解决这些老项目的接入难题，我通过量化老项目各个指标的手段，来确定选型 APM 的正确性。

如果你负责的集群也存在同样的历史包袱问题，你可以参考我的实践。

通过发布平台或脚本，计算出应用最后的发布时间。时间越久远，接入 APM 的收益就越小。你可以抽取采样几个时间节点来绘制出历史项目的分布。
通过编译，分析出是否支持编译发布和依赖框架的明细。对不支持编译发布的老服务选型，我推荐 Agent 类型的 APM 产品；依赖框架的明细，方便我们确定是否还要做二次框架适配。