跟着小红书事务的快速开展，资源耗费和本钱压力明显增加。在降本增效的大布景下，咱们建设了功能继续优化 & 追寻渠道，来系统性辅佐事务团队处理功能问题，在事务系统日常的演化过程中，继续跟进、追寻系统的功能退化并推进优化。
现在，这一渠道已掩盖小红书搜索、引荐、广告的 S0 服务，运转两个多月以来，辅佐事务团队存量优化超1万 CPU 核；发现功能退化超1万 CPU 核并跟进优化。
1. 布景
当时，小红书正处在快速开展期间，流量的快速上涨和事务的快速迭代，明显增加了资源耗费和本钱压力。
在存量的资源占用上，咱们要求研制人员对使用做尽可能深度的功能优化。但是，研制人员在对自己的模块做功能优化时，往往短少东西来辅佐剖析，东西的合理挑选、环境装备、使用方法等各个方面，都有较高的学习本钱。
另一方面，当时功能优化首要依托个人经历进行逐个剖析，缺少通用化的机制，经历较难在团队间共享。即使有人发现一个通用的功能问题，也很难衡量其触及的模块和全体的优化空间。
此外，小红书事务的日常迭代往往会带来增量的资源耗费，即功能退化。 特别是关于频繁迭代的模块，如一些引荐使用，每天进行发版且每个版别触及十屡次不同的提交。在这些提交中，可能会隐藏着一些功能退化点。明显的功能退化点会在功能压测中被发现，而更多的功能退化往往是细小的，比方一个 commit 带来了全体 CPU 1% 左右的占用，这样细小的退化是隐蔽的，经过常规压测等手段比较难以发现。
跟着事务的迭代，铢积寸累下，多个细小的功能退化会导致使用全体功能的明显恶化，进而积重难返。经过一段时刻的堆集后，在排查这种问题时，面对动辄上百次的代码提交前史，开发同学很难排查出真实导致功能退化的提交是什么。最终只能以安稳性的名义增加资源扩容，这样的状况屡次产生。
针对此，咱们测验从全体上处理功能问题，规划开发了一套功能优化和继续追寻的渠道，来辅佐使用研制人员剖析功能问题，一起在日常的事务系统演化过程中，继续跟进、追寻系统的功能退化并推进优化。
2. 思路
咱们的方针是从全体上处理功能问题。
问题首要聚集在以下三个方面：
存量功能优化： 对使用进行全方位的深入剖析、确诊、优化；优化的经历堆集后，横向扩展，做到通用的优化
增量功能退化阻拦： 事务迭代过程中，自动发现使用的增量资源占用，即功能退化
功能安稳性问题： 对一些突发的功能恶化导致的安稳性问题，快速定位原因
对应的全体技能思路：
剖析手段： 根据 profiling 等采样手段，来对使用进行剖析
产品化： 做到渠道化来进步易用性，研制人员可以尽可能低门槛、高效的使用；
继续优化： 在机制上做到继续优化，将采样剖析做到常态化、例行化，将功能优化、剖析、防退化，融入到事务使用的日常迭代中，重视使用的每一个版别、每一次代码提交、每一个策略试验进行，继续追寻事务使用的功能表现。
3. 全体计划
咱们的内部落地全体架构如下：
中心思路是经过对事务进程进行继续性的采样、处理、存储，并根据采样数据做剖析，来辅佐功能优化和发现功能退化。
数据采样上，咱们用单机低频次继续采样，降低本钱，减少对使用的影响。
在剖析上，数据来自大数据存储，并从纵向、横历来比照剖析：在纵向上，选用 merge + diff 剖析，来发现退化点；在横向上，供给跨使用的通用查询才能，查询、剖析函数粒度的资源占用。
3.1 数据采集、处理、存储
3.1.1. 数据采集
当时首要的数据采集方法是经过对进程进行 profiling，profiling 的原理是根据一定的频率对运转进程进行采样，来了解进程的特征。当时，profiling 支撑从多个方面对程序进行采样剖析，如 CPU、Memory、Thread、Lock、I/O 等。日常使用中，对 CPU 进行 profiling 的使用最为广泛。
一般的 CPU profiling 是 On-CPU，也便是 CPU 时刻花费在哪些代码履行上。在 On-CPU 之外，还有 Off-CPU，指的是进程不在 CPU 上运转运转的时刻，比方进程因为 IO、锁等原因处于等候，花费了时刻。所以，Off-CPU 是对 On-CPU 的弥补，全体联系如下：
依据使用的实际状况，归纳的对 On-CPU、Off-CPU 进行采样，更为全面地了解程序的运转状况。
在多言语支撑方面，当时咱们支撑 C++、JAVA、Golang 等主流言语：
C++ 使用： 经过 Linux perf
JAVA 使用： 现在主流计划（如 IntelliJ IDEA 和阿里的 Arthas）是经过 Async-profiler 来完成 profiling。Async-profiler 是将 Perf 的仓库追寻和 JDK 供给的 AsyncGetCallTrace 结合了起来，低开销的支撑多种 Perf event。咱们的计划里也凭借了这个东西，并针对咱们的需求进一步做了定制开发
Golang 使用： 经过 Golang 内置的 pprof
在采样方法上，咱们支撑定时、自动和条件触发三大方法。当时，小红书的线上使用根本敞开了常态化、定时的 profiling
3.1.2 事务接入
采样的 agent 以 daemonset 方法布置，支撑对物理机上的多个事务 pod 进行采样。对使用的采样敞开、关闭是经过装备中心来下发。此外，支撑更多的采样装备，如：单次采样的采样频率、采样时刻装备；屡次采样之间的采样周期；采样方法切换等。
因而，咱们当时做到了事务无感知接入，接入在分钟等级生效。
3.1.3 存储
在采样完毕后，对采样后的数据进行解析、处理，如依据函数调用链核算 sample 数、过滤占比过低的函数调用链等。处理后，咱们将数据进行存储，用于后续的剖析。咱们的存储计划挑选的是 clickhouse，在存储 profiling 的数据之外，一起会把相关的环境变量信息一起存储，如使用名、使用版别、机房等。此外，采样后生成单 Pod 的火焰图，将火焰图压缩并保存在方针存储中，如腾讯云 cos。
3.1.4 资源耗费
在本钱上，单次采样的继续时刻一般不超越一分钟，屡次采样之间的周期间隔是小时等级，因而对使用程序根本没有影响；单次 pod 单次采样，经处理并保存到 clickhouse 的数据在千行的规模。所以全体的项目本钱根本是存储本钱，即 clickhouse 和方针存储，都很廉价，全体近乎零本钱。
3.2 存量优化
3.2.1 方针
依据咱们的观察和经历，一线研制同学对出产服务的确诊剖析诉求长期是被约束的，首要原因在：
公司出于安全需求，会对出产环境的网络和权限进行管控。
这导致一些确诊会非常费事，例如，小红书有一些系统选用了超大 Java Heap，如果要对此使用做堆剖析需求的步骤：
-
dump 堆到本机指定为止；
-
传输 hprof 文件到指定跳板机；
-
从跳板机下载 hprof 文件到本地；
-
本地需求花数小时对 hprof 文件建索引，关于几十 GB 的堆，本地往往因为机器功能不够，最终可能仍是无法完结剖析；
经过一些确诊东西，咱们可以观测到许多系统运转目标，但对目标的解读往往需求许多经历和对事务的理解。
如运转 free 命令，咱们可以得到系统的内存使用目标（free/buffer/cache）。但是这些目标究竟意味着什么？对一个特定的使用，当时水位是否合理？这对使用者是有较高的根底和事务布景知识要求。
因为这些约束和不便利，使得咱们一线资深研制同学日常对功能的重视逐渐变少，而一些新同学更是望而却步。最终系统因为缺少“体检”，既不能治于未病；又因缺少对系统的满足认知，导致需求治疗时又无从下手。
为此，咱们设定了一个小方针：把确诊变成一个日常触手可及的事：
开箱即用：
咱们将一些常用的东西打包成一个东西箱，一键（或默认）安装到方针容器里；
白屏化：
一切操作都在网页上经过点击拖拽完结，研制同学不需求记住许多命令参数，一起对东西的输出做解析和解释；
知识库：
纵向上，咱们会堆集前史目标供参阅。横向上，咱们会总结一些共性的优化点供研制同学参阅。
3.2.2 东西
3.2.2.1 根底信息展现
这部分首要展现一些进程和环境相关的根底信息，OS、JVM、机器装备、启动参数、环境变量等。便利用户迅速了解一些使用的根本信息。
3.2.2.2 运转时目标
这块首要涵盖一些秒级运转时的 Metrics（如 CPU 利用率，GC 信息），loaded class，线程池状况等。这块作为大盘目标的弥补，在 agent 测内嵌了一个小型的时序数据库，直接在端上存储几个重要的秒级目标。协助用户捕捉一些更细粒度的信号。
3.2.2.3 采样&剖析
现在咱们首要供给了针对 Java 的一些在线剖析才能。关于 Java 程序，现在使用频率最高的是堆剖析，用户可以在渠道上一键触发 Heap dump，dump 文件生成后会自动上传到内部布置的 apache-jifa worker 上，用户可以在列表里边找到对应的入口，跳转到 jifa 页面去做具体的堆剖析。
一起，根据 profiling 东西，如 async-profler，用户可以一键生成 cpu、alloc 及 lock 的火焰图，并在线展现。经过这些火焰图，能很便利找到系统的一些热点，然后有针对性的去优化。
3.2.3 通用优化机制
在存量优化方面，咱们的一个创新点便是通用优化机制。在对各使用进行常态化的 profiling 后，咱们有了一切使用的功能原始数据，进一步的主意便是大数据检索：经过众多的功能优化 case 后，将常见的根底库和已知的通用功能问题抽象成规则库，然后可以匹配其在线上一切模块的耗费占比和全体占用核数，来发现更多优化空间，到达批量优化而且追寻优化的效果。
下图所示，为线上一个根底库 SDK 在各个使用中的资源耗费状况，别离核算了 CPU 占比和对应的核数。在此根底上，批量的推进使用进行优化。
3.3 功能继续优化
3.3.1 全体思路
针对事务迭代过程中产生的功能退化，继续跟进、追寻。
全体的思路是：首先是发现功能退化点，准确到函数等级；并进一步相关、发现对应的改变事情(代码提交、算法试验等)；后续跟进整个功能退化的生命周期，推进优化，直到最终处理功能退化。
3.3.2 发现
3.3.2.1 机制
首先是自动化巡检，即每天会定期查看接入的服务是否存在潜在功能退化，经过昨天和前天晚顶峰功能数据，查看各使用是否有功能退化状况，并推送到相关企微群。
此外，经过接入 QA 流水线、上线渠道等方法，在上线前、上线后回调，更早期阻拦功能退化。
3.3.2.2 发现方法
经过功能数据 merge + diff 剖析：依据查询条件，在将新版别和基准版别别离进行数据聚合后，进行比照；经过剖析比照后的 diff，发现异常改变点并判断是否有功能退（准确到函数）。当时支撑机房、版别和时刻区间等多种条件。
此外，为了衡量功能退化点的影响，将退化的程度与对应占用的 CPU 核数相相关，也可以让研制人员们了解对应退化点关于系统全体功能的影响，有更直观的感受。
3.3.2.3. 退化点展现
火焰图是一种比较抱负的展现函数调用联系的方法，一起也可以便利的定位其在全体中的位置。因而，咱们经过定制化的差分火焰图，展现退化点对应的具体函数栈状况，并用颜色来标记、杰出功能退化点，用不同的颜色来区分退化的程度；一起在火焰图上展现对应的 CPU 核数，来强化退化程度，增加火焰图的表达内容。
此外，为了支撑版别间消失的代码逻辑，使用了消失火焰图。这样，组合起来，可以展现两个版别之间函数栈的新增、修正、消失等场景。
在技能完成上，咱们在开源的 flamescope根底上定制开发，进行实时进行处理和渲染，依据需求可以灵敏的支撑各种使用场景。一切的火焰图和 diff 核算均从 clickhouse 中读取数据处理。
线上的一个实际功能退化例子如下，其中差分火焰图中展现了退化点对应的函数调用、退化对应的 CPU 核数；消失火焰图展现了版别之间消失的代码逻辑。
3.3.3 定位改变
在确认功能退化后，依据功能退化的状况（如退化的时刻点、函数栈），检索使用对应的改变事情，如算法试验改变、装备中心下发改变、上线记录等。未来，会进一步测验依据函数栈来管理 git 的提交状况，相关可能代码提交。
3.3.4 继续追寻
为了便利追寻功能退化问题的进度，咱们会把核实过的信息推送至内部危险渠道来录入留痕，而且经过趋势图追寻优化状况。
如上图所示，这是一个线上使用功能退化的实际 case，经过函数调用链的 CPU 使用率趋势图可以看出功能退化产生的起始点，一起可以看出该功能退化是否得到了修正、何时修正，这样可以明晰的看到功能退化问题的过程，便利继续追寻功能问题。
3.4 功能异常问题定位
在采样的方法上，支撑条件触发方法，即装备描述异常态的触发条件(比方 CPU 突涨等)，当满足条件时进行数据的采集和上报。再根据上述的 merge + diff 数据剖析方法，将异常态和正常态的数据别离进行汇聚后，做比照剖析，经过 diff 剖析来定位出导致突涨的根因，一起相关对应的改变。
4. 展望
未来，咱们期望可以去探索更多的功能优化手段，如 PGO；以及根据 PMU 目标，探索 “内存大页”等技能落地；一起，咱们也期望可以收集更多的功能目标，如 walltime、cpu cache、mem bindwith 等，来掩盖更多的功能剖析场景。
5. 作者简介
韩柏：技能部/可观测技能组小红书可观测技能工程师，结业于上海交通大学，从事引荐架构、根底架构工作，在可观测、云原生、中间件、功能优化等方面有较为丰厚的经历。
小粟：技能部/可观测技能组小红书可观测技能工程师，结业于西安交通大学，先后在引荐架构、云原生、可观测范畴从事相关工作，现专心于通用日志系统的建设。
苏星河：技能部/可观测技能组小红书可观测技能工程师，结业于南京大学核算机系，之前在小红书供应链管理、大数据、引荐等许多事务堆集了丰厚的经历，最近在专心JVM在线确诊及功能优化相关的工作。
