发帖
雷达卡
金融核心系统信创改造的背景与挑战
自2020年起，国家陆续出台《金融行业信息化发展规划（2022-2025）》《关于银行业保险业数字化转型的指导意见》等政策文件，明确提出金融机构需“实现关键核心技术自主可控”。其中，2027年被设定为金融信创全面落地的关键时间节点。
在央行主导制定的《金融领域信创发展路线图》中，提出了“分层推进”的实施策略：2024年前完成办公管理系统的国产化改造；2025年启动一般业务系统的迁移工作；到2027年，实现核心系统100%国产化替代；2028年进入单轨运行验证阶段。
以银行机构为例，其核心系统涵盖账户管理、支付清算、信贷风控等数百个功能模块。在信创改造过程中，需同步替换包括数据库（如从Oracle迁移至GoldenDB）、中间件（如WebLogic替换为东方通）、操作系统（如RedHat转向麒麟）、服务器硬件（如IBM Power过渡到鲲鹏）在内的全栈技术组件。这一过程不仅涉及复杂的技术适配，还需保障业务连续性，压力巨大。
目前，头部金融机构已开展分布式核心系统的试点建设，而约80%的中小金融机构仍依赖传统的集中式架构，技术债务积累较深。据IDC数据显示，为在2027年前达标，这些机构需保持年均投入增速超过30%。
传统可观测方案面临的局限性
在金融核心系统向分布式、国产化演进的过程中，系统的可观测性成为保障稳定运行的关键能力。然而，传统解决方案在实际应用中暴露出诸多缺陷：
APM方案的主要问题在于侵扰性强。出于安全合规、性能损耗和系统稳定性等方面的顾虑，多数金融机构仅将其部署于测试环境，难以推广至生产系统。此外，主流的Java字节码增强技术仅适用于Java应用，无法覆盖高频交易中的C++服务或AI推理场景中的Python应用，适用范围受限。
日志方案虽然在金融行业中应用广泛，但同样存在代码侵入问题。且由于日志数据非结构化程度高，导致存储与计算资源消耗较大，长期运维成本高昂。
NPM方案虽具备零侵扰特性，但需将云内所有主机及容器Pod的网络流量镜像至专用分析设备，严重占用计算资源和网络带宽。随着东西向流量的增长，该模式极易引发资源瓶颈，难以持续扩展。更重要的是，上述各类传统方案均无法实现跨层级数据的关联分析——APM和日志聚焦于应用层，NPM则局限于网络转发层面。
DeepFlow：基于eBPF的全栈可观测新范式
DeepFlow依托三大核心技术——eBPF零侵扰采集、算子前置处理、语义智能标注，构建了面向金融核心系统的全栈可观测能力。通过“云上云下业务全景图”、“全栈调用链追踪”、“函数级性能剖析”三大核心功能，实现了对异构环境下的端到端监控覆盖。
自2016年起服务于金融客户以来，DeepFlow已在网部署Agent超20万个，单个金融客户的Agent规模突破1万节点。在AI集成方面，它是唯一入选CNCF CNAI全景图的同类产品；在技术创新层面，DeepFlow是业内唯一在国际顶级学术会议ACM SIGCOMM发表核心技术论文的产品，同时也是唯一拥有上千名开发者参与的活跃开源社区项目。
DeepFlow全栈可观测实践案例
DeepFlow的可观测能力主要体现在以下四个方面：
- 云上云下业务全景图：全面观测每个服务的整体性能表现
- 全栈调用链追踪：精准定位每一次调用路径中的延迟来源
- 持续性能剖析：深入到函数级别识别性能瓶颈
- OneAgent统一采集：整合指标、日志、追踪、拨测等多源数据，实现统一关联分析
在多家推进核心系统分布式改造的国有银行与股份制银行中，DeepFlow已成为支撑系统从选型验证 → 开发测试 → 平滑投产 → 持续运行 → 敏捷迭代全生命周期的伴生观测平台。
某银行客户典型应用场景
以下结合某大型商业银行的实际案例，展示各团队如何利用DeepFlow平台提升研发效率与系统稳定性。
开发测试团队的应用实践
在开发与测试阶段，团队对可观测能力的需求集中在两个关键环节：
1. 功能测试
在分布式架构下，调用链追踪、日志检索与性能剖析是快速定位问题的基础能力。传统方式依赖代码插桩，增加开发负担且易引入风险。DeepFlow提供的零侵扰观测能力，使团队无需修改代码即可获取完整的调用上下文，显著提升了调试效率，并有助于早期发现潜在性能隐患。
2. 非功能测试
在复杂的国产化基础设施环境中，压测结果往往受多因素影响。当性能未达预期时，瓶颈排查极具挑战。同时，测试阶段积累的数据对于后续线上容量规划、弹性伸缩策略制定具有重要参考价值。
案例一｜应用性能退化：定位高CPU消耗的瓶颈函数
在一次非功能测试中，开发测试团队发现新搭建的核心集群ncbs-ksebm中，服务ncbs-gr-poinrpc频繁出现请求超时现象。借助DeepFlow的持续性能剖析能力，团队迅速识别出新版本服务中存在异常高的CPU占用。
进一步分析显示，sun/reflect/GeneratedMethodAccessor 函数与 org/apache/logging/log4j/spi/AbstractLogger::logIfEnabled 函数合计引入了约18%的CPU开销。凭借清晰的函数调用栈信息，开发人员得以快速锁定问题根源并优化代码逻辑，有效解决了性能退化问题。
对于应用监控与业务监控团队而言，当前面临的核心挑战之一是可观测性数据覆盖不完整。这一问题主要体现在三个方面：黄金指标缺失、调用链路覆盖不全，以及缺乏在线实时剖析能力。
01｜监控指标缺乏：为多团队提供零侵扰黄金指标
传统的黄金指标如吞吐量、响应时延和错误率，往往依赖于应用层主动暴露。即便监控团队制定了明确的指标上报规范，在实际落地过程中仍常出现执行不到位的情况，导致关键性能数据无法全面采集。
在调用链方面，基于代码插桩或应用改造实现的 APM 和日志方案难以实现端到端的完整链路追踪。尤其对于使用 SofaRPC 等框架的场景，IO 线程层面的性能盲区长期存在。此外，商业 APM 所采用的字节码增强技术，每隔数月就可能因运行环境变化而需要重新适配，维护成本高。
当生产环境出现性能劣化时，测试环境往往无法复现问题现场。若通过重启进程来注入 Java Agent 进行诊断，又可能导致故障上下文丢失，错失根因分析的最佳时机。
On-CPU 持续剖析能力：低开销、全时域性能观测
目前，On-CPU 持续剖析功能已在全部云主机上常态化开启，仅消耗约 1% 的 CPU 资源，可在开发、测试到生产各阶段持续运行，快速识别应用程序性能退化的根本原因。该能力无需在主机侧额外安装 perf、jstack 等调试工具，所有数据采集均由 one-agent 独立完成。同时支持按需对指定进程开启或关闭剖析功能，全程无需重启或修改应用进程，保障业务稳定。
02｜长尾时延突增：零侵扰追踪 Java IO 线程性能瓶颈
某银行核心交易系统的组件在压测过程中，每 5 分钟会出现数十次 2s 至 10s 的延迟尖刺。其调用链路为 gateway → aggquery → paramcenter，基于 SofaRPC 实现通信。以一次典型延迟事件为例，传统 APM 显示三段服务观测到的延迟分别为 2.05s、2.05s 和 2ms，初步判断瓶颈位于 aggquery 服务，但长时间排查未果，严重影响压测进度。
切换至 DeepFlow 全栈观测平台后，通过简单的界面操作，利用其零侵扰调用链追踪能力，迅速定位到性能瓶颈实际发生在 paramcenter 服务的网卡与系统调用之间——具体表现为负责 Socket 读写的 IO 线程出现卡顿。
运维人员据此快速识别出该服务 IO 线程数量配置过低的问题，调整配置后故障立即消除。DeepFlow 不仅避免了传统 APM 因代码插桩带来的侵入性和性能负担，还能在高压场景下持续稳定运行，有效解决了 SofaRPC 中常见的 IO 线程追踪盲区问题。
03｜偶发调用失败：零侵扰定位数据库主键重复插入错误
非功能性测试不仅能暴露性能瓶颈，也能揭示高负载下的异常处理缺陷。在一次新核心系统的压力测试中，微服务 ncbs-subnoa 在高并发下偶发调用失败，但应用日志中未记录任何错误信息。
借助 DeepFlow 全栈观测平台对“压测机 → 网关 → 应用 → 数据库”整条链路的全覆盖能力，系统快速捕获到 ncbs-subnoa 访问数据库时的异常行为，并可进一步下钻查看具体的 SQL 错误码（1062）、错误描述（Duplicate entry）及对应的 SQL 语句（INSERT INTO xxxx_flow_instance_node）。这些精准的异常信息被反馈给开发团队后，问题得以迅速修复。
04｜代码性能隐患：发现低效 SQL 与 Redis 大 Key
在开发阶段，代码中常隐藏着一些低效的基础设施调用模式，例如存在性能缺陷的 SQL 或 Redis 操作。典型的低效 SQL 包括：使用 SELECT * 查询全部字段、未带 WHERE 或 LIMIT 导致全表扫描、WHERE 或 ORDER BY 字段缺少索引，以及因字段函数使用、隐式类型转换或通配符模糊匹配引发的索引失效等。
常见的 Redis 使用问题则包括 SET、HSET 操作中设置过大的 Key，即所谓的“Redis 大 Key”现象。这类大 Key 占用大量内存空间，容易引起 Redis 性能下降、内存飙升、数据分布不均以及主从同步延迟等问题。
DeepFlow 全栈观测平台具备零侵扰采集能力，能够完整捕获应用所有的 MySQL 与 Redis 调用日志，帮助在开发测试阶段提前识别低效 SQL 和大 Key 请求，从而规避上线后引发的数据库性能劣化风险。同时，MySQL 调用日志的采集也有助于识别 SELECT * 等不良编码习惯，推动开发规范落地。
以往，此类性能隐患的发现高度依赖 APM 插桩机制和开发人员的自觉性，对于第三方供应商提供的黑盒软件更是难以管控。如今，依托 DeepFlow 的无侵入式采集能力，完整的调用日志数据使得性能问题的前置防控成为现实。
在信创技术选型过程中，DeepFlow 提供了客观、中立的全栈可观测性数据支持。例如，在新核心压测环境中对海光与鲲鹏平台进行对比测试时，依托 DeepFlow 的全面监控能力，两套架构均成功达到预期压测目标：稳定支撑 2 万 TPS 的交易请求，且平均响应时延控制在 90ms 以内。
DeepFlow 能够为压测活动提供全面、中立的性能观测数据，协助测试团队在未达预期结果时快速定位瓶颈所在，并为系统正式上线提供可靠的容量规划和资源配置依据。以下为某次压测中的典型应用案例：
海光平台交易波动下的瓶颈快速定位：
通过 DeepFlow 捕获的 RED 指标（请求量、错误率、响应时延）以及底层资源使用情况，团队能够在交易性能出现波动时迅速下钻至具体服务或组件，识别出性能瓶颈的具体位置，避免因信息缺失导致决策延迟。
目前，DeepFlow 已实现对所有运行在其覆盖范围内云主机上的服务自动采集 RED 黄金指标，无需业务方额外开发或埋点。这些指标可通过 PromQL API、SQL API 及 Grafana DataSource API 等多种方式对外输出，已被广泛应用于多个关键团队：
- 帮助应用监控团队构建完整的微服务监控与告警体系；
- 助力全栈云团队增强 Kubernetes 集群的监控大盘能力；
- 支持新核心团队搭建分布式核心系统的 Grafana 监控视图。
尤其对于应用监控团队而言，过去依赖“规范要求”推动业务方自行上报黄金指标，常因业务上线压力而被忽视，导致告警覆盖率长期偏低。如今，所有部署在 DeepFlow 所覆盖环境中的服务均已具备自动化的黄金指标采集与告警能力，真正实现了 100% 告警覆盖的目标。
02｜交易性能骤降：零侵扰定位代码级瓶颈函数
凌晨 00:01，对公贷款批处理应用的运维人员收到大量高时延告警，查看相关性能指标如下图所示：
告警服务的请求速率、异常比例与响应时延曲线
结合持续性能剖析所获取的 CPU 使用趋势，发现异常集中在 00:01:00 至 00:03:13 这两分钟内。由于故障持续时间极短，准确识别根因成为防止复发的关键。得益于 DeepFlow 的零侵扰、低开销持续剖析能力，系统完整记录了故障期间应用进程的 On-CPU 剖析数据。运维人员随即对比正常时段与异常时段的火焰图差异：
分析结果显示，在异常时间段内，deflate_slow、longest_match 和 slide_hash 等函数的 CPU 占比显著上升。将该信息提交给开发团队后，迅速确认问题根源为多线程压缩操作引发的 CPU 占用过高。后续优化方案将压缩任务调整为单 Pod 内单线程执行，优化后 CPU 使用率明显回落，问题得以彻底解决。
03｜CPU 使用突增：零侵扰识别耗时函数
对公贷款批处理微服务在生产环境中出现 CPU 使用率在一分钟内从不足 10% 急剧攀升至 80% 以上的情况。此类突发问题难以通过传统侵入式工具及时捕捉瓶颈函数。而 DeepFlow 的零侵扰剖析能力可直接输出故障时刻 CPU 开销最高的函数列表，例如：
- com/goldendb/jdbc/internal/util/StringUtils::indexOfNextChar
- java/lang/String$CaseInsensitiveComparator::compare
- java/lang/String:toLowerCase
- Java/util/RegularEnumSet::contains
- java/lang/String::toUpperCase
这些函数及其完整的调用栈（在火焰图中呈现）被迅速交付给开发人员，使得性能问题可在无需复现环境的情况下快速定位，大幅缩短排查周期。
此外，生产环境中一些瞬时的 CPU 毛刺同样会影响服务响应时延。如下图所示，参数中心应用每隔 5 分钟会出现一次 CPU 飙升现象。借助 DeepFlow 的持续剖析能力深入分析，发现 POIN-CONSULCONF 与 configWatchTask 线程的 CPU 占比较高，进一步定位到是由 Spring Boot 中每 5 分钟触发一次的 ConfigListener 执行参数更新和同步操作所致，直接影响了正常业务处理流程。
响应时延曲线
系统、数据库与中间件团队面临的挑战
在核心系统改造过程中，硬件、操作系统、中间件及数据库均面临替换与适配的新挑战，主要体现在以下几个方面：
缺乏性能基线：
在软硬件选型阶段缺少充分的历史性能数据作为参考，难以科学评估不同技术栈的实际表现，也无法为上线后的容量管理提供可靠依据。
分布式数据库运维复杂度提升：
一次交易涉及大量 SQL 读写与事务操作，传统的集中式数据库运维经验在分布式架构下不再适用。同时，缺乏高效手段区分数据库代理节点与数据节点之间的性能瓶颈，导致问题定界困难。
操作系统内核层面关联难：
当故障涉及操作系统层级时，现有工具无法有效将应用层调用日志与内核级性能指标进行关联分析，影响根因定位效率。
压测过程中，业务响应时延出现多次波动，且并非短暂毛刺现象。通过全栈观测平台进行排查，初步锁定问题源于应用网关的POD。进一步分析发现，JVM参数中IO线程配置偏低，导致网络IO等待率升高，请求队列发生拥堵。在调高相关线程数后，问题得以解决。
在一次压力测试中，三台发压机表现出压力输出不均的现象，导致整体压测压力无法提升，并频繁出现客户端重置的情况。由于难以判断是发压端还是被测应用的问题，团队借助全栈观测平台的流量拓扑图，快速识别出压力分布不均源自发压机自身负载失衡，从而明确了问题边界。
海光与鲲鹏环境在压测期间均出现了无规律的应用层时延突增毛刺。此类问题难以复现且定位困难。利用全栈观测平台的调用日志数据，运维人员实现了分钟级从数百个Pod中精准定位异常实例。最终通过调大JVM参数中的MaxMetaspaceSize和MetaspaceSize，成功消除毛刺问题。
02｜链路瓶颈难识别：实现分布式数据库的零侵扰性能追踪
作为分布式核心系统的关键组件，分布式数据库的性能瓶颈定位极具挑战性，尤其在涉及代理集群与数据集群的复杂架构下，实现从应用到数据库的全栈链路追踪尤为关键。DeepFlow基于eBPF技术实现了大部分链路的零侵扰追踪。然而，由于应用通常使用独立线程池访问数据库，造成追踪断点。为此，联合新核心团队对数据库客户端SDK进行改造，在每个SQL事务的首条语句中以注释形式注入TraceID，成功打通了应用至数据库的完整调用链。
某银行信用卡中心在非功能测试环境中对微服务进行压测时，发现访问部署于裸金属的EverDB时延高达200ms，远超2ms的设计目标。EverDB是该行结合金融业务特性，与合作伙伴共同研发的具备自主知识产权的分布式数据库方案，采用双轨并行策略推进数据库转型。
借助DeepFlow的调用链追踪能力，运维团队迅速将性能瓶颈定位至EverDB的调度节点。通过查看该节点的持续剖析数据，发现Off-CPU时间显著异常，其中epoll_wait函数等待CPU的时间偏长，表明调度程序存在网络IO处理缓慢或阻塞问题。将此信息反馈给数据库管理员后，调整数据库IO线程相关参数，问题迅速得到解决，保障了信用卡新核心系统的测试进度。
由于架构复杂，分布式数据库的性能问题普遍难以定位。DeepFlow通过零侵扰追踪与持续剖析等能力，在日常运维中还解决了多类典型故障，例如：因DN节点IO线程配置不足引发的高时延，以及执行线程池过小导致的服务响应延迟等。
03｜压测未达预期：突破微服务网关的性能瓶颈
在非功能测试阶段，基础设施的复杂性常成为性能瓶颈定位的主要障碍。如下图案例所示，信用卡新核心系统测试团队在信创云上对金融授权联机交易服务进行压测时，发现性能未达预期，随着并发量上升，时延呈现明显劣化趋势。尽管使用了现有的APM工具和日志系统，但连续两周未能定位根本原因。
测试团队指出：理论上，网关不应成为性能短板，但由于缺乏对容器云、网络层及PointRPC框架的可观测能力，仅靠信用卡运维团队难以深入排查。在将DeepFlow接入该压测环境后，打开业务全景拓扑的瞬间即暴露出异常：新一代核心网关服务Gateway与服务注册中心Consul之间存在异常高频通信。该线索提交至新核心团队后，迅速确认问题根源——网关未实现本地缓存，每笔交易均需实时向Consul查询服务注册信息，导致高并发下资源耗尽，带宽打满，时延急剧上升。
网络团队面临的挑战：云网络逐步沦为黑盒
随着网络虚拟化、SDN及容器CNI技术的广泛应用，分布式业务环境下的网络故障排查难度大幅上升。传统依赖交换机分光镜像的方式已无法覆盖全部流量路径，而在云主机上进行流量镜像又会导致CPU与带宽消耗成倍增长，使得云网络逐渐演变为“黑盒”状态。
01｜云网性能盲区：零侵扰定位KVM网络瓶颈
在分布式核心系统全面上云前的大量性能测试中，曾出现K8s集群内微服务调用裸金属部署的GoldenDB服务时，客户端观测到的时延为3ms，而DBA团队在数据库侧记录的时延仅为1.5ms。这表明近一半的耗时发生在基础设施层面，但具体引入环节长期不明。
通过 DeepFlow 可以观察到，访问过程中的主要延迟集中在 KVM 宿主机的 vxnet 网络环节。该问题被反馈至私有云供应商后，迅速展开排查，发现当前环境使用了 ARM 架构的 CPU 和支持 SRIOV 的网卡，并启用了 VXLAN Offloading 功能。在复杂配置叠加的情况下，导致数据包转发延迟显著上升。经过对业务逻辑进行升级，并实施网卡缓冲区扩容、关闭中断聚合、优化中断队列绑定与 CPU 核心关联等调整后，重传和零窗口现象得到明显改善。最终重传率降至 0.1% 以下，KVM 转发延迟降低达 80%，有效支撑了分布式核心交易系统的顺利上线。
在信用卡新核心项目的授权重构联机交易压力测试中，当通过托管 ELB 对 Gateway 进行压测时，出现了随机性的超时与连接重置现象，异常交易占比介于 0.1% 至 0.4% 之间。而绕过托管 ELB 直接对 Gateway 施加压力时，该问题消失。已知授权类交易的超时阈值设定为 200ms。
如上图所示，借助 DeepFlow 的流量拓扑功能可识别出 ELB 与 Gateway 之间的链路存在异常。深入查看流日志后发现，连接结束类型为“客户端重置”，此类问题通常由客户端（即 ELB）错误复用 SNAT 源端口所致。将此分析结果提交给私有云服务商后，对方快速调整了 ELB 的相关配置，问题随即消除。
商业银行在推进核心系统单元化改造过程中强调：“在单元化架构下，绝大多数服务间调用及数据库读写操作均可在本地单元内闭环完成，仅少数场景需跨数据中心通信。这种设计有效降低了跨区域网络延迟，提升了系统响应速度与整体性能。”然而，在业务持续迭代的过程中，如何防止产生非预期的跨区域、跨可用区或跨单元流量，成为一大挑战。传统依赖交换机分光镜像的方式不仅硬件投入大，且因流量可能经历多次 NAT 转换，导致 IP 地址难以映射回具体服务实例，定位困难。
DeepFlow 能够全面覆盖云环境中的所有云主机和容器 Pod，采集原始网络流量，并自动关联云资产信息与容器服务元数据，帮助网络团队实现对跨区域流量的持续监控。
全栈观测平台 Agent 的资源限制、自监控与熔断机制
为了确保观测平台自身能够紧跟新核心业务的敏捷迭代节奏，其稳定性与可控性至关重要，尤其是在大规模部署下必须保障 Agent 的资源占用处于合理范围。
如下图所示，DeepFlow 全栈可观测平台的 Agent 具备完善的资源限制策略、运行状态自监控能力以及熔断保护机制。这些特性不仅保障了 Agent 自身的高效运行，更能在极端情况下主动进入熔断模式，避免对核心业务造成干扰。
Agent 的自我持续性能剖析能力
DeepFlow 平台所具备的业务全景拓扑、全栈链路追踪以及持续性能剖析能力，同样适用于其自身的运行监控。例如，下图展示的 On-CPU 剖析火焰图揭示了一次 Agent 升级后 CPU 使用率异常升高的问题。经分析发现，set_epc_by_cidr 函数消耗了高达 16% 的 CPU 资源。结合详细的函数热点和调用栈信息，开发团队迅速定位原因：由于行内双栈云环境中 VPC 与子网数量突破一万，触发了该函数的性能瓶颈。基于此洞察，团队快速完成了代码优化。
总结与未来展望
随着金融核心系统数字化转型迈入深水区，DeepFlow 在提升系统稳定性、保障业务连续性以及加速敏捷交付方面发挥了关键作用。依托 eBPF 与 WebAssembly 等零侵扰数据采集技术，全栈可观测性不仅为传统架构提供了高效的监控手段，还成功打破了多团队协作中的数据孤岛，显著提升了故障定位、性能调优和资源管理的效率。
展望未来，随着大模型智能体技术的发展，DeepFlow 的应用场景将进一步拓展。大模型所具备的智能分析能力有望彻底突破传统运维中因知识储备和人力精力不足带来的瓶颈，进一步提升跨部门、跨团队的协同效率，并在性能优化、容量预测以及智能化故障检测等方面提供更强有力的支持。同时，智能体还将助力运维团队实现更精细化、实时化的风险防控，特别是在复杂环境下实现动态优化与趋势预判。
未来，我们将持续探索技术进步与业务创新的融合路径，推动金融领域的全栈可观测平台从单一技术工具演进为数字化转型的核心驱动力。通过不断强化平台功能与性能，并深度融合人工智能等前沿技术，我们有信心为银行内部提供更加精准、高效的技术保障，为数字化时代的金融服务构筑坚实的技术底座。
11月29日下午，DeepFlow 联合蓝鲸智云共同发起一场线下Meetup活动，携手 Greptime、OpenCSG 等技术团队，深入探讨 AIOps 如何实现从“问题感知”到“行动决策”的完整闭环实践。
本次交流将聚焦智能运维的前沿落地场景，展现从发现问题、分析根因到自动化响应的全流程实战经验。
通过多方技术视角的碰撞与融合，共同探索运维智能化的下一阶段演进路径，推开智能运维新阶段的大门。
京公网安备 11010802022788号
