共计 7203 个字符，预计需要花费 19 分钟才能阅读完成。
前言
随着春节大促行将到来，为了确保线上业务高效稳固地运行，电商企业大多会对旗下要害业务利用进行多轮测试。通过模仿线上较高流量的申请，来察看服务性能的理论体现。以某企业的业务测试报告举例：
$$
图 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-g…
[6] Aliyun JavaAgent 性能压测报告
https://help.aliyun.com/zh/arms/application-monitoring/develo…
[7] ARMS 利用监控反对的 Java 组件和框架
https://help.aliyun.com/zh/arms/application-monitoring/develo…
[8] 配置 MSE 流量防护行为
https://help.aliyun.com/zh/mse/user-guide/configure-web-behav…
[9] ARMS 利用监控接入概述
https://help.aliyun.com/zh/arms/application-monitoring/gettin…
[10] MSE 服务治理利用接入
https://help.aliyun.com/zh/mse/user-guide/application-access-…
[11] 容器服务 Kubernetes 版 ACK
https://www.aliyun.com/product/kubernetes
[12] 配置零碎防护
https://help.aliyun.com/zh/mse/user-guide/configure-system-pr…
作者：张铭辉、泮圣伟
原文链接
本文为阿里云原创内容，未经容许不得转载。
