金融核心系统信创改造的背景与挑战
2020 年以来，《金融行业信息化发展规划(2022-2025)》，《关于银行业保险业数字化转型的指导意见》等文件明确要求金融机构“实现关键核心技术自主可控”，2027 年成为金融信创全面落地的硬性时间节点。央行牵头制定的《金融领域信创发展路线图》提出“分层推进”策略 —— 2024 年前完成办公管理系统改造，2025 年启动一般业务系统迁移，2027 年实现核心系统 100% 国产化替代，2028 年进入单轨运行验证期。
以银行为例，核心系统通常涉及账户管理、支付清算、信贷风控等数百个模块，需同步替换底层数据库（如 Oracle → GoldenDB 等）、中间件（如 WebLogic → 东方通等）、操作系统（如 RedHat → 麒麟等）、服务器（如 IBM Power → 鲲鹏等）等全栈组件，技术验证与业务连续性保障压力巨大。头部机构已试点分布式核心系统，而 80% 的中小金融机构仍依赖集中式架构，技术债积累深，2027 年达标需年均投入增速超 30%（IDC数据）。
传统方案实现可观测性的缺陷
在金融行业核心系统场景下，传统方案实现可观测性面临着各方面的挑战，下表对不同解决方案进行的比较：
APM 方案
主要缺陷在于高侵扰性。由于潜在的安全合规、性能、稳定性隐患，金融机构一般仅在测试环境中部署 APM，无法在生产环境推广。并且，APM 方案中较成熟的 Java 字节码增强方案仅针对 Java 应用，难以覆盖例如高频交易中的 C++ 应用、智能推理服务中的 Python 应用。
日志方案
虽然在金融机构中成熟度更高，但同样也对应用代码有侵入性。并且，由于日志数据结构化程度低，存储和计算的消耗相比其他方案更高。
NPM 方案
虽然是零侵扰的，但需要将云内所有主机、容器 Pod 的流量引流到专有分析设备上，极大消耗云主机的计算资源和网络带宽，随着东西向流量的增大会走向失控的结局。并且，这几种传统方案均无法实现全栈数据的关联：APM 方案和日志方案仅关注应用服务本身，NPM 方案仅关注网络转发。
DeepFlow 方案
DeepFlow 基于 eBPF 零侵扰采集、算子前置、语义智能标注三大原创核心技术，通过云上云下业务全景图、全栈调用链追踪、函数级性能剖析三大产品能力，构建了核心系统的全栈可观测性。自 2016 年开始服务金融客户，目前在网 Agent 数量已超过 20 万，单个金融客户的 Agent 规模已超过 1 万。在 AI 能力方面，DeepFlow 也是同业唯一一个进入 CNCF CNAI 全景图的产品。在技术领先性方面，对比其他采用 eBPF 技术的竞品，DeepFlow 是唯一一个在国际顶级学术会议 ACM SIGCOMM 上发表核心技术论文的产品，也是唯一一个拥有上千人参与的活跃开源社区的产品。
DeepFlow 全栈可观测性实践案例
DeepFlow 的全栈可观测性产品能力主要体现在四个方面：
在推进核心系统分布式改造的国有、股份制银行客户中，DeepFlow 的全栈可观测性已经成为了护航核心系统从选型验证 → 开发测试 → 平滑投产 → 持续运行 → 敏捷迭代整个生命周期的伴生系统。
下面以某行客户为例子，分享各个团队使用 DeepFlow 全栈观测平台的实践案例。
开发测试团队
开发测试团队对可观测性能力的依赖主要体现在两个阶段
01 ｜应用性能退化：零侵扰剖析应用代码中的瓶颈函数
下图中，开发测试团队发现新核心集群 ncbs-ksebm 中的 ncbs-gr-poinrpc 服务请求经常 Timeout。利用 DeepFlow 持续剖析能力，测试团队快速发现了新上线的服务中由
sun/reflect/GeneratedMethodAccessor函数和org/apache/logging/log4j/spi/ AbstractLogger::logIfEnabled函数引入了 18% 的 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 全栈观测平台以后，如下图所示，经过几步简单的点击，使用零侵扰的调用链追踪能力，能够快速锁定性能瓶颈发生在 Java 服务 paramcenter 的网卡和系统调用之间，即负责 Socket 读写的 IO 线程卡顿导致了该问题。
运维人员查看到这一现象以后，快速定位到了该服务 IO 线程数量配置过小的根因，配置更新以后问题随即修复。DeepFlow 全栈链路追踪不止是避免了传统 APM 代码插桩的侵入性和性能问题，能够随时、持续在高压环境开启，同时也解决了传统 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 对应的 Value 值所占的内存空间比较大，可能导致 Redis 性能下降、内存飙高、数据不均衡以及主从同步延迟等问题）。
DeepFlow 全栈观测平台能够零侵扰采集应用的所有 MySQL、Redis 调用日志，能够在开发测试阶段发现低效的 SQL 语句和 Redis 大 Key 请求，能够帮助开发者提前发现性能隐患，避免应用上线后触发 MySQL、Redis 服务的性能劣化。除此之外，DeepFlow 采集的 MySQL 调用日志也能帮助开发者提前发现 SELECT * 等有性能隐患的开发习惯。
Redis 调用日志的采集字节数指标
以往，发现这样的性能隐患需要依靠 APM 插桩，依赖开发人员的主观能动性，对外部供应商提供的软件产品更是难以要求。现在，依靠 DeepFlow 的零侵扰采集能力，完善的调用日志数据让性能隐患提前规避成为可能性。
扫描二维码获取案例
应用监控团队
对于应用监控和业务监控团队来讲，面临的第一大挑战是可观测性数据不全
-
黄金指标不全：经典的吞吐、时延、异常指标依赖应用软件的主动暴露。即使监控团队有明确的指标暴露要求，实际执行过程中也大打折扣。
-
调用链不全：依赖应用改造的 APM、日志解决方案总是无法覆盖完整的链路，而商业 APM 产品提供的字节码增强机制每隔半年可能都会遇到需要重新适配的问题。
-
在线剖析能力缺乏：当线上环境出现应用性能劣化时，在测试环境中可能无法复现。即使在生产环境中通过重启进程注入用于 Debug 的 Java Agent，重启动作也可能导致故障现场的丢失。
01｜监控指标缺乏：为多团队提供零侵扰黄金指标
DeepFlow 能够零侵扰采集所有服务的 RED（请求、错误率、时延）黄金指标，并支持以 PromQL API、SQL API、Grafana DataSource API 等形式对外开放。目前，指标数据已经帮助应用监控团队构建了完整的微服务监控告警体系，帮助全栈云团队强化 K8s 监控大盘，帮助新核心团队构建分布式核心系统的 Grafana 监控大盘。
特别是应用监控团队，以往只能依靠“规范要求”业务方具备完善的黄金指标，这些管理手段经常会由于业务方强势要求上线而打破，结果就是应用的告警覆盖率非常低下。目前，某行所有运行在 DeepFlow 覆盖的云主机上的服务，都已经具备了黄金指标的告警能力，让 100% 告警覆盖成为可能。
02｜交易性能陡降：零侵扰剖析应用代码中的瓶颈函数
凌晨 00:01，对公贷款批处理应用的运维人员突然接到大量高时延告警，查看应用性能指标如下图所示：
告警服务的请求速率、异常比例、响应时延曲线
结合下图中持续性能剖析的 CPU 走势，运维人员发现异常主要集中在 00:01:00 ~ 00:03:13 之间。由于响应时延劣化的故障只持续了 2 分钟，找到问题的根因是避免下次故障的关键所在。得益于 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 增长以外，生产环境中一些瞬时突发的 CPU 毛刺也会导致应用调用时延受到影响，例如下图中每隔 5 分钟参数中心应用会出现一次 CPU 飙高，利用持续剖析能力下钻即可发现 POIN-CONSULCONF、configWatchTask 线程 CPU 占比较高，开发人员能够据此快速确定由于每 5 分钟执行一次的 Spring Boot ConfigListener 函数的参数更新、同步操作导致了业务处理受到影响。
扫描二维码获取案例
系统、数据库、中间件团队
核心改造过程中，硬件、操作系统、中间件、数据库均面临着替代的挑战
-
缺乏性能基线：缺少充足的数据支撑不同软硬件的选型和上线运行以后的容量评估。
-
分布式数据库：一次交易中包含大量的 SQL 读写和事务操作，以往集中式数据库的运维经验在分布式场景下遇到了巨大的挑战，缺乏高效的手段定界数据库代理节点和数据节点的性能问题。
-
操作系统内核：当故障涉及操作系统时，没有高效的方式将应用调用日志与操作系统性能指标关联。
01｜信创技术选型：提供客观中立的全栈观测数据支撑
在新核心压测环境海光 v.s. 鲲鹏对比测试中，在 DeepFlow 的保障支撑下，两套环境均成功到达压测目标：2 万 TPS 交易请求平均时延控制在 90ms 内。
DeepFlow 能为压测活动提供中立的、全面的可观测性数据，帮助测试人员快速定界压测结果不符合预期时的瓶颈位置，并为正式投产提供丰富的容量规划和资源配比数据支撑。在某一次压测活动中，典型的数据支撑案例列举如下：
-
海光应用系统交易波动快速定位瓶颈点：压测期间业务响应时延多次波动，非毛刺形态，通过全栈观测平台定位是由于应用网关 POD 原因，最终定位 JVM 参数中的 IO 线程设置过低，导致网络 IO 等待率较高，队列产生拥堵，调高后问题解决。
-
三台压力机发压不均匀：压测期间，发现压测压力上不去，且存在客户端重置现象，无法界定是发压机问题、还是应用问题，通过全栈观测平台流量拓扑图快速定位是由于三台发压机发压不均匀。
-
海光和鲲鹏应用时延高毛刺问题：压测期间，海光环境、鲲鹏环境均出现无规律应用侧时延突增毛刺问题，无法定位。通过全栈观测平台调用日志观测数据，分钟级在几百个 Pod 中定位出异常 Pod，最终定位调大 MaxMetaspaceSize 以及 MetaspaceSize 解决。
02｜瓶颈链路不明：零侵扰追踪分布式数据库性能瓶颈
分布式核心系统的关键组件是分布式数据库，如何实现应用和分布式数据库（通常包括代理集群和数据集群）的全栈链路追踪是极具挑战的。DeepFlow 利用 eBPF 技术实现了大部分链路的零侵扰追踪，但应用在读写数据库时往往使用独立的线程池。针对此问题，协调新核心团队对数据库客户端 SDK 进行改造，在每一个 SQL 事务的第一条 SQL 语句中以注释的方式注入 TraceID，从而实现了从应用到分布式数据库的全栈调用链追踪。
全栈观测平台的分布式数据库调用链追踪能力
某行内信用卡中心在非功能测试环境中对微服务进行压测时，发现访问裸金属中的 EverDB 时延高达 200ms，不符合 2ms 以内的要求。EverDB 是某行为满足业务发展需求，根据金融业务特点和分布式数据库产品特性采取了双轨并行的策略，在引入了分布式数据库产品的同时，和合作伙伴一起，共同打造的自主知识产权的分布式数据库方案。
通过 DeepFlow 的调用链追踪能力，运维人员可以快速锁定性能瓶颈出现在 EverDB 调度节点中。查看调度节点的持续剖析数据，发现 Off-CPU 有明显异常，epoll_wait 函数等待 CPU 的时间明显高，说明调度程序中的网络 IO 操作速度较慢或阻塞。将此信息告知数据库管理员以后，通过修改数据库 IO 线程相关参数，该问题快速解决，保障了信用卡新核心非功能测试的进度。
分布式数据库由于其架构复杂性，性能问题定位难度较高。DeepFlow 利用零侵扰分布式追踪、持续剖析等能力日常定位的典型故障还包括：由于新核心分布式数据库 DN 节点 IO 线程数配置不合理导致的高时延问题，由于数据库 DN 节点执行线程不足导致的高时延问题，等等。
03｜性能压测失败：零侵扰追踪微服务网关的性能瓶颈
非功能测试阶段性能瓶颈定位的另一大挑战来自基础设施服务的复杂性。在下图所示的案例中，信用卡新核心系统测试团队在信创云上进行金融授权联机交易服务压测时发现性能数据不达标，随着并发量的升高时延呈现明显的不符合预期的增长趋势。测试团队使用已有的 APM 和日志工具定位两周无进展。
测试团队表示：正常情况下 Gateway 性能不应是这种表现，但单独靠信用卡运维团队无法对容器云、网络、PoinRPC 框架等基础设施造成的影响进行分析。DeepFlow 扩容至该压测环境后，打开业务全景拓扑的一刻直接发现了问题所在：新一代核心网关服务 Gateway 和服务注册中心 Consul 之间存在巨大的流量。此信息提供给信用卡新核心团队以后，定位结果得到了快速确认：由于新核心网关缺乏缓存功能，导致每笔交易均需要从 Consul 获取注册信息，从而导致并发增大时系统和带宽资源耗尽，时延迅速劣化。
扫描二维码获取案例
网络团队
网络虚拟化、SDN、容器 CNI 为分布式业务场景下的故障排查带来了巨大的挑战
传统交换机分光镜像的方式无法获取到全部流量，而在云主机上引流的方式又将会导致 CPU 和带宽消耗翻倍增加，云网络逐渐成为黑盒。
01｜云网性能黑盒：零侵扰追踪 KVM 网络性能瓶颈
分布式核心系统上线全栈云之前进行了大量的性能测试，期间发现 K8s 集群中的微服务访问裸金属服务器上的 GoldenDB 服务时，客户端侧的时延（3ms）与 DBA 团队看到的时延（1.5ms）有较大的差距，这意味着整个过程中基础设施的耗时占了将近 50%，但并不清楚具体是哪个环节引入的。
通过 DeepFlow 可以看到，整个访问过程中的主要时延消耗在 KVM 宿主机的 vxnet 网络上。这些数据反馈到私有云供应商以后进行了快速的排查，发现该环境下宿主机使用了 ARM CPU 和 SRIOV 网卡，并开启了 VXLAN Offloading，复杂的环境下一些不合理的配置导致流量转发时延过高。在升级业务逻辑并针对服务器进行了网卡缓冲区扩展、关闭网卡中断聚合、调整网卡中断队列与绑核后，重传及零窗现象有了大幅优化，重传率降低至0.1%以下，KVM 转发时延下降了 80%，有效的保障了整个分布式核心交易系统的顺利上线。
02｜托管服务盲区：定位托管负载均衡器端口复用问题
信用卡新核心项目组进行授权重构联机交易压力测试时，通过托管 ELB 压测 Gateway 时出现超时重置现象，问题现象出现随机，异常交易比例为 0.1%~0.4%。当绕过托管 ELB 直接压测 Gateway 时超时现象消失。授权重构联机交易的超时判定阈值是 200ms。
在上图中，DeepFlow 流量拓扑中发现 ELB 与 Gateway 之间链路存在异常，继续点开异常链路，发现流日志的结束类型为客户端重置，这类异常一般是由于客户端（ELB）错误的复用了 SNAT 源端口号导致。将此问题反馈至私有云服务商以后，ELB 的配置得到了迅速调整，问题随即解决。
03｜流量治理繁杂：跨区域、跨可用区、跨单元流量监控
在商业银行核心系统单元化改造的研究与思考中提到：“在单元化架构中，大部分的服务间调用和数据库读写操作都可在本地单元内完成，只有少数场景需要跨数据中心调用。这种设计减少了跨数据中心的网络延迟，提高了系统的响应速度和整体性能”。然而，如何保障业务迭代过程中不产生预期之外的跨区域、跨可用区、跨单元流量是非常有挑战的，传统的交换机分光镜像方法需要投入大量硬件资源，且流量中监控到的 IP 地址可能已经经历过了多次 NAT 转换从而无法定位到具体的服务。
DeepFlow 覆盖云内所有云主机和容器 Pod，能够采集到最原始的流量，并且自动和云资产信息、容器服务信息关联，可以帮助网络团队持续监控跨区域流量。
扫描二维码获取案例
全栈观测团队
为了紧跟新核心业务的敏捷迭代，观测平台自身也需要保持更新
目前，DeepFlow 已经覆盖了数万台云主机，已经成为了某行双栈云基础设施中的重要组成部分。那么，如何在迭代过程中保障观测平台的稳定可靠也非常重要，特别是还需保障 Agent 的资源消耗可控。
01｜Agent 的资源限制、自监控和熔断能力
下图中展示了 DeepFlow 全栈可观测平台中 Agent 自身丰富的资源限制、自监控和熔断能力，这些能力保障了 Agent 的高效运转，以及在发生最恶劣情况下 Agent 能够进入熔断状态以避免影响新核心业务。
全栈观测平台 Agent 的资源限制、自监控和熔断能力
02｜Agent 的自我持续剖析能力
DeepFlow 全栈观测平台的业务全景拓扑、全栈链路追踪、持续性能剖析对自身也同样适用。例如下图的 On-CPU 剖析火焰图就展示了 Agent 某次升级以后发现 CPU 用量有明显升高，排查之后发现 set_epc_by_cidr 函数消耗了 16% 的 CPU。开发人员根据此信息快速定位到了问题的原因，由于行内双栈云环境中 VPC 和子网数量破万导致了此性能问题。利用丰富的函数热点和调用栈信息，开发人员快速完成了优化。
全栈观测平台 Agent 的自我持续剖析能力
扫描二维码获取案例
总结和未来展望
随着金融核心系统的数字化转型进入新的阶段，DeepFlow 在提升系统稳定性、保障业务连续性、以及加速敏捷迭代方面发挥了至关重要的作用。通过基于 eBPF 和 WebAssembly 等技术的零侵扰采集能力，全栈可观测性不仅为传统系统引入了高效的监控手段，而且成功解决了多团队协作中的数据孤岛问题，提升了故障定位、性能优化与资源管理的工作效率。
展望未来，随着大模型智能体技术的发展，DeepFlow 的应用场景将进一步扩展。大模型的智能分析能力将彻底打破传统运维中因知识和精力瓶颈带来的限制，进一步提高跨部门、跨团队的协作效率，并在性能调优、容量预估和智能化故障检测方面提供更高效的支持。此外，智能体将帮助运维团队实现更加精细化和实时的风险防控，尤其是在复杂系统环境下的即时优化和预测能力。
在未来的发展过程中，我们将继续深入探索与业务创新和技术进步相结合的可能性，推动金融全栈可观测性平台从单纯的技术工具向数字化转型的关键驱动因素转变。通过不断完善监控平台的功能和性能，配合人工智能等先进技术的集成应用，我们有信心在行内提供更加精准、高效的技术保障，为数字化时代的银行业务提供坚实的后盾。
11月29日下午，DeepFlow × 蓝鲸智云联合举办线下Meetup，携手Greptime、OpenCSG等团队，揭开AIOps从“感知问题”到“行动决策”的实战闭环！扫码锁定席位，一起推开智能运维的下一扇门！
