金融银行业可观测性方案及服务

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

01  |   什么是 DeepFlow

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

可以通过 Github（https://github.com/deepflowio/deepflow）了解 DeepFlow 的技术架构以及可观测性功能特性。

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

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

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

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

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

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

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

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

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

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

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

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

03  |   技术

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

▌ 什么是 eBPF

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

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

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

▌ eBPF 的演进

eBPF 是由 BP F技术演进扩展而来（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 打开了可观测性实现的技术窗口，就是在系统平台层面能够获取全栈的运行数据，包括应用调用、网络拓扑、平台事件等，云、容器及系统部门天然具备全栈数据获取的角色和使命，这也印证了可观测性应该是云服务的一个能力。

04  |   DeepFlow 组件

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

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

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

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

▌ 数据收集抽象层

相比于部署在物理网络用于流量分析的重型装备，云杉流量采集器像是《三体》中描述的质子，极简的部署，极微的体量，却能捕捉到每个最小交互单元的流量数据包。

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

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

▌ 数据接入抽象层

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

▌ 私有解析抽象层

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

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

05  |   方案

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

▌ 需求与部署

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

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

云内流量分析对象是成千上万的业务 pod、虚拟机，以及他们之间交互形成的又一个指数量级的网络路径，想要把这种体量的流量数据包发送出来再进行集中处理计算显然不是明智的选择。这就给流量采集器提出了一个更加严苛的要求：以极小的资源消耗，保证强大的本地计算能力。DeepFlow 流量采集器在腾讯全栈专有云中进行了完美适配，经过现场多轮测试结果可知：在规定资源占用的前提下（1C1G），单个流量采集器计算处理能力大于 10Gbps，这无疑是客户工程师心中的又一粒定心丸。

从覆盖范围上看，这种流量采集器部署实现了对整个 A 金融行业云两地多区域的的全面覆盖。这种规模是在传统网络流量监控角度上难以想象的。采集流量范围更加广，管理流量的规模更加庞大，粒度更加精细化，才能够适应云数据中心当下的监控需求，是新架构、新场景下对于网络流量监控的必然要求。

▌ 运行与服务

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

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

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

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

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

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

06  |   价值

▌ 云建设及试运行阶段

“不仅仅听云服务商的说法”

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

▌ 核心系统开发及调试阶段

“提升非功能测试效率”

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

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

▌ 关键业务应用上线阶段

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

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

▌ 业务应用生产运行阶段

“分钟级定界故障”

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

▌ 运维智能化阶段

“不再是人工的智能”

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

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