一、项目背景及目标

近年来，我社根据陕西信合《信息科技十四五规划》，启动了“陕西信合数字化转型工作”，形成了陕西信合数字化转型“321”总体框架，确定了“网点智能化转型”（以下简称：网转）工作的开展思路与信息化建设方式。其中，陕西信合分布式技术平台（以下简称：分布式技术平台）作为全行级技术底座，提供了全行微服务的统一运行框架，形成了分布式技术组件和应用公共基础组件的跨平台、通用的服务共享能力，大大提升了我社新架构新模式下的运行效率和容量能力，强化了多活容灾切换、弹性扩容、故障隔离转移、灰度发布等优良特性，已经成为我社数字化转型重要的“支撑设施”。陕西信合分布式技术平台在业界内首创了敏稳双态的企业级服务框架体系，实现了传统zk注册中心与微服务注册中心之间数据的相互传输，进而实现服务的统一管控；同时在微服务框架内通过引入zk、nacos双技术栈的注册中心，解决单一技术栈故障时的全局风险，实现了超完备的注册中心冗余架构。

作为一个我社采用“自研+开源”模式建设的基础应用支撑平台，其技术架构及功能架构方面在行业内有一定的先进性和前瞻性，市场上尚无标准的面向分布式技术平台的应用监控软件或系统可进行直接适配，故需要自主建设一个可靠的、适配的应用性能监控系统来对分布式技术平台上承载的各类微服务进行性能状态监控，保障相关应用及业务的稳定运行。

二、项目方案

根据网转项目整体工作安排，随着试点系统的逐步上线和试点机构的上线切换，为及时掌握分布式技术平台上运行的各类微服务调用响应状态，我们按照“统一规划，分步实施”的指导原则，对陕西信合分布技术平台监控系统（以下简称：本系统）的功能架构进行了总体设计。并结合我社自主可控能力建设工作的相关要求，对系统核心技术组件进行了选型，主要以行业广泛使用的各类开源中间件或框架组件为主，为后期信创适配提供便利，系统核心组件架构如下。

图 1 系统架构

在分布技术平台架构下，我社应用业务主要是根据业务流程设计，通过定义组合不同微服务中功能接口间的相互调用（下文将功能接口间调用简称交易）关系，从而实现业务逻辑。

图 2 实现原理

本系统主要功能模块包含统计管理中心、报表中心、运行大屏、查询中心、业务场景定义、后台管理、消息队列管理、数据处理中心、数据储存中心等。具体如下：

图 3 功能架构

（1）消息队列管理

 在消息队列技术选型上，本系统使用Kafka集群作为消息队列，实现了分布式技术平台和本系统在数据处理上的解耦。同时，在本系统处理大量交易数据（即微服务调用流水信息，下同）时，Kafka集群可以起到削峰填谷的作用，避免短期的大数据量对本系统造成的性能影响。

（2）数据处理中心

为提高监控数据处理效率，发挥实时监控数据的价值，本系统基于流处理引擎Flink构建了数据处理中心模块。该模块通过项目组自研定制的Flink作业任务实现对交易数据的实时处理，对交易数据进行清洗过滤和统计分析，随后将处理好的数据写入数据存储中心。

（3）数据储存中心

为更好的适应各类监控场景对原始监控采集数据颗粒度不同的需求，本系统在构建数据存储中心时，设计了明细数据存储模块和聚合数据存储模块两大数据存储模块。分别用来存储交易明细数据及交易聚合数据。

（4）统计管理中心

为适应复杂多变的监控数据统计需求，我们在本系统中构建了统计管理中心。管理员用户可在此模块中动态配置统计维度和统计指标，从而配合报表中心实现灵活、动态配置的统计报表功能，便捷的对业务、微服务、功能接口的应用性能监控指标进行多维数据分析。

（5）报表中心

根据统计管理中心已配置的维度、指标，结合管理员用户在报表中心设置的报表类型和周期，系统将在低峰时段自动生成不同系统、多维度、多层级的离线报表，为系统管理员分析系统运行情况提供有力的数据支撑。

（6）运行大屏

运行大屏模块可通过自定义配置监控大屏布局，指定需要观测的能力中心、微服务、功能接口等监控对象以及监控指标项。根据在上述模块中的配置信息，通过曲线绘制的方式，将应用性能关键指标（交易量、交易响应时间、交易成功率）实时展示于系统页面或监控大屏之上。

图 4 运行大屏

（7）查询中心

本系统的查询中心模块支持对实时或历史交易监控数据进行明细查询和简要分析。交易明细查询结果条目中可将原始采集的交易明细（即微服务调用流水信息）的原始报文详细信息以格式化方式列出，并支持对当次交易明细查询结果以列表或饼图的方式进行简要统计。用户还可以在交易明细查询结果中指定交易条目，调用分布式技术平台的【查看交易调用链】功能，进行该笔交易的调用链路深度探查

（8）业务场景定义

业务管理模块主要用于维护业务场景定义，配置业务场景码和微服务、功能接口的对应关系。系统将自动根据管理员用户维护的业务场景配置，将相关微服务、功能接口的性能数据进行整合，通过业务拓扑图和业务调用链路图的方式，将业务场景维度的应用性能情况呈现给用户，实现业务场景层的监控。

三、创新点

陕西信合分布式技术平台监控系统作为我社首个采用“自主+开源”方式模式建设的应用性能监控系统，其具备较好的实时数据处理、智能分析与智能可视化能力，较好的兼容了陕西信合分布式技术平台,实现了对分布式技术平台上承载各类应用业务的性能黄金三要素（交易量、交易响应时间、交易成功率）等关键指标的实时监控。

1.兼容自主可控能力建设要求

结合我社自主可控能力建设工作的相关要求，在系统设计、技术选型阶段，项目组充分考虑系统向国产化环境迁移的技术能力需要，核心技术组件均选用主流开源组件，便于向国产化环境迁移。在监控数据处理方面，本系统采用的数据明细存留和周期性数据聚合双轮驱动的数据处理模式，有效的支撑了各类监控应用场景对监控元数据的多元化需求。并积极尝试引入在数据分析型应用和数据管道型应用中广泛使用的Flink开源组件，从而较好的满足了分布式技术平台监控数据高吞吐/低延迟的特性需求。

此外，区别于传统应用性能监控系统高度集成化的设计思路，本系统在功能模块的接口封装上均设置了自定义功能，有利于后期基于监控数据挖掘产生的新监控需求快速落地。

2.基于DevOps实现监控对象自适应

在监控数据采集方面，充分借鉴了近年广泛应用的“埋点式”应用性能监控方案的设计精髓，但又在其基础上进行了一定程度上的发展和拓延，通过对分布式技术平台微服务调用流水信息的充分应用，实现了对被监控对象（分布式技术平台）的 “零成本”改造，自动获取新增业务变化相关指标，实现新增微服务、功能接口、业务场景“自感知”监控。

3.业务链路与性能指标的融合

本系统通过对离线数据智能分析，自动维护业务场景调用链路拓扑，并在运维场景融合方面，通过业务场景自定义功能、业务链路拓扑功能使得应用性能监控数据与业务链路信息、业务场景信息有机融合，丰富了应用性能监控数据的使用场景，提升了应用性能监控数据的使用价值。

4.自校正异步处理数据导致的曲线畸变

一般应用性能监控系统为提升监控数据处理效能，对采集点收集的监控源数据多进行异步处理，无法保证采集数据处理时序的完全一致性。为有效的抑制与改善因上述原因导致的监控性能曲线畸变现象，本系统自主创新了异步数据处理时间补偿机制，通过对部分监控采集数据的错乱时序进行准实时修正，对曲线畸变现象进行了一定程度上的抑制和改善，大程度保证了监控数据的有效性和实时性。

四、技术实现特点

1.无侵入式的数据采集

传统的应用性能监控系统主要通过在目标服务器中安装代理进行应用性能数据的采集和获取。这种方式使监控实施人员需要频繁对监控目标设备进行操作，对运行生产安全有一定影响。并且代理在数据采集的过程中，会对监控对象所在的平台性能有所损耗。

本系统则通过充分利用陕西信合分布式技术平台注册中心的微服务调用流水信息，实现了对监控对象（主要为分布式技术平台上运行的各类微服务、功能接口）应用性能数据的“无代理”采集。具体工作原理如下：

根据陕西信合分布式技术平台微服务调用流水信息处理机制设计，当应用发生交易（即分布式技术平台上的微服务相互调用）时，每笔微服务调用流水信息（含有微服务调用的服务方、消费方、请求时间、响应时间、调用结果等元数据）的数据都会被分布式技术平台注册中心收集。而本系统通过对接分布式技术平台的注册中心组件，直接获取其异步推送到本系统kafka消息队列中的微服务调用流水信息，完成对监控对象的性能元数据采集。如下图所示：

图 5 交易数据数据流向

这种采集方式有效的避免了因数据采集失败或采集代理资源过度消耗而产生的对被监控对象的性能干扰。在数据处理方面，因消息异步推送机制的存在，将监控对象业务活动和监控系统内部数据处理进行了解耦，实现了微服务调用流水信息的旁路采集，在本系统中进行的监控数据采集和处理活动不介入原交易（微服务调用）业务处理逻辑。

同时，此种采集模式为应用性能监控系统的采集扩展提供了便利。必要时，可以对接不同的注册中心、第三方的监控数据，实现对采用分布式架构的其他技术平台监控数据的敏捷接入。

2.高吞吐、低延迟的数据多维处理

随着我社以网点智能化转型项目为代表的数字化转型工作不断推进，陕西信合分布式技术平台上承载的微服务数量将不断增多，本系统所监测的交易数据（微服务调用流水）量也会成几何式增长。为减少本系统在处理海量交易数据流水时的数据延迟，大化发挥实时监控的价值，通过反复比较和验证，我们终选择开源的流处理引擎Flink作为本系统的实时数据处理组件。考虑到实时数据处理组件对并发处理能力和组件可用性要求较高，我们对其部署架构进行了高可用、高扩展性的集群设计。

图 6 高可用设计

此外，项目组根据实际场景需要，对Flink进行了接口改造和个性化功能封装。通过系统上线前的非功能测试实测，目前分布式技术台监控系统已确认可支持2W笔/秒的实时数据处理计算。

3.有效的延迟数据补偿机制

在本系统对实时交易数据的处理过程中，由于微服务调用流水信息中存储的各类时间信息为微服务实例所在主机的本地时间，微服务通讯SDK组件在向分布式技术平台注册中心组件进行微服务调用流水信息上传时采用异步通讯机制，故本系统在接收分布式技术平台注册中心所推送的微服务调用流水信息时，无法完全保证这些信息是严格按照时序排序的。按照一般应用性能监控系统对流式数据处理的逻辑或惯例，往往在聚合周期内进行窗口数据聚合时，对这部分错序数据将按当前处理窗口时间而非交易实际应对应的窗口时间标识，导致应用性能曲线绘制不精确，出现预期外的畸变点（曲线毛刺），一定程度上影响了应用性能监测效果。在传统的各类应用性能监控系统（APM）中，因为采集点分布在不同设备或主机上，在异步数据处理的机制下，亦会出现同类问题。

图 7 问题原因示意

为有效的规避上述问题，项目组通过对陕西信合分布式技术平台上承载的交易数据（微服务调用流水）进行充分的调研分析，通过自主创新的时间补偿机制设计，对部分监控采集数据的错乱时序进行准实时修正。基本实现原理如下：通过调研发现，数据可能会存在0~3秒内的正常延迟（由于异步数据处理机制导致），或大1分钟的异常延迟（如功能接口响应超时），因此在聚合窗口处理数据的时候，对于延迟小于3秒的正常延迟数据，首先比对待处理交易的实际发生时间与当前聚合窗口的窗口时间（窗口期内所处理的晚交易时间作为当前窗口时间），若不匹配，则将已错过聚合窗口的数据放至初聚合缓存区内，并通过独立线程定期将缓存区内的数据与其真实交易窗口内的其他交易数据进行重新聚合，并刷新性能曲线，以此来进行曲线修正，通过以上机制能够及时修正正常延迟导致的错序数据。同时，为了保证数据处理的性能，大于3秒的异常延迟数据会通过新增聚合周期结果，在数据消费时通过逻辑计算进行数据修正。通过对于不同延迟类型的不同处理机制，既保证了新的交易聚合周期95%的数据及时性，也同时保证数据时间准确性达到100%，同时极大的提高了Flink任务处理数据的效率，保证了监控数据的有效性和实时性。

图 8 处理方案

4.智能化监控-交易调用链

包含陕西信合在内的中小金融机构一直以来在分布式系统运维面临一个难题，即：当交易出现问题时，如何快速、准确的从成百上千的应用节点及微服务实例中，找到异常的节点。为了解决这个难题，陕西信合分布式技术平台充分发挥在建设初期定立的微服务交易报文头规范的标准定义价值，通过全局流水号在注册中心组件内，对单笔交易进行了链路追踪。链路追踪具体实现原理如下：

分布式技术平台通过交易的全局流水号将一笔交易的所有数据关联起来，根据交易的请求流水号和源请求流水号，确定每个应用节点两两之间的调用关系，描绘出每一笔交易的调用链，达到调用关系可视化的效果。

通过使用【查看交易调用链】功能，运维人员可以快速了解到交易的调用过程以及涉及到应用节点。当业务交易出现问题时，对应的交易链路图中的节点会变为红色，同时将鼠标悬浮到节点上，即可定位到问题节点。此外，通过交易调用链，可以调转到日志查询页面，将交易的全局流水号作为查询条件，对应用日志进行全文检索。用户亦可以自定义查询条件，对应用日志进行全文检索，点击操作栏中的“上下文”查看有问题的节点的日志数据。而本系统通过功能集成的方式引入了该项功能。用户在进行应用性能曲线观测时，可通过在交易曲线界面选中想进行详细探查的数据点，系统将根据选中的数据点时间，查询此区间的所有交易明细。用户在查询结果中可以指定交易条目，通过使用【查看交易调用链】功能，通过调用分布式技术平台内置的链路查询功能，查看每一笔交易在全生命周期中的微服务调用情况，了解业务交易的处理流程，从而实现对我社分布式技术平台上承载的各类应用系统的交易数据从“宏观”到“微观”的多视角监测。

图 9 运行曲线及单笔链路

5.智能化监控-业务场景监控

在分布式技术平台上落地的各类业务场景中，具体业务处理逻辑的调用链条深度、广度，往往会贯穿多个能力中心或外围系统，且单一业务场景上的微服务之间的调用关系错综复杂，加大了运维人员故障定位的难度。单纯依靠传统运维模式中通过调阅业务流程设计文档或者其他辅助文本资料来确定该业务场景的微服务调用链条设计，从请求发起首系统开始进行依次分析，采用传声筒式的故障定位和排查模式，将耗费大量人力物力。且随着业务逻辑的高速迭代，业务场景的微服务调用链路通过人工维护的有效性难以保证。

为降低各业务场景下微服务调用链路的人工维护成本，提高链路的精确性、可用性和及时性。本系统通过对存量离线数据进行持续学习，使用核心算法，依照不同的数据可信度使用差异化的链路拓扑生成机制。在高可信度数据满足的条件下，系统将持续自动分析和学习存储微服务调用流水信息中微服务调用关系，沉淀生成该业务场景下的微服务调用链路信息，并依据指定算法规则生成指定场景下的业务微服务调用链路拓扑。对低可信度数据，系统将根据可信度等级将预生成的微服务调用链路推送至人工确认环节或直接支持管理员维护业务拓扑脉络。以此解决数量众多、分支脉络复杂、频繁迭代的业务场景调用链路拓扑。

同时，为了实现更全面的监控业务场景，本系统将业务场景下的服务调用链路和实时监控数据进行了较好的融合。系统在简洁宏观的业务链路图上以流速、流量、颜色等方式实时展示各链路节点对应的微服务的交易量、交易响应时间、交易成功率等关键性能指标，使得监控人员更加直观快速的监测当前业务中交易量的趋势、交易耗时的快慢、成功率的高低。同时，为了解决上述视图下业务的调用顺序、调用层级无法良好体现的弊端，通过业务调用图按照由上而下体现调用顺序、从左至右体现调用层级，并加以数据过滤器，便于回溯任何时段中业务各调用层级的运行情况。

图 10 业务调用链路

五、项目过程管理

1.项目启动

本项目于2022年3月中旬启动。项目启动阶段主要工作内容包括制定工作说明书、组建项目组、召开项目启动会等工作等。

2.总体调研

此阶段于2022年3月下旬进行，主要工作内容为项目组在成立后对项目整体的需求范围进行分析。分析工作内容包括：

网转环境调研:对目前使用的传统式应用性能监控系统使用现状及存在的问题、网点智能化转型环境系统架构、环境部署信息、交易日志结构、数据质量、分布式技术平台处理机制等。通过调研及访谈，根据总体调研情况，初步制定分布式技术平台监控系统建设方案、系统架构、数据处理逻辑等。调研监控管理岗、一线运维人员等实际系统用户在故障排查、监控值机、故障告警等应用场景的诉求。

需求分析：对分布式技术平台监控系统功能覆盖配置方案及范围、告警配置方案、数据清洗加工方案、业务场景监控等需求进行分析，对分布式技术平台监控系统与分布式技术平台、统一告警平台系统联通性等技术需求进行分析。

需求跟踪和进度报告：对需求及进度进行跟踪及汇报

3.功能设计及本地化功能开发

此阶段开展时间为2022年3月下旬至4月下旬。主要工作内容包括：

数据处理中心清洗加工聚合逻辑开发，存储中心索引、表结构设计，报表中心统计中心规则开发，大屏管理模块、业务管理、查询中心逻辑开发。

业务场景算法、数据可信度规则设计、自动沉淀拓扑逻辑，业务监控链路图、业务调用拓扑图功能开发。

分布式技术平台数据接入、统一告警平台接口实现

对通过测试的分布式技术平台监控系统进行上线部署准备。包括完成安全漏洞扫描、部署方案设计、验证方案设计、回退计划指定等前置工作，并按照《陕西信合应用系统上线规范》准备上线申请材料，接受上线评审。

4.平台测试  

此阶段时间为2022年5月上旬至5月中旬。在本阶段内，项目组按照陕西信合应用系统测试规范，配合测试部门完成了本地化平台版本的集成测试、UAT测试、非功能测试、安全评估测试等工作，并由测试部门出具终测试报告。

5.平台部署

此阶段时间为2021年5月下旬。本系统已于5月20日随陕西信合网转项目群（一期）一同正式上线。在本阶段内，项目组开展了相关系统上线前部署准备工作，包括运行平台资源申请、设计部署方案、验证方案、回退计划等。按照行内要求，提请变更申请流程，进行变更评审，并按照预定部署方案变更步骤的实施。

6.平台试点系统接入及试运行

此阶段起始时间为2022年5月至今，主要工作内容包含以下：

监测网点智能化转型一期上线的能力中心、微服务、功能接口、业务交易数据在本系统的接入情况，并对采集的监控数据进行抽样验证。

使用本平台采集的监控数据，协助定期整理各重要业务相关业务场景、微服务、功能接口的运行情况报表。

对运行监控岗及值机人员进行系统使用培训。

六、运营情况

通过本平台建设，我社基本具备了在当前复杂的分布式生产环境中故障定位、运行状态监测、业务健康度监测等场景中高效的运维能力，有效的提升了运维工作的智能化水平。目前已经纳管了分布式生产环境37个能力中心，129个微服务实例，2000余个功能接口的交易数据，覆盖分布式环境中所有实例对象。通过分布式技术平台监控系统的建立，实现高效的交易数据接入、监测、统计、分析能力，已累计处理6000W余条交易数据，并持续对业务运行健康状态进行监测。

通过平台自主研发的核心算法、智能化学习逻辑，系统自动分析并建立36个业务场景的调用链路拓扑、调用关系拓扑，提升了我社运维能力，并基本构建了网点智能化转型中全部重要业务的智能稳定的业务级监控体系。

七、项目成效

1.实现了低维护成本的分布式环境监控

分布式技术平台监控系统基于统一的通讯SDK，实现了分布式环境微服务、功能接口交易数据自动接入，达到上线即监控的目标，降低了新服务上线对监控系统的影响，降低了对被监控应用的资源消耗，实现应用与监控的解耦。减少由于人为操作失误导致的漏监情况的发生。具有高效、安全、易扩展、低维护的特点。

2.提高了故障发现准确率、故障点定位效率

分布式技术平台监控系统在经过一段时间的生产数据沉淀后，已自动维护36个重要业务场景的链路拓扑关系，并建立1383条关系数据。在排查业务响应耗时长、业务发生故障等场景中提供易排查、可视化、便操作的运维场景。并通过算法实现可持续、低人工干预的业务场景链路拓扑关系维护能力，降低了由于系统迭代导致拓扑关系失真的问题。通过业务调用链路拓扑与性能指标监控的融合，实现业务级监控，使运维人员定位业务故障点的排查时间下降了60%。

并通过告警规则的配置，可对能力中心、微服务、功能接口各层级的对象进行监控，并加以实时告警、聚合数据告警两种类型规则分类的配置，实现单条交易数据的成功情况、耗时情况或调用主机、指定错误码等业务、技术数据进行实时监控，也可通过定数据量、定统计周期等多告警规则方式灵活配置，实现多条数据情况下交易量、成功率、平均耗时的实时检测。满足了监控告警的各种业务、技术需求，提升了告警类型丰富度、准确性。

3.为业务优化提供有力的数据支撑

分布式技术平台监控系统通过丰富、灵活的报表功能，向开发人员在性能优化的过程中，提供了有力的多维性能数据支撑。通过智能业务链路拓扑功能，在业务调用深度、调用广度分析工作中，为业务设计人员提供可视化、免维护的数据分析支撑，并通过与性能指标的融合，快速分析业务处理效率较低、存在异常的服务节点，为提高业务处理效率提供准确、可靠的分析数据。

八、经验总结

项目建设至今，按照项目整体规划，初步完成了以业务应用为目标的分布式技术平台监控系统建设，稳定高效的对分布式环境的能力中心、微服务、功能接口及复杂交易业务进行监控，补齐了监控领域在分布式环境中的空白。并结合我社数字化转型工作进程，建立以分布式技术平台为基础的监控能力体系，预留后期与CMDB、统一运维操作平台、运维数据中台等应用层平台的数据、能力接口。项目建成的业务调用链路拓扑，能持续智能的进行拓扑关系自维护，提高故障定位、根因分析等运维场景中分析效率，支撑我社重要业务在变更、故障分析、业务趋势预测等场景下的数据支撑能力。