DeepFlow 证券行业云原生可观测性实践

目前，在整体数字化转型过程中，证券行业的业务系统全面云原生化已是必然趋势，我们和很多证券行业的客户沟通交流，发现每个证券行业客户的云基础架构都是由三个或者三个以上的资源池组成，比较常见的有 EasyStack、VMware、K8s 以及超融合资源池 SmartX、Nutanix 等等。
在这样的混合云、异构环境下，DeepFlow 基于自主研发的高性能流量采集器软件，能够实现云上分布式应用、微服务的全流量采集。
比如在 EasyStack、华为云、超融合资源池中，采集器以用户态进程的方式运行在资源池计算节点上，负责采集该计算节点内所有业务虚拟机的流量；再比如在 VMware 资源池中，通过在 ESXi 宿主机上各运行一台专属流量采集器虚拟机，接收 ESXi 宿主机内所有虚拟机的流量；另外在 K8s 资源池中，采集器是以 DaemonSet POD 的方式运行在 K8s Node 节点上，负责采集该 Node 节点内所有业务 POD 的流量。
通过上述的流量采集器部署方式，可以构建面向证券行业混合云业务系统可观测性能力图谱的基座——数据采集层，并经过流量采集器强大的本地计算与预处理能力，向 DeepFlow Server 端输出丰富的 Metrics、Logging、Tracing 指标，包括覆盖网络、系统、应用排障的海量 Metrics 性能指标；网络流量日志、应用流量日志；以及网络流量拓扑、全栈链路追踪、应用调用追踪等 Tracing 数据。
这样能够大大降低监控数据的传输带宽消耗，实测仅为业务传输带宽的万分之一，也就是流量采集器采集到 10Gbps 的业务流量，经过本地预处理后，发送的监控数据带宽消耗仅为 1Mbps，实现对业务网络传输的零侵扰。
基于采集端上送的海量可观测性数据，DeepFlow 提供丰富的应用展示能力，包括业务网络全链路诊断、分布式应用性能分析、全网全流量回溯取证等，并从业务层面针对部署在异构资源池上的分布式业务进行全局的性能保障，这里的业务主要包含核心交易类，如集中交易、集中清算系统等等；还有互联网类、综合支撑类等等，通过 DeepFlow 提供一站式的可观测分析诊断能力，支撑证券行业混合云上业务的长期稳定运行。
另外，DeepFlow 也提供数据开放与协作共享能力，使得 IT 服务管理系统、运维大数据平台能够通过 SQL API 的方式，简单、快速地获取混合云上分布式应用的全栈性能指标；同时也可以和云管平台进行一系列的联动，可以按照租户的维度将租户内的资源和业务的监控视图赋能到租户所在的云管平台上进行使用等等。
此外，流量采集器除了能够采集流量、本地计算可观测数据之外，还具备业务流量数据包分发的能力，通过精细化的策略控制，来补齐云上其他工具对于虚拟网络流量消费的需求，避免流量采集探针的重复建设。
DeepFlow 可观测性协作的价值与使命
价值1、肉眼可见的故障处理效率提升
实现微服务全栈链路的动态追踪，分钟级定位分布式应用故障范围。

这张拓扑图，它是根据时间线、针对一个分布式业务系统的流量访问关系进行动态绘制的，从图中可以清晰、直观地看出各个微服务的上下游调用关系，包括客户端、WEB、APP、中间件消息队列、LB、DB 等等，并且在该业务系统异常时，能够准确地在这张拓扑图中标识具体的异常访问路径，也就是图中红色的线条，同时可以继续下钻，查看该异常访问路径在途径的所有虚拟网元节点侧统计的 Metrics 性能指标。比如图中 DB 集群是由两组容器 POD 组成，同时 DB-2 访问 DB-1 的路径跨越了两层虚拟化。
全栈路径对应右上角图中标识的七处位置，分别为客户端 POD、客户端 Node 节点、客户端宿主机、网关、服务端宿主机、服务端 Node 节点以及服务端 POD，DeepFlow 能够自动计算每一跳位置的 Metrics 性能指标，再通过横向、纵向的关联对比，自动标识异常访问路径的具体故障点，比如能够准确地回答应用访问慢是慢在了客户端容器节点内，网络丢包是发生在服务端宿主机到服务端容器节点之间，等等。
通过这样的全栈链路追踪能力，能够实现故障的快速定界定位，显著降低故障修复时间。
价值2、零侵扰的全链路调用追踪
使用 BPF、eBPF 技术实现零侵扰、无盲点的分布式应用调用追踪，进而实现从应用到基础设施的全链路追踪与保障。以大家所熟知的 Bookinfo Demo 来举例，这个场景包括多语言，如 JAVA、Python、Ruby、NodeJS 等等，以及也包含了 Istio 服务网格，是一个比较典型的分布式业务系统。
右上角的火焰追踪图，是通过 eBPF+BPF 技术关联实现的一个完整的、自动化的分布式应用全链路追踪图，这个和传统的应用调用追踪图比较相似，但是没有做任何的插码，不需要修改业务代码，也无需向 HTTP 头注入 TraceID 或者 SpanID。
同时在这张全链路追踪图中，包含了4个调用、38个 SPAN，以及上述提到的多语言的分布式追踪能力。
一般情况在客户端进程发起一个 GET 的调用，通过插码的方式，仅能够看到客户端调用服务端的时延，中间传输网络是透明的，是看不到的。DeepFlow 通过一系列自研的专利技术，创新性地实现 Flow 生成、Session 关联，能够直观地将客户端调用服务端中间的每一跳时延都刻画出来，比如客户端应用进程到 POD、到 Node、再到服务端 Node、POD、服务端进程等等。
因此，通过这张全覆盖的火焰图能够使各部门在同一个平面上协作起来，实现故障问题的快速定界定位。
另外，在看一下 Service Mesh 的场景，可以清晰地看到业务流量被 Istio envoy sidecar 截持后，中间经过的每一个环节的时延消耗情况，包括 Ingress Envoy 的收、发，以及 Egress Envoy 的收、发。同时，应用服务接收到这个请求后，会发起一次 DNS Lookup，这往往也是应用插码容易忽略掉的一些细节的地方，也是 eBPF 零侵扰的分布式应用全链路追踪的价值所在，看的更全面，排障才能更得心应手。

]]>