(19)国家知识产权局 (12)发明 专利申请 (10)申请公布号 (43)申请公布日 (21)申请 号 202111624042.9 (22)申请日 2021.12.2 2 (71)申请人 百望股份有限公司 地址 100094 北京市海淀区北清路中关村 壹号A1楼17层 (72)发明人 陈杰　杨正道　田志涛　 (51)Int.Cl. G06Q 30/04(2012.01) G06Q 10/06(2012.01) G06Q 10/04(2012.01) G06F 11/30(2006.01) G06F 16/2458(2019.01) (54)发明名称 反向追溯企业发票系统配 置的方法 (57)摘要 本发明公开了一种反向追溯企业发票系统 配置的方法， 包括： 数据采集； 对采集的数据进行 分析； 根据分析的结果进行监控预警； 性能分析； 故障定位。 本发明的方法， 降低了故障的发生率， 当反向追溯出现故障的时候， 可以有效地评估出 影响范围， 及时找到对应问题点， 能够第一时间 防止雪崩现象产生； 降低了运维成本， 全方面资 源采集+链路追踪， 可以实时提供资源使用率， 有 效的提高运维工作， 从而降低成本浪费； 扩展了 传统的链路追踪范围， 将企业发票系统所依赖、 所相关的资源都进行了监控跟踪、 更加保障了软 件稳定范围。 权利要求书1页 说明书9页 附图3页 CN 114445162 A 2022.05.06 CN 114445162 A 1.一种反向追溯企业发票系统配置的方法， 其特 征在于， 包括： 数据采集； 对采集的数据进行分析； 根据分析的结果进行监控预警； 性能分析； 故障定位。 2.根据权利要求1所述的反 向追溯企业发票系统配置的方法， 其特征在于， 所述数据采 集包括： 通过定时任务实施采集基础资源的资源信息 通过定时任务实施采集 业务功能信息 。 3.根据权利要求1所述的反 向追溯企业发票系统配置的方法， 其特征在于， 所述对采集 的数据进行分析包括： 基础资源的映射分析； 业务功能资源的映射分析。 4.根据权利要求1所述的反 向追溯企业发票系统配置的方法， 其特征在于， 所述根据分 析的结果进行监控预警包括： 基于资源的定期检查， 根据检查监控数据， 根据分析的结果， 对照指标数据， 实施预警 或者报警； 若出现预警或者报警， 则逆向梳理调用链路， 获取到到影响源头范围， 并进行通 知。 5.根据权利要求1所述的反 向追溯企业发票系统配置的方法， 其特征在于， 所述性能分 析包括： 基于采集到的基础资源的性能等信息， 按照资源采集获取的使用量进行比例计算， 获 取性能指数。 6.根据权利要求1所述的反 向追溯企业发票系统配置的方法， 其特征在于， 所述故障定 位包括： 通过调用链路拓扑关系， 结合预警或报警信息以及性能分析的结果， 实现快速 定位。 7.一种反向追溯企业发票系统配置的装置， 其特 征在于， 包括： 数据采集模块， 用于数据采集； 数据分析模块， 用于对 采集的数据进行分析； 监控预警模块， 用于根据分析的结果进行监控预警； 性能分析模块， 用于性能分析； 定位模块， 用于故障定位。 8.一种电子设备， 其特征在于， 包括存储器、 处理器及存储在所述存储器上并可在所述 处理器上运行的计算机程序， 所述处理器执行所述程序， 以实现如权利要求 1‑6任一项所述 的反向追溯企业发票系统配置的方法。 9.一种非临时性计算机可读存储介质， 其上存储有计算机程序， 其特征在于， 该程序被 处理器执行， 以实现如权利要求1 ‑6任一项所述的反向追溯企业发票系统配置的方法。权　利　要　求　书 1/1 页 2 CN 114445162 A 2反向追溯企业发票系统配置的方 法 技术领域 [0001]本发明涉及电子发票技术领域， 具体涉及一种反向追溯企业发票系统配置的方 法。 背景技术 [0002]为了支撑日益增长 的庞大电子发票量， 大量采用微服务架构。 服务按照不同的维 度进行拆分， 互联网应用构建在不同的软件模块集上， 可能布在了几千台服务器， 横跨多个 不同的数据中心， 功能的依赖、 服务的依赖、 软硬件之 间相互的依赖似的分布式系统变得日 趋复杂。 [0003]如何快速进行发票故障定位， 如何准确进行发票容量评估， 如何动态展示服务的 链路， 如何进 行系统性能优化， 这是电子发票分布式系统巨大挑战。 现有技术存在的技术缺 陷包括： [0004]故障定位难： 一次请求往往需要涉及到多层网络、 多个服务、 多个硬件服务， 这些 很可能是由多个团队负责的。 一旦出问题， 只知道有异常， 但具体的异常在哪个服务引起的 就需要进入每一个服务里面看日志， 这样的处理效率是非常低的。 最坏的情况可能要拉上 多个团队一 起定位。 [0005]容量评估难： 由于电子发票的使用特殊性， 导致流量入口经常不 同。 ， 不同入口的 流量导致各模块的qps增量是不同的， 容 量评估是一件 难事。 [0006]链路梳理难： 由于服务调用复杂， 链路过深， 一个模块， 根本不知道自己身在何处， 不知道自己的系统被谁依赖 了， 也不知道自己的系统下游 依赖哪些服 务， 费时费力。 [0007]性能分析难： 一个服务依赖于后台多个服务， 如果某接口的耗时突然增加， 开发得 从自己开始， 逐步分析 各依赖接口的耗时情况。 [0008]监控跟踪范围小， 仅仅局限于软件、 微服务层面的链 路追踪， 所以调用访问链 路范 围局限性很高， 无法支撑起整体系统。 [0009]故障影响范围难以确定， 因为传统链路都是基于请求自上而下， 融入底层出现故 障， 很难、 或者无法进行逆向追溯； 如某个底层功能故障， 无法 反向追溯到上层业 务。 [0010]故障连锁风险高， 由于监控跟踪范围有限、 故障无法反向追溯， 导致出现问题、 出 现故障后无法第一时间判断影响范围， 从而会导 致连锁雪崩现象出现。 发明内容 [0011]本发明的目的是提供一种反向追溯企业发票系统配置的方法。 为了对披 露的实施 例的一些方面有一个基本的理解， 下面给出了简单的概括。 该概括部 分不是泛泛评述， 也不 是要确定关键/重要组成元素或描绘这些实施例的保护范围。 其唯一 目的是用简单 的形式 呈现一些概念， 以此作为后面的详细说明的序言。 [0012]根据本发明实施例的一个方面， 提供一种反向追溯企业发票系统配置 的方法， 包 括：说　明　书 1/9 页 3 CN 114445162 A 3