你好赵伟

这个屌丝很懒，什么也没留下！

热门标签

阿里云推出 3.x Java 探针，解锁应用观测与治理的全新姿势

作者：你好赵伟 | 2024-03-16 03:32:00

踩

前言

随着春节大促即将到来，为了确保线上业务高效稳定地运行，电商企业大多会对旗下关键业务应用进行多轮测试。通过模拟线上较高流量的请求，来观察服务性能的实际表现。以某企业的业务测试报告举例：

图 1 压测报告显示，成功率非常低，且全局接口成功率都很低

通过报告可以看到：当应用所承受的流量增加至特定临界点时，请求成功率大幅下降，导致整个测试周期内平均成功率相当惨淡，仅有 9.89%，并伴随着较高的响应时间（RT）。经过深入分析，发现这种高失败率现象普遍存在于所有接口上，并且在整个压测过程中未显示出任何回归稳定状态的迹象。

面对这类压测结果的直观推断是应用可能已达到其性能瓶颈。Prometheus 监控所采集的 CPU 使用情况进一步印证了这一假设：应用实例的 CPU 使用率几乎达到饱和状态，应用在当前情景下无法处理如此高 TPS（每秒事务数）。该企业采用的优化手段为：一方面，通过链路追踪（Tracing）数据和 CPU 火焰图，逐步定位到代码层面性能瓶颈，并开展针对性优化；另一方面，为应用集成开源的流量控制防护和熔断降级组件来应对线上流量的不确定性，并对关键业务应用进行扩容处理，进一步增强应用可用性。

图 2 压测过程中应用实例 pod 的 CPU 指标

在实际业务场景中类似问题并不少见，并可以总结为以下两个挑战：

如何定位复杂业务系统中的性能瓶颈？
如何应对流量的不确定性，保护好我们的服务？

示例中的公司对于以上问题给出了自己的解答：模拟线上流量开展性能测试，以 Tracing 数据 + CPU 火焰图作为问题定位依据，通过流控和熔断降级来保护服务。上述方案在开源领域拥有比较成熟的落地实践：

使用 OpenTelemetry 的 SDK/Agent 采集 Tracing 数据[1]
使用 Async Profiler 工具生成 CPU 火焰图[2]
使用 Sentinel 实现流量治理[3]

但实际上，无论是对业务代码进行改造，还是搭建 OpenTelemetry 服务端用于数据接收，都会带来一定的成本投入，研发不再能专注于业务代码开发和维护。那么，是否有无侵入、自动化方式来解决问题呢？阿里云推出的全新 3.x 版本 Java 探针为这些问题带来了全新回答。

Java 探针（也称为 JavaAgent）可以在应用运行态增强应用本身的字节码，业务应用本身不需要做任何代码改动即可实现额外能力的扩展[4]。部署在 kubernetes 中的应用，还可以基于 init-container 实现探针自动注入，进一步降低接入成本。

如何定位业务系统性能瓶颈？

正如前文所说，在定位和优化慢调用问题时，除了观测应用的各个关键指标外，还有“两大法宝”：调用链数据（Tracing）和 CPU 火焰图，可以帮助定位业务调用中耗时较长、CPU 较高的代码片段然后做对应修复。然而，这“两大法宝”却各有自己的“硬伤”：

Tracing 数据常常存在观测盲区

对 Tracing 而言，其数据一般依赖 Agent/SDK 提供的自动或手动的埋点实现数据采集，然后上报到 Tracing 数据收集端（Collector）存储，再由展示端的 Dashboard 关联并展示出来。显然，一条链路的精细程度取决于埋点的颗粒度。但实际上，Tracing 数据的采集也会带来一定的开销，并不会无限制地细分粒度，只会对通用框架中的关键方法进行埋点。那么对于某些业务中的高开销逻辑，往往就可能缺失埋点，从而无法对业务逻辑的耗时进行准确判断，类似下图中的埋点缺失问题在调用链中经常存在。

图 3 常见的 Tracing 数据中容易存在未覆盖埋点导致的观测盲区

CPU 火焰图难以帮助定位线上问题

对 CPU 火焰图而言，可以直观展现业务应用执行过程中 CPU 密集点。火焰图中方法栈宽度代表方法执行时长，通过对“宽底座”、“大平头”的方法开展优化，缩减其调用耗时以达到性能提升效果。然而，许多隐藏的性能问题在测试阶段往往不容易暴露出来，但在线上环境却能显露无余。而火焰图的生成需要花一些时间来采集，当集中于对线上业务进行止血的时候，现场的保存往往有所缺失，毕竟不可能在线上问题发生后先跑个 5 分钟的火焰图。这可能会让整个问题的定位复盘过程变得更加复杂。

图 4 常见 CPU 火焰图中的“大平头”与“宽底座”

那么，有没有一种不需要手动建立密集埋点就能观测到 Tracing 数据盲区，又可以自动识别慢 trace，并将相关方法栈的 CPU 火焰图过滤和关联到对应 Trace 的方法呢？应用实时监控服务（ARMS）在 3.x 版本 Java 探针中通过“代码热点”功能给出了答案。

接下来，以解析并遍历 JSON 数据及调用下游 HTTP 接口场景举例：


public class HotSpotAction extends AbsAction {
 
  private RestTemplate restTemplate = new RestTemplate();
 
  //请求入口方法
  @Override
  public void runBusiness() {
    readFile();
    invokeAPI();
  }
 
  //执行HTTP调用
  private void invokeAPI() {
    String url = "https://httpbin.org/get";
    String response = restTemplate.getForObject(url, String.class);
  }
 
   //读取文件数据并解析
  private double readFile() {
    InputStreamReader reader = new InputStreamReader(
        ClassLoader.getSystemResourceAsStream("data/xxx.json"));
    LinkedList<Movie> movieList = GSON.fromJson(reader, new TypeToken<LinkedList<Movie>>() {
    }.getType());
    double totalCount = 0;
    for (int i = 0; i < movieList.size(); i++) {
      totalCount += movieList.get(i).rating();
    }
    return totalCount;
  }
}

结合下图，对于上述接口，在 Tracing 系统中找到一条慢调用链。可以看到本条调用链共计耗时达到了 2649ms，但后两个 Span 跟第一个 Span 之间存在 2s 多的耗时盲区（这段逻辑对应上述执行 JSON 数据解析），单纯依赖于 Tracing 系统，并没有办法定位到缺失的 2s 耗时具体发生在哪段代码中。

图 5 业务系统的 Tracing 数据，可以看到第二条 span 之前存在一块观测盲区

针对上述问题，接入 ARMS 最新版本探针并开启代码热点后，该问题根因定位就变更非常简单了。仅需单击调用链详情中的代码热点页签，可以在右侧的火焰图中看到相比 Tracing 除了左侧的 HTTP 相关方法栈（对应 Tracing 中的 HTTP 调用），还包含 com.alibaba.cloud.pressure.memory.HotSpotAction.readFile() 导致的 1.91s 执行耗时：

图 6 代码热点页签中的实际展示，可以直观看到耗时较高的方法栈

图中左侧为本次调用中所涉及的所有方法所耗时情况列表，右侧为对应方法所有方法栈信息所绘制的火焰图，其中：

1）"Self" 列显示方法自身消耗的时间或资源。

这个指标表示方法在自身的调用栈中所消耗时间或资源，不包括其子方法调用所消耗时间或资源。
帮助识别哪些方法在自身内部花费了大量时间或资源。

2）"Total" 列显示方法及其所有子方法调用所消耗的总时间或资源。

这个指标包括方法自身消耗时间或资源，以及其所有子方法调用所消耗的时间或资源。
帮助了解整个方法调用栈中哪些方法所贡献了最多的时间或资源。

对于如何使用代码热点功能生成的火焰图定位慢调用根因，可以通过重点关注 Self 这一列或者直接看右侧火焰图中底部的较宽火苗从中定位到高耗时的业务方法，较宽火苗其是引发上层耗时高的根源，一般是系统性能的瓶颈所在。

从上图中不难看到，本文中的慢调用核心原因就是因为 LinkedList 不具备随机访问的能力，在频繁查的场景下开销较高，通过将其重构为 ArrayList 等有索引的 List 实现就可以解决这一问题。其他更多有关代码热点的使用细节可以参考该功能相关用户文档[5]

如何应对流量的不确定性？

其实在压测过程中，如果已配置依靠 CPU 指标/流量指标的弹性，为什么请求成功率还是会持续劣化？经过分析，从指标到达阈值到新的服务实例就绪过程中其实存在一定的时间间隔（可能是因为 Java 应用启动较慢的原因，达到了秒级别的启动时长），在突增流量场景下出现新服务实例还未就绪，老服务实例就已经过载情况。此时业务成功率大幅下跌原因，一部分是因为老服务实例过载；另一个原因是，由于原有实例过载，请求处理能力下降，导致大量流量涌入新启动的服务实例，从而导致新服务实例也因为过大流量而引起过载，陷入不断重启不断扩容的“最坏情况”。当系统面对突增流量，是否有手段可以有效地保护系统始终处于稳态情况？

那就是微服务引擎（MSE）的最新特性，自适应过载保护。

图 7 MSE 自适应过载保护页面

正常情况下，面对突然到来的流量洪峰（弹性来不及扩容），会导致 CPU 飙升（即系统负载上升），全局接口出现明显的性能劣化，比如 RT 持续增加、成功率大幅度下跌。

图 8 开启过载保护后的大流量压测情况

Aliyun JavaAgent 3.x 版本提供了自适应过载保护能力，可以有效地保护我们系统。自适应过载保护会在 CPU 使用率到达阈值时调整限流策略，以一定比例进行限流，保障系统负载处于稳定水平，使得全局接口保持较高 RT 及成功率。

图 9 开启过载保护后的大流量下接口表现

总成功率 50.99%，在 /xx 接口流量突增后，全局所有接口成功率开始下降，RT 也快速飙升，自适应过载保护生效，成功率逐步上升，RT 也快速回落到正常水平。需要注意的是，压测中限流也被当成普通异常处理，因此在成功率上仅 50.99%（实际在去除了限流的异常后请求成功率在 80% 左右，从后半段 RT 表现中也可以看到。）

3.x Java 探针，全新的能力矩阵

前文中提到的“代码热点”与“自适应过载保护”特性，都是以阿里云推出的全新 3.x Java 探针作为底座实现的功能，该组件为您的 Java 应用提供了一整套无侵入的接入方案，深度集成了 OpenTelemetry、Arthas、Sentinel 等多种可观测与微服务治理组件与方案。帮您快速、无感地接入应用实时监控服务（ARMS）、微服务引擎（MSE）、企业级分布式应用服务（EDAS）、Serverless 应用引擎（SAE）等云产品的重要功能。

如何接入 3.x Java 探针

阿里云 Java 探针提供了多种便捷的接入方式，且可以依据您的需求定制可观测和服务治理能力的接入与否。您可以参考 ARMS 应用监控接入概述[9]与 MSE 服务治理应用接入[10]进行接入。

对于运行在阿里云容器服务 ACK[11]中的应用，您可以采用最简单的接入方式：基于 Pilot 模式实现探针的自动注入以及配置，无需修改镜像，只需要在应用 Yaml 中加入几个 label 就可以为 Java 应用接入可观测或服务治理能力。

首先为 ACK 集群安装 ack-onepilot，如图所示：

图 10 安装 ack-onepilot

安装完成之后，在 ACK 集群内创建Java应用，并在 pod 的 spec.template.metadata 字段中添加几个 label，您也可以直接编辑 Deployment 的 yaml 文件，在 spec.template.metadata.labels 下为 pod 添加 label：

如果您需要接入 ARMS 应用实时监控服务，请添加以下两个 label：


armsPilotAutoEnable: "on"
armsPilotCreateAppName: "${接入到ARMS的应用名}"

如果您需要接入 MSE 微服务治理服务，请添加以下三个 label：


msePilotAutoEnable: "on"
msePilotCreateAppName: "${接入到MSE的应用名}"
mseNamespace: "${接入到MSE的命名空间}"

应用成功部署后，您可以在 ACK 控制台上看到对应的 Deployment，点击“ARMS 控制台”即可跳转到 ARMS 控制台查看应用的监控信息。

图 11 从 ACK 控制台跳转到 ARMS 控制台

如果您的应用接入了 MSE 微服务治理，可以在 ACK 控制台上点击更多 > 微服务治理按钮直接跳转至 MSE 服务治理控制台。

图 12 从 ACK 控制台跳转到 MSE 控制台

版本改动一览

除“代码热点”、“自适应过载保护”功能外，本次 Java 探针中还带来了其他全新特性：

支持 Java 21 应用的字节码增强，一个探针可同时支持 Java 8-21 应用的无侵入式可观测数据采集和微服务治理解决方案。
ARMS 数据上报架构全面升级，基于短连接和上报压缩，进一步浓缩上报数据，数据上报成功率从原有的 99% 提升到 99.99%，提供更加稳定可用的数据采集服务。
ARMS 重磅推出慢调用诊断利器——基于调用链的代码热点功能，提供接口慢调用过程的自动观测能力，帮助分析代码执行中的性能瓶颈，详情请参考使用代码热点诊断慢调用链的问题[5]。
ARMS 开展性能优化，应用接入更加轻量化，更加无感；2c4g 双副本规格的容器场景下，挂载探针带来的额外 CPU 开销相较过往版本降低 50%，接近极限 TPS 场景下 CPU 仅增加 10%，使用异步框架的场景 CPU 开销优化幅度达到 65%，性能表现更加良好；启动时间大幅度优化，探针挂载启动耗时降低到 5 秒内，通过容器方式接入，init-container 启动耗时降低到 6 秒内，探针整体启动耗时缩减 10s+。详情请参考ARMS Java探针性能压测报告[6]。
ARMS 支持 Vert.x、Reactor-Netty 等异步框架的完整耗时统计，补充了 OceanBase、xxl-job 等组件的自动化埋点，同时对已有的组件如 PostgreSQL、Kafka 等埋点进行优化，提供了更加精准、更加丰富的指标和 Span 数据，详情请参考 ARMS 支持的 Java 组件和框架[7]。
MSE 流量防护实现对 RPC 调用行为的自定义支持，详情参考配置 MSE 流量防护行为[8]。
MSE 流量防护支持自适应过载保护，基于 CPU 指标以及自适应算法自动保护系统不被过大的流量打垮[12]。

结语

JavaAgent 技术通过其字节码增强的特点，可以无侵入地增强Java微服务的功能，为用户带来了全新的产品能力体验。通过本文的说明，我们可以发现阿里云 3.x 版本探针不仅引入了激动人心的新特性，而且在使用体验上也实现了质的飞跃。

在性能方面：探针挂载启动耗时降低到 5 秒内，探针整体启动耗时缩减 10s+；挂载探针带来的额外 CPU 开销相较过往版本降低 50%；接近极限 TPS 场景下 CPU 仅增加 10%；
在特性方面：带来了诊断、治理领域新特性，自适应负载保护、慢调用诊断、Java 21 的支持等。

当然 3.x 系列 Java 探针并不是终点，为了达成阿里云上的微服务永远在线的目标，我们才刚刚起航。最新的 4.x 版本已经在邀约灰度中，该版本探针完全兼容开源 OpenTracing 协议，新增了自定义线程池的监控，同时提供了更广的自动埋点支持范围与更可靠的异步 tracing 能力，欢迎对新版探针感兴趣的客户联系进行灰度升级，第一时间使用新探针的特性。

相关链接：

[1] OpenTelemetry 官方网站

https://opentelemetry.io/

[2] Async Profiler 工具

https://github.com/async-profiler/async-profiler

[3] 使用 Sentinel 进行流量治理

http://sentinelguard.io/zh-cn/docs/introduction.html

[4] 什么是 Java agent

https://www.developer.com/design/what-is-java-agent/

[5] 使用代码热点诊断慢调用链的问题

https://help.aliyun.com/zh/arms/application-monitoring/user-guide/use-code-hotspots-to-diagnose-code-level-problems

[6] Aliyun JavaAgent 性能压测报告