云杉网络 COO 来源

金融信创是金融机构重点投入以及技术迭代的方向，经过多年阶段迭代，进入难度更大的核心系统、关键业务系统的更替阶段。DeepFlow 解决行业中普遍存在的分布式交易系统保障难、平台双轨多芯调优难、云上资源把控难、分布式数据库追踪难等挑战。

什么是DeepFlow

DeepFlow 是一款高度自动化的一站式可观测性平台，旨在为复杂的云基础设施及云原生应用提供深度可观测性。基于 eBPF 实现了应用性能指标、分布式追踪、持续性能剖析等观测信号的零侵扰（Zero Code）采集，并结合智能标签（SmartEncoding）技术实现了所有观测信号的全栈（Full Stack）关联和高效存取。

在金融行业关键业务系统测试投产、迁移上云、保障业务连续性、调优升级等不同阶段场景中持续提供观测服务保障能力。

金融银行业中面临的可观测性挑战

1、关键业务系统升级上云后保障业务连续性

云平台建设和试运行后，对于应用迁移上云，金融客户都是有严格的分阶段及并发运行计划。办公、一般业务系统都逐步在云上运行，金融客户也对云及云原生应用深刻掌握。核心系统、关键业务系统在云上运行的计划也都进入了实际落地的快车道。微服务化的核心系统一般都提供公共内核服务、业务单元服务等，每个微服务都能独立部署、运行及扩展，为银行提供了灵活的业务扩展、系统整合及生态开放能力。

保障业务连续性始终是金融行业技术运营部门开展工作的核心，对信息系统有效监控及告警是重要保障手段。绝大多数金融机构科技运营部门都是以技术栈进行部门划分，比如网络、系统、应用等，在边界清晰的条件下，可以专注并深入地发挥技术能力。但资源池化、分布式以及微服务化后，技术边界交叠融合，在保障业务连续性过程中，从单一技术栈视角难以全面洞察业务运行状态。监控需要多维度、多层面的数据关联，从故障定界到根因定位，从热点预警到容量预测，每个部门都面临无从下手的挑战，经常出现“是又不是”的判断。部门已有的工具面临新环境失效、数据收集单一，判断依据不足等问题。面对已经上线的业务，亟需系统化的、贴合的手段来保障。新型业务应用对监控效率、部门协作提出了全新要求。

2、保障信创替换后的系统性能

以金融信创的重要软件部分数据库为例，关系到金融业务系统的整体功能与性能。分布式数据库将传统数据库各部分组件进行分布式部署，通过网络通信进行协同工作，在处理及运维上避免了集中式系统的短板，在提升了整体交易能力的吞吐同时，由于组件之间网络通信的传输成本，也会存在每笔交易请求的处理时间（ART，Application Response Time）增加的风险；由于数据库运行的资源节点增加，也会增加处理交易、事务及SQL语言执行的运维管理复杂度。

3、提升操作系统、芯片架构选型评估效率

金融银行业进入信创关键业务替换期，在早期办公、一般业务系统替代的实践中积累了经验和指标，核心系统、关键业务的信创替换后，对稳定性、性能要求更加严格。由于技术路线选型将持续影响后续IT系统规划、建设及投入，所以在信创评估选型过程中需要格外的谨慎及细致，除了同业内交流对比外，各行也都投入了大量的人力、物力进行评估。

从CPU、操作系统、数据库、中间件、应用系统在不同组合下的运行效果、性能参数、压力表现等都需要一手数据以明确调优方法；进行局部替换后，对整体业务应用的影响评估也同样需要一手数据进行判断。“哪个平台表现好？”，“资源消耗的热点函数是哪个？”需要统一的观测数据收集能力提升评估准确性及效率。

4、提升核心系统测试调优效率

分布式系统开发进入非功能测试阶段、上线试运行阶段时，就进入了重协作的工作周期。核心系统、关键业务系统上线工作是一个体系工作，涉及到软件研发中心、数据运营中心、供应商等多个部门组织，且有严格的规划及流程，测试调优效率直接影响上线流程。缺乏对环境、系统、平台以及交易应用等整体运行数据收集、统一视角、关联能力，仅单一视角的工程师在发挥专业技能之前，如优化数据库查询、调整网络配置、修改应用函数代码等工作，通常首要面临的是难以独立界定故障、性能瓶颈的边界和所属。团队间会商举证、工单流转、现象重现、数据临时获取等都是效率损耗的节点。在非功能测试环节中，让测试系统具备可观测性，快速确定性能瓶颈是值得期待的事情。

技术

eBPF技术是可观测性的关键技术，是在多技术栈融合，分布式核心系统运行在云原生环境的时间点上，打开了可观测性实现的技术窗口。

什么是eBPF

eBPF是一项革命性技术，不在需要修改编译内核源代码或者加载内核模块，就可以高效地在内核中运行用户编写的沙箱程序（Sandbox Programs），并且保证内核安全运行。比传统的内核编程更加方便快捷，能基于现有的系统抽象层来打造功能更加丰富的基础设施软件，而不会增加系统的复杂度，也不会牺牲执行效率和安全性。

从实现来看，eBPF 是一个基于寄存器的虚拟机，使用自定义的 64 位指令集，能够在 Linux 内核内运行即时编译的eBPF程序，并能访问相应内核函数和内存。在选定内核函数被执行时，相应的eBPF程序也被执行，程序的目的丰富多样，包括网络、安全、度量性能、应用追踪等等。

eBPF解决了在内核编程中的经常遇到的挑战，使内核释放出巨大的可能性。在此之前，内核编程主要有直接修改内核代码和编写内核模块两种方式。直接修改内核代码需要重新编译内核，通过编写API调用实现应用功能，用户环境兼容、维护性是一大挑战，难以在客户生产环境中采用。通过加载的内核模块同样面临内核版本的更新，内核API的变化，所以内核模块需要随着每一个内核版本的发布而更新。eBPF通过严格的运行验证及限制解决了工程师内核编程中最大的问题，安全稳定问题，释怀了时刻要小心的Kernel Panic恶梦。

eBPF的演进

eBPF是由BPF技术演进扩展而来（The BSD Packet Filter: A New Architecture for User-level Packet Capture，1992 https://www.tcpdump.org/papers/bpf-usenix93.pdf），BPF最初是为Tcpdump等工具获取和过滤匹配特定规则的网络数据包方法，更多的目的是为了处理内核中网络相关问题。 Alexei Starovoitov 在2014年引入了扩展BPF（extenal BPF）设计，可以直接将BPF虚拟机开放至用户空间。在内核内运行用户空间程序的能力被证明是非常强大的，eBPF不仅继承了BPF初衷，适合编写网络程序，可以编写附加到网络套接字以过滤流量、分类流量和运行网络分类器操作的程序，甚至可以使用 eBPF 程序修改已建立的网络套接字的设置。而且由于eBPF 程序可以访问内核数据结构，开发人员可以编写和测试新的调试代码，而无需重新编译内核，具备在几乎所有类型的事件、内核函数上执行特定动作的能力，比如在安全、调试内核和性能分析等方面。

eBPF的优势

前面提到安全稳定问题，这是eBPF的技术优势，eBPF程序是一个 64 位的指令序列，运行将严格考虑到两个方面：所有的 eBPF 指令在加载时必须是可验证的，以确保内核的安全；eBPF代码需要尽可能快地被执行。

强安全：BPF验证器（BPF Verifier）会保证每个程序能够安全运行，它会去检查将要运行到内核空间的程序的每一行是否安全可靠，如果检查不通过，它将拒绝这个程序被加载到内核中去，从而保证内核本身不会崩溃，这是不同于开发内核模块的。

高性能：一旦通过了BPF验证器，那么它就会进入JIT编译阶段，利用Just-In-Time编译器，编译生成的是通用的字节码，它是完全可移植的，可以在x86和ARM等任意CPU架构上加载，这样能获得本地编译后的程序运行速度，而且是安全可靠的。

除此之外，为什么说eBPF打开了可观测性实现的技术窗口，就是在系统平台层面能够获取全栈的运行数据，包括应用调用、网络拓扑、平台事件等，云、容器及系统部门天然具备全栈数据获取的角色和使命，这也印证了可观测性应该是云服务的一个能力。

DeepFlow组件

数据平台通常架构包括采集端和处理端，DeepFlow可观测性平台也是如此，由Agent、Server两部份组成，面向云原生环境，可直接使用云环境进行部署扩展。完全兼容各类型云平台、容器平台以及多语言开发的应用系统。

DeepFlow Agent组件运行在数据收集端，在不侵入应用、业务资源（容器PoD、虚拟机等）的条件下，按功能开启选项收集各类型数据，包括网络流量、应用系统调用追踪、CPU性能剖析、平台事件、日志等类型数据，对数据进行分布式预处理后传输至DeepFlow Server存储分析端。

在动辄上万节点（容器Node）规模的金融环境中收集数据不同于实验室环境操作，可用性、安全性、稳定性及高性能都是方案选择的首要条件。Agent分布式设计，避免数据集中处理架构存在的性能瓶颈，零侵入设计避免对生产程序改造和干扰运行，进程方式运行避免对生产业务造成运行风险。

在以上条件下，各种部署形态的DeepFlow Agent为客户提供三个核心功能抽象能力：

1.数据收集抽象层

实现信创、非信创环境下的容器Pod、Serverless、虚拟机、裸金属设备等多种类型资源池内的网络流量、调用追踪、性能剖析等多维度数据的统一获取并处理。广受好评的就是DeepFlow在大规模环境下的稳定性以及零侵入方式对多语言编写的应用调用追踪数据的收集。

稳定性自不比多说，要看客户实践及生产应用，DeepFlow荣幸地支持了国内最大的金融行业云的可观测性建设，DeepFlow也是金融银行业客户可观测性建设中最多的产品选择。

应用全链路调用追踪始终是运维侧的难题，主要就是代价大以及追不全，主要表现在追踪需要应用改造支持，部门间协调数据，第三方应用，如中间件、数据库没有办法插码追踪。随着云原生发展，数据中心的系统部门（云管理部门、容器部门）成为了天选的观测数据收集部门，上至应用管理，下至网络配置，都融入和平台之中，eBPF技术打开了贯穿上下的技术窗口。DeepFlow实现了这点。

2.数据接入抽象层

并不是所有数据都通过DeepFlow Agent来收集，客户通常已经投产了很多工具，积累了相应的数据。通过标准技术接口接入更多数据源数据，是更高效地进行数据消费，以及降低总体存储成本、维护成本的选择。在云原生范畴中，最常见的接入的数据就是Prometheus，犹如Kubernetes的双生子，Prometheus必然出现在客户的运维工具中，来监控容器资源状态。不幸的是，大部分生产环境中都使用得不是太好，一个主要原因就是不同于测试使用，生产规模不断变大后，后端的数据处理没人搞。Prometheus数据写入DeepFlow Server后，第一，Prometheus数据关联到更多维度的观测数据；第二，数据存储由DeepFlow Server负责。

3.私有解析抽象层

在核心系统以及关键业务应用中，会面临私有协议、交易标识、流水号提取等场景，通过可编程的WASM组件，热加载在DeepFlow Agent中运行，可以在收集端按需获取相应标识，并上报存储分析后端DeepFlow Server。这对更详尽地获取应用调用追踪数据并串联起来提供了完备的方式，并且对私有协议解析提供了扩展方式，大大提升私有协议追踪的效率。

DeepFlow Server组件基于ClickHouse并优化后实现观测数据存储，并通过Autotagging技术实现自动为多维观测数据注入统一属性标签，SmartEncoding技术通过标签与观测数据分离，平衡存储开销与查询体验。DeepFlow Server可选择部署在独立物理服务器或者云上资源池中。选择已有的云上计算服务是大部分客户的选择，可以选择云上服务器、容器、SQL数据库、对象存储等云上服务快速完成部署实施。

方案

金融银行客户的观测性建设不是一蹴而就的简单工具上线，是根据客户自身发展阶段、需求重点、业务类型、投入预算等因素进行进行的系统工作，包括软件产品以及服务。

需求与部署

观测数据收集并不是一味地越多越好，越细越好，这是与诉求、成本相关的。DeepFlow可根据不同场景需求、发展阶段提供可配置的部署选择，包括观测功能、目标区域。DeepFlow 企业版本提供包括应用、网络、数据库、CPU性能、日志等可选功能。

以大多数保障业务连续性，定界排障的场景为例，DeepFlow Agent覆盖完整的交易调用请求路径（如下图），包括网关功能区、计算区以及数据库区。根据实际运行环境，也可以选择仅部署计算区域，重点关注虚拟机、容器间的请求调用，再逐步扩大部署范围。

从业务应用的视角出发，呈现收集的并关联完善的观测数据后，就具备了初步的观测能力。对于经常困扰客户的分布式应用定界排障问题，变得简单直观。对于一个复杂的分布式应用，当每一步调用请求都可以让“数据来说话“，运维的确定性就大大增加了。

再深入一个信创分布式数据库的观测场景，目前金融银行业客户都在改造核心系统，分布式数据库替换Oracle也是目标之一，通常数据库节点规模都在600-800台服务器。数据库的DBA专家们在测试、优化、生产过程中，首选需要是快速明确判断应用查询写入、网络传输的边界，（当然分钟级定界是所有部门所期望的，以高效发挥专长），再者就是能根据交易进行事务、SQL执行在CN（Coordinator Node）、DN（Data Node）节点中的追踪。

运行与服务

排障仅是DeepFlow可观测性能力在工具价值方面的体现，可观测性是伴随云原生、信创改造中长期、体系进行发展的，围绕着不断沉淀的观测数据，不断开拓、深化观测应用场景，对客户的服务体系尤为重要。服务源自产品领先性、客户覆盖及广泛的生产实践经验总结，为客户在云原生发展中推动起“观测数据、观测场景、观测价值“飞轮不断旋转。

DeepFlow服务行业客户，主要包括观测工具服务，观测数据服务、数据底座服务、观测智能体服务四大类。

I. 观测工具服务目标是帮助客户使用DeepFlow产品，解决监控业务系统中“黑盒“”盲点””断链”的直接需求，通常是面对客户单一部门进行服务，着重解决客户在保障业务连续性过程中，对于分布式、微服务、云原生环境中监控手段缺失或失效的问题，直接对应客户部门的履职和责任。服务效果就是“分钟级定界故障“以及洞察系统运行状态。

II. 观测数据服务目标是通过数据提升客户部门间的协作效率。所服务的金融银行业客户，主要是一部两中心的架构，研发中心、数据中心都会根据技术栈进行划分部门，单一技术栈虽然具备专业深度但在总体状态上存在局限性。观测数据服务就是有效对接各技术栈现有的工作流程、运维工具，这并不是一个简单的技术工具问题，而是服务能力。首先要解决的就是多部门的”数据信任”，通常需要“事实说话“，在第一类别服务过程中，确实体会到想要的”盲点”数据通过DeepFlow可以快速获取，并准确地、高效地解决过手头问题。其次就是对接数据，”缺啥补啥”，将观测数据融入到各部门的已有工具和工作流程中。在云杉的服务过程实践中，在业务系统上线、技术选型场景中，都实现了跨中心的多部门数据服务。服务效果就是帮助各部门在工作中轻松得到想要的缺失数据。

III. 数据底座服务目标是通过DeepFlow数据接入能力关联更多数据源，降低客户数据总体存储成本，结合观测工具服务、观测数据服务提升数据使用效率。服务效果是有效沉淀客户生产IT系统的私有运行数据并结构化、语义化，以具备智能应用的数据基础。

IV. 观测智能体服务目标是在具备数据与智能大模型的条件下，迅速在客户选择的智能平台上运行面向运维体系的智能应用。保证智能应用不至于“表面绣花“，真正起到跃层提升效率的效果，场景化以及融入工作流程尤其重要。服务效果是在明确的场景或环节中替换目前对观测数据的人工分析工作。

价值

1、云建设及试运行阶段

不仅仅听云服务商的说法

在验证平台运行是否符合需求及预期过程中，DeepFlow最大的价值是独立、客观地支撑客户进行验证及优化平台，供客观全栈运行数据，独立于云服务商进行性能评估及数据说明，尤其在网络路径、拓扑呈现、链路追踪、资源汇总提供比对依据。

2、核心系统开发及调试阶段

提升非功能测试效率

优化交易响应时间是非功能测试中重要的目标，通常银行交易业务每笔交易需要在60-80ms中处理完成，每笔交易响应过程，需要经过多个微服务调用，涉及业务单元、公共服务、网络传输、负载均衡等。轻松串起每笔交易的调用追踪，并能有效关联至网络、资源、日志等维度数据，是每个开发调试人员向往的理想环境，以快速定位性能瓶颈的调用、资源等，快速发挥工程师的优化手艺。

信创数据库、信创处理器、信创系统等环境中，对于测试交易过程中，建立统一性能看板，详细记录从函数粒度占用CPU、到调用请求处理延时的性能数据，本质改观分布式系统适配、评估平台，路线选型的效率瓶颈。

3、关键业务应用上线阶段

明察上线不同环境后的性能差异

通常关键业务上线是行里的重要事件，涉及开发中心、数据中心以及各服务商多部门协作。在上线阶段，人员都是各领域的专家，虽然开发环境、测试环境、试运行环境都是尽可能地统一规格进行建设，但经过使用运行，仍然存在不可避免的差别，导致上线系统在功能、性能上达不到预期。虽然多部门的专家都待命，但通常解决问题并不是很顺畅且多有反复。当试运行环境具备观测能力，对于运行状态、测试交易进行实时记录，每个团队都有统一的数据视角，各技术栈专家，开发工程师可以快速获取上下文，锁定问题范围，专业的工程师都能在自身技术栈的范围内充分发挥作用，大大提升判断瓶颈、复现问题、修复补丁、验证测试等不同环节中的协作效率。

4、业务应用生产运行阶段

分钟级定界故障

系统正式上线生产环境后，进入生产运维保障侧后就是保障业务连续性。经过了大量严谨的测试和上线流程约束后，不会出现重大功能性故障。但既然是系统，由于外界内部的因素，总不能保证100%稳定服务。大部分客户都是使用工单，进行运维侧处理各类运维故障的手段流程。避免工单无止尽地在部门间流转，分钟级定界问题，呈现可信的多维度观测数据，降低MTTR（Mean Time To Repair，平均修复时间）。

5、运维智能化阶段

不再是人工的智能

运维经验以及多技术栈的广度和深度，束缚着运维效率的提升。DeepFlow Agent、Server组件低代价完成收集及沉淀观测数据，并进行标记、关联及语义化编码。观测数据结合大模型后，即可使用DeepFlow智能体，将以上不同场景的数据分析工作，转移至群聊中的助理机器人、工单派送中的分发机器人、排障过程中的根因机器人，总结过程中的报表机器人来进行，提升运维质量及效率。

DeepFlow产品及服务伴随金融行业客户的云原生系统及信创发展，持续领先，持续服务。