性能剖析利器-Conan｜得物技术

作者 / 得物技术 - 仁慈的狮子

目录

一、背景

    1. 局限性

    2. 向前一步

二、原理剖析

    1. 系统架构

    2. 工作模式

    3. reporter

三、稳定性验证

四、案例分析

五、写在最后

一、背景

线上问题的定位与优化是程序员进阶的必经之路，常见的问题定位手段有日志排查、分布式链路追踪和性能分析等，其中日志排查主要用来定位业务逻辑问题，分布式链路主要用来定位请求链路中具体是哪个环节出了问题，而如果服务本身的性能出了问题，如一段时间复杂度高的代码引发了CPU占比飙升、内存泄漏等，则需要依赖性能分析工具来帮我们定位此类问题。

在Golang技术栈中，pprof则是性能分析的一大杀器，它可以帮助我们获取到程序的运行时现场(profile data)，并以可视化的形式展示出来，火焰图是其中最为常见的一种展现形式：

我们如果想要借助pprof的能力进行性能分析，通常的步骤是：

• 程序中导入net/http/pprof包，并开放端口用于获取profile数据；

• 使用go tool中集成的pprof工具，访问端口下载profile数据，然后在本地对profile数据进行解析并可视化展示。

1.1 局限性

在微服务盛行的当下，很多系统根据业务发展需要，都被拆分成了几十甚至上百个微服务，就拿得物社区业务来讲，整体业务被拆分成了推荐服务、内容服务、引力服务、标签服务等数十个微服务，并且为了提高服务的可用性，每个服务又是以多实例的形式部署。如此多服务的如此多实例，在人力有限的情况下，很难做到一切都在掌控中，一旦线上某个服务的某个实例出现了异常，即便我们可以通过告警快速感知，但是也很难保证可以及时捕获到服务运行时的现场信息。下图所示的是实际生产环境发生过的一次异常，可以看出发生的时间是在凌晨，试问如果遇到这种情况，我们该如何应对？

因此可以说，仅仅凭借pprof提供的基础能力，我们很难应对在复杂的业务系统中突发的性能问题。

1.2 向前一步：

工欲善其事，必先利其器！

既然人为手动采集profile数据的方式不再适用，那就朝自动化的方向演进，于是，便诞生了Conan！Conan的核心功能包括profile数据自动化采集、存储和展示，旨在为Golang系统提供一套用于性能分析的自动化解决方案。

二、原理剖析

2.1 系统架构

Conan为常见的C/S架构，client端是集成了Conan SDK的应用，应用运行期间，SDK会负责在恰当的时机采集应用的profile数据，并上报到server端；server端我们使用Pyroscope进行搭建，Pyroscope是一个开源平台，算得上是持续化profiling中的代表之作，在Conan中，Pyroscope负责将client上报的profile数据进行高效存储，并提供可视化界面，支持以火焰图等多种形式展示这些profile数据。Conan整体架构如下图所示：

2.2 工作模式

前面提到，SDK会在“恰当”的时机采集应用的profile数据，那么这个时机该如何确定？其实，时机的确定也就是对应着不同的使用诉求，我们搜集了多位资深研发的宝贵建议，总结提炼得出了如下两种最常见的使用场景：

• 在应用真正发生性能问题的时候进行profile数据的采集，精准的捕捉问题现场；

• 持续化的采集，定期分析采集下来的pr