CN113347033B - 基于区块链的根因定位方法、系统及验证节点 - Google Patents

Abstract

本申请提供了一种基于区块链的根因定位方法、系统及验证节点，涉及区块链技术领域，该方法包括：接收目标异常交易的交易重现请求，将该交易重现请求广播至区块链的各个验证节点，以使每个验证节点分别根据各自对应的动态日志配置文件和所述交易重现请求，执行所述目标异常交易并生成该目标异常交易对应的动态日志文件；若接收到日志搜集请求，则根据该日志搜集请求获得各个验证节点的动态日志文件，以根据各个验证节点的动态日志文件完成所述目标异常交易的根因定位。本申请能够提高交易日志搜集的效率，进而能够提高异常交易根因定位的效率。

Description

基于区块链的根因定位方法、系统及验证节点

技术领域

本申请涉及区块链技术领域，尤其涉及一种基于区块链的根因定位方法、系统及验证节点。

背景技术

区块链网络是一种利用P2P通讯技术实现对等通信、利用共识机制实现记账合法性、利用链式结构存储数据的共同记账的解决方案。区块链网络在接收到业务系统的一笔交易请求后，涉及将交易广播到当前业务链的所有验证节点上，以及在分阶段共识过程中节点之间的复杂通讯过程，因此在交易出错或与预期结果不一致时，需要结合业务链上所有节点的日志信息进行综合排查。

业务链在组网时其节点归属于不同的联盟成员机构，在需要搜集日志进行问题排查时常需要搜集各节点的日志信息，冗长的人工线下协商、通知和协作流程，容易造成关键线索日志信息被覆盖或日志搜集时间久，导致问题排查困难或问题排查时间久，系统无法及时定位原因，影响交易业务。

发明内容

针对现有技术中的问题，本申请提出了一种基于区块链的根因定位方法、系统及验证节点，能够提高交易日志搜集的效率，进而能够提高异常交易根因定位的效率。

为了解决上述技术问题，本申请提供以下技术方案：

第一方面，本申请提供一种基于区块链的根因定位方法，包括：

接收目标异常交易的交易重现请求，将该交易重现请求广播至区块链的各个验证节点，以使每个验证节点分别根据各自对应的动态日志配置文件和所述交易重现请求，执行所述目标异常交易并生成该目标异常交易对应的动态日志文件；

若接收到日志搜集请求，则根据该日志搜集请求获得各个验证节点的动态日志文件，以根据各个验证节点的动态日志文件完成所述目标异常交易的根因定位。

进一步地，在所述接收目标异常交易的交易重现请求之前，还包括：

接收日志级别调整请求；

将所述日志级别调整请求广播至各个验证节点进行共识处理，以使每个验证节点根据共识处理成功后的日志级别调整请求中的动态日志配置信息，更新该验证节点对应的动态日志配置文件。

进一步地，所述每个验证节点分别根据各自对应的动态日志配置文件和所述交易重现请求，执行所述目标异常交易并生成该目标异常交易对应的动态日志文件，包括：

每个验证节点均从其对应的动态日志配置文件中，获得与所述目标异常交易对应的动态日志配置信息；根据所述动态日志配置信息，确定所述目标异常交易的日志级别；根据所述日志级别和交易重现请求，执行所述目标异常交易并生成该目标异常交易的动态日志文件。

进一步地，所述根据所述日志级别和交易重现请求，执行所述目标异常交易并生成该目标异常交易的动态日志文件，包括：

若所述目标异常交易的日志级别为调试级别，则根据所述交易重现请求，执行所述目标异常交易并生成该目标异常交易的动态日志文件，该动态日志文件包括：用于存储调试级别日志的调试日志文件和用于存储跟踪记录的交易跟踪文件。

第二方面，本申请提供一种验证节点，包括：

交易重现模块，用于接收目标异常交易的交易重现请求，将该交易重现请求广播至区块链的各个验证节点，以使每个验证节点分别根据各自对应的动态日志配置文件和所述交易重现请求，执行所述目标异常交易并生成该目标异常交易对应的动态日志文件；

根因定位模块，用于若接收到日志搜集请求，则根据该日志搜集请求获得各个验证节点的动态日志文件，以根据各个验证节点的动态日志文件完成所述目标异常交易的根因定位。

进一步地，所述的验证节点，还包括：

接收模块，用于接收日志级别调整请求；

日志配置调整模块，用于将所述日志级别调整请求广播至各个验证节点进行共识处理，以使每个验证节点根据共识处理成功后的日志级别调整请求中的动态日志配置信息，更新该验证节点对应的动态日志配置文件。

进一步地，所述交易重现模块，包括：

交易重现子模块，用于每个验证节点均从其对应的动态日志配置文件中，获得与所述目标异常交易对应的动态日志配置信息；根据所述动态日志配置信息，确定所述目标异常交易的日志级别；根据所述日志级别和交易重现请求，执行所述目标异常交易并生成该目标异常交易的动态日志文件。

第三方面，本申请提供一种基于区块链的根因定位系统，包括：

业务系统、运维管理系统和区块链，所述区块链包括：所述的验证节点；

所述业务系统，用于将目标异常交易的交易重现请求发送至验证节点，并接收验证节点的交易重现请求处理返回信息；

所述运维管理系统，用于将日志级别调整请求和/或日志搜集请求发送至验证节点。

第四方面，本申请提供一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现所述的基于区块链的根因定位方法。

第五方面，本申请提供一种计算机可读存储介质，其上存储有计算机指令，所述指令被执行时实现所述的基于区块链的根因定位方法。

由上述技术方案可知，本申请提供一种基于区块链的根因定位方法及装置。其中，该方法包括：接收目标异常交易的交易重现请求，将该交易重现请求广播至区块链的各个验证节点，以使每个验证节点分别根据各自对应的动态日志配置文件和所述交易重现请求，执行所述目标异常交易并生成该目标异常交易对应的动态日志文件；若接收到日志搜集请求，则根据该日志搜集请求获得各个验证节点的动态日志文件，以根据各个验证节点的动态日志文件完成所述目标异常交易的根因定位，能够提高交易日志搜集的效率，进而能够提高异常交易根因定位的效率，保证交易过程的可靠性；可以在区块链网络正常运行过程中调整特定交易的日志级别，按照交易级别输出特定日志并进行归集，验证节点之间的协商操作简单、透明且高效，能够快速输出协助用户定位并分析异常交易的交易跟踪日志，快速解决问题。具体的优点包含有：1、重启协商过程高效：组建业务链时默认部署系统智能合约，跟踪交易时通过系统智能合约的共识操作自动校验并触发相关系统流程，能够避免线下各验证节点的运维机构之间的复杂协商；2、日志级别调整操作可追溯：基于区块链技术的系统智能合约的执行，可以实现业务链的验证节点之间信任传递，操作过程安全可信并且过程可追溯；3、保障交易跟踪日志的快速归集：依据业务链内的有效标记，开启跟踪交易的详细日志并定向输出到特定文件中，有利于交易日志的快速归集，能够方便用户高效分析及定位交易异常的原因。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是本申请实施例中的基于区块链的根因定位方法的流程示意图；

图2是本申请另一实施例中的基于区块链的根因定位方法的流程示意图；

图3是本申请应用实例中的基于区块链的根因定位方法的流程示意图；

图4是本申请实施例中的验证节点的结构示意图；

图5是本申请应用实例中的基于区块链的根因定位系统的结构示意图；

图6是本申请应用实例中的验证节点的结构示意图；

图7为本申请实施例的电子设备的系统构成示意框图。

具体实施方式

为了使本技术领域的人员更好地理解本说明书中的技术方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

为了便于对本方案的理解，首先对本方案相关的技术内容进行说明。

业务链：是根据业务需求组建的区块链联盟网络，抽取业务规则为基于业务智能合约对具体的业务数据进行背书。区块链业务场景落地时，业务系统将业务智能合约部署到业务链中的每一个验证节点上，在接收到业务系统的交易请求后，各验证节点进行交易共识和交易执行。

系统智能合约：区块链系统内置的进行区块链系统内部规则处理的智能合约，其逻辑与具体的业务场景无关，每次规则变更均需要业务链网络中的各成员节点进行共识。

业务智能合约：业务系统部署在区块链系统上的进行业务规则处理的智能合约，其逻辑与具体的业务场景相关，每次规则变更均需要业务链网络中的各成员节点进行共识。

需要说明的是，本申请公开的基于区块链的根因定位方法、系统及验证节点可用于金融技术领域，也可用于除金融技术领域之外的任意领域，本申请公开的基于区块链的根因定位方法、系统及验证节点的应用领域不做限定。

具体通过下述各个实施例进行说明。

为了提高交易日志搜集的效率，进而提高异常交易根因定位的效率，本实施例提供一种执行主体是验证节点的基于区块链的根因定位方法，该验证节点包括但不限于服务器，如图1所示，该方法具体包含有如下内容：

步骤101：接收目标异常交易的交易重现请求，将该交易重现请求广播至区块链的各个验证节点，以使每个验证节点分别根据各自对应的动态日志配置文件和所述交易重现请求，执行所述目标异常交易并生成该目标异常交易对应的动态日志文件。

具体地，可以接收业务系统发送的目标异常交易的交易重现请求，该交易重现请求可以用于重新执行所述目标异常交易，以实现错误重现；所述目标异常交易为出错或与预期结果不一致的交易；每个验证节点可以根据其对应动态日志配置文件和所述交易重现请求，执行所述目标异常交易；并可以在执行目标异常交易的同时，生成动态日志文件；所述交易重现请求可以包含有：所述目标异常交易对应的业务智能合约标识和交易信息等；交易信息可以包含有：交易类型、交易金额和账号名称等；所述动态日志配置文件的格式可以如下所示：

[Flag＝1；{业务智能合约ID1:交易名称1；业务智能合约ID2:交易名称2}]

其中，可以根据所述交易重现请求中的业务智能合约标识和所述动态日志配置文件，确定所述目标异常交易对应的动态日志开关Flag的值，根据动态日志开关Flag的值设置所述目标异常交易的日志级别，可以根据所述日志级别和交易信息执行所述目标异常交易并生成所述目标异常交易对应的动态日志文件。

步骤102：若接收到日志搜集请求，则根据该日志搜集请求获得各个验证节点的动态日志文件，以根据各个验证节点的动态日志文件完成所述目标异常交易的根因定位。

具体地，所述日志搜集请求可以包含有：系统智能合约标识、业务智能合约标识和交易标识，所述业务智能合约标识可以是业务智能合约ID，是业务智能合约的唯一标识，用于区分不同的业务智能合约；交易标识可以是交易名称，是交易的唯一标识，用于区分不同的交易，系统智能合约标识、业务智能合约标识和交易标识可以分别是一串字符串。可以根据所述日志搜集请求中的交易标识，从各个验证节点中获得文件名包含有该交易标识的动态日志文件。

区块链中的目标验证节点可以将各个验证节点的动态日志文件输出至该目标验证节点对应的运维管理系统并输出显示，以根据各个验证节点各自的动态日志文件，确定存在异常的验证节点，以便于接下来验证节点的维护，保证交易的安全性，同时，还能够降低数据交互过程的复杂程度。

为了在提高交易日志搜集的效率的基础上，提高交易日志搜集的准确性，参见图2，在本申请一个实施例中，在步骤101之前，还包括：

步骤201：接收日志级别调整请求。

具体地，所述日志级别调整请求可以包含有：系统智能合约标识和动态日志配置信息。

具体地，所述动态日志配置信息的结构可以如下所示：

[Flag＝1；{业务智能合约ID1:All；业务智能合约ID2:交易名称2}]

步骤202：将所述日志级别调整请求广播至各个验证节点进行共识处理，以使每个验证节点根据共识处理成功后的日志级别调整请求中的动态日志配置信息，更新该验证节点对应的动态日志配置文件。

具体地，可以应用所述动态日志配置信息替换所述动态日志配置文件中的所有数据。

由上述描述可知，本实施例提供的基于区块链的根因定位方法，能够根据日志级别调整请求中的动态日志配置信息，变更动态日志配置文件中的日志级别，以便于接下来根据动态日志配置文件中的变更后的日志级别，输出更为详细的日志信息，可以按最详细的日志级别，将目标异常交易的日志信息记录在动态日志文件中，并做统一归集，以实现异常交易根因的快速定位。

为了节省系统磁盘空间，同时保证交易日志的可靠性，在本申请一个实施例中，步骤101中的所述每个验证节点分别根据各自对应的动态日志配置文件和所述交易重现请求，执行所述目标异常交易并生成该目标异常交易对应的动态日志文件，包括：

步骤1011：每个验证节点均从其对应的动态日志配置文件中，获得与所述目标异常交易对应的动态日志配置信息；根据所述动态日志配置信息，确定所述目标异常交易的日志级别；根据所述日志级别和交易重现请求，执行所述目标异常交易并生成该目标异常交易的动态日志文件。

具体地，所述日志级别可以包含有：FATAL级别、ERROR级别、WARNG级别、INFOR级别和DEBUG级别。FATAL级别只记录系统致命错误日志；ERROR级别记录致命错误日志和普通错误日志，即包含FATAL和ERROR级别信息；WARNG级别记录致命错误日志、普通错误日志和警告级别日志，即包含FATAL、ERROR和WARNG级别日志；INFOR级别记录致命错误日志、普通错误日志、警告级别日志和系统关键运行日志，即包含FATAL、ERROR、WARNG和INFOR级别日志；DEBUG级别即调试级别为最详细日志记录，会记录系统所有设定的日志信息，即包含FATAL、ERROR、WARNG和DEBUG级别日志。

可以在常规运行时将日志级别设定为INFOR级别，只输出系统关键运行信息；在需要更详细的日志信息进行交易排查时，开启DEBUG级别，能够避免日志刷新太快浪费系统磁盘空间，以及避免循环记录时将关键信息刷新掉。同时设置交易跟踪TRACE配置，支持按智能合约的交易跟踪记录，在需要根据跟踪进行交易排查时,交易跟踪开启，会打印交易在每个功能模块中流转的详细数据信息。

作为优选，为了实现交易日志的快速归集，所述根据所述日志级别和交易重现请求，执行所述目标异常交易并生成该目标异常交易的动态日志文件，包括：若所述目标异常交易的日志级别为调试级别，则根据所述交易重现请求，执行所述目标异常交易并生成该目标异常交易的动态日志文件，该动态日志文件包括：用于存储调试级别日志的调试日志文件和用于存储跟踪记录的交易跟踪文件。

其中，所述调试日志文件即debug.log文件，交易跟踪文件即.trace文件。

为了进一步说明本方案，参见图3，本申请提供一种基于区块链的根因定位方法的应用实例，具体描述如下：

步骤301：业务链的验证节点启动，启动时加载日志配置文件log.ini和动态日志配置文件dynamicLog.ini。

其中，动态日志配置文件根据业务智能合约共识，并根据系统智能合约标识加载，各个验证节点的动态日志配置文件分别保存在各自的合约运行沙箱中，动态日志配置文件可以用于记录当前系统智能合约对应的需要开启DEBUG级别日志和交易TRACE的交易名称。

步骤302：交易异常时，运维管理系统发起日志级别调整请求；其中，交易异常时，业务链上的业务智能合约可能存在故障。

具体地，日志级别调整请求、交易重现请求和日志搜集请求的三种请求的格式均为Invoke(stubId,function,args)。

对于日志级别调整请求来说，stubId表示系统智能合约标识，function为“update”表示更新，args表示动态日志配置信息，args包含有：Flag、业务智能合约标识和交易标识之间的对应关系；举例来说，动态日志配置文件包含有：[Flag＝1；{业务智能合约ID1:交易名称1；业务智能合约ID2:交易名称2}]，若需要将业务智能合约ID1的全部交易开启，则发送的日志级别调整请求中的args为：[Flag＝1；{业务智能合约ID1:All；业务智能合约ID2:交易名称2}]。

其中，交易重现请求中的stubId表示业务智能合约标识，function为“reset”表示交易重现，args表示交易信息；日志搜集请求中的stubId表示系统智能合约标识，function为“query”表示查询，args表示待获取动态日志的交易名称。

步骤303：验证节点接收日志级别调整请求。

步骤304：验证节点对日志级别调整请求进行共识，共识成功后将日志级别调整请求中的动态日志配置信息更新到动态日志配置文件中，更新成功后返回动态日志开启成功信息给运维管理系统。

步骤305：业务系统发起交易重现请求以进行交易异常重现；验证节点接收交易重现请求；根据dynamicLog.ini文件中记录的动态日志配置信息，判断是否记录所述交易重现请求对应的交易的动态日志，若是，则在“./logs/智能合约ID/交易/”路径下，记录文件名为：交易名.验证节点编号.debug.年月日.log和文件名为：交易名.验证节点编号.年月日.trace的动态日志文件。

步骤306：交易完成后运维管理系统发起日志搜集请求。

步骤307：一验证节点接收到日志搜集请求后，将日志搜集请求广播至业务链的其它所有验证节点上，其它各验证节点将对应交易的动态日志文件传输到发出日志搜集请求的验证节点的交易动态日志路径“./logs/智能合约ID/交易/”下，动态日志文件包括调试日志文件和交易跟踪文件。

步骤308：用户可在运维管理系统中完成重现交易过程中业务链上的所有验证节点的日志查看，准确定位交易失败原因。

从软件层面来说，为了提高交易日志搜集的效率，进而提高异常交易根因定位的效率，本申请提供一种用于实现所述根因定位方法中全部或部分内容的验证节点的实施例，参见图4，所述验证节点具体包含有如下内容：

交易重现模块41，用于接收目标异常交易的交易重现请求，将该交易重现请求广播至区块链的各个验证节点，以使每个验证节点分别根据各自对应的动态日志配置文件和所述交易重现请求，执行所述目标异常交易并生成该目标异常交易对应的动态日志文件。

根因定位模块42，用于若接收到日志搜集请求，则根据该日志搜集请求获得各个验证节点的动态日志文件，以根据各个验证节点的动态日志文件完成所述目标异常交易的根因定位。

在本申请一个实施例中，所述的验证节点，还包括：

接收模块，用于接收日志级别调整请求。

日志配置调整模块，用于将所述日志级别调整请求广播至各个验证节点进行共识处理，以使每个验证节点根据共识处理成功后的日志级别调整请求中的动态日志配置信息，更新该验证节点对应的动态日志配置文件。

在本申请一个实施例中，所述交易重现模块，包括：

交易重现子模块，用于每个验证节点均从其对应的动态日志配置文件中，获得与所述目标异常交易对应的动态日志配置信息；根据所述动态日志配置信息，确定所述目标异常交易的日志级别；根据所述日志级别和交易重现请求，执行所述目标异常交易并生成该目标异常交易的动态日志文件。

本说明书提供的验证节点的实施例具体可以用于执行上述根因定位方法的实施例的处理流程，其功能在此不再赘述，可以参照上述根因定位方法实施例的详细描述。

本申请还提供一种基于区块链的根因定位系统的实施例，在本实施例中，该根因定位系统包括：业务系统、运维管理系统和区块链，所述区块链包括：所述的验证节点；所述业务系统，用于将目标异常交易的交易重现请求发送至验证节点，并接收验证节点的交易重现请求处理返回信息；所述运维管理系统，用于将日志级别调整请求和/或日志搜集请求发送至验证节点。所述验证节点、业务系统和运维管理系统均包括但不限于服务器，所述业务系统可以分别与各验证节点连接，所述运维管理系统可以是多个，每个运维管理系统均与至少一个验证节点连接。

为了进一步说明本方案，本申请提供一种基于区块链的根因定位系统的应用实例，用于实现上述基于区块链的根因定位方法，参见图5，在本应用实例中，在组建业务链时在验证节点上同时部署业务智能合约和系统智能合约，系统智能合约通过对运维管理系统发起的日志级别调整请求进行共识，修改业务链上的验证节点的动态日志，将要排查的交易按最详细的日志级别记录在特定的日志文件中并做统一归集，以实现交易问题快速定位，所述根因定位系统包含有：业务链1、验证节点2、运维管理系统3和业务系统4，具体描述如下：

业务链1为根据外部业务系统4的上链业务需求组建而成，链上包括多个验证节点2，均属于业务链的成员节点，成员节点上均部署有与运维管理系统3进行系统操作请求交互的系统智能合约，以及与业务系统4进行交易请求交互的业务智能合约，系统操作请求可以是指日志级别调整请求或日志搜集请求。验证节点总数为3f+1个，其中f表示可支持的容错节点个数，最小值为1，系统操作请求和交易请求均采用拜占庭容错算法(PracticalByzantine Fault Tolerance，简称pbft)进行共识，一笔共识请求必须在业务链中的每个验证节点收到至少2f+1个来自其他验证节点的一致的确认消息后，该笔交易才能完成当前阶段的共识，拜占庭容错算法三个阶段的共识都完成后才共识成功，系统操作请求和交易请求才被执行，执行结果才能作为合法数据生成新的区块并进行持久化。

验证节点2，用于接收运维管理系统3发起的系统操作请求以及业务系统4发起的交易请求，所有验证节点内部结构均一致，对交易进行权限验证并完成重复及参数合法性校验，校验通过后将交易广播至业务链1中的其他所有验证节点，接收业务系统4的待共识交易的区块广播通知，对待共识交易进行参数合法性校验，校验通过后则进入三段式共识过程，第一阶段为pre-prepare共识，第二阶段为prepare共识，第三阶段为commit共识，三个阶段为顺序执行，当前一阶段累计收到2f+1个其他交易共识节点的一致确认消息后当前阶段的共识完成并进入下一阶段，三个阶段的共识全部完成后代表区块批量共识消息合法，按合约中的逻辑处理后的数据生成新的区块数据，并触发合约执行后的相关流程。验证节点启动时根据设置的日志级别进行交易日志记录，日志级别设计为“FATAL、ERROR、WARNG、INFOR、DEBUG”5个日志级别：验证节点2的日志配置文件为log.ini，配置文件格式为：

LogLevel＝4[FATAL:1ERROR:2WARNG:3INFOR:4DEBUG:5]

Trace＝0[0:关闭1:打开]

配置文件log.ini对验证节点上所有业务智能合约生效。

验证节点2的动态日志配置文件为dynamicLog.ini配置文件格式为：

Flag:1[0:关闭1:开启]

业务智能合约ID1:交易1；交易2；......

业务智能合约ID2:交易1；交易2；......

dynamicLog.ini对验证节点上所有模块生效；只有当动态日志开关Flag配置为1时，其配置的业务智能合约ID对应的所有交易都会开启动态交易模式，即当Flag为1时，配置的业务智能合约ID对应的交易会开启DEBUG级别的日志同时会记录TRACE，当业务智能合约ID后面未配置交易信息时默认该业务智能合约的所有交易都会开启动态交易模式。

运维管理系统3，是验证节点2的配套管理运维系统，通常由不同的业务链1联盟成员方各自部署，一个运维管理系统3可根据业务链1的联盟运营公约运维管理1个或多个验证节点2，即业务链1的多个验证节点2同时配套多个运维管理系统3，每个运维管理系统3的内部结构均一致，仅管理的验证节点3信息不同。运维管理系统3可发起日志级别调整请求到验证节点2，同时可以触发交易日志文件搜集操作。

业务系统4，是业务交易请求发起系统，向业务链1的验证节点2发起交易请求，包括更新类交易和查询类交易请求，并接收验证节点2的交易请求处理返回信息，实现相关业务的逻辑闭环。

为了进一步说明本方案，本申请还提供一种验证节点的应用实例，参见图6，在本应用实例中，该验证节点包括：外部请求收发模块11、交易路由模块12、系统合约共识及执行模块13、业务合约共识及执行模块14，具体描述如下：

外部请求收发模块11，负责接收运维管理系统3发起的日志级别调整请求、日志搜集请求以及业务系统4发起的交易请求，根据交易证书对交易进行验密，根据交易请求Invoke(stubId,function,args)中的智能合约标识stubId(stubId为部署系统智能合约后，业务链1返回的某一智能合约的唯一标识)，检测交易的重复提交等操作，将校验通过的交易请求转发至交易路由模块12。

交易路由模块12，负责主控交易进入对应的合约共识路由，根据业务智能合约标识路由到对应的业务合约共识及执行模块，如将运维管理系统3发起的日志级别调整请求和日志搜集请求转发到系统合约共识及执行模块13，将业务系统4发起的交易请求转发到业务合约共识及执行模块14。

系统合约共识及执行模块13，是业务链交易动态跟踪的核心工作模块，负责对运维管理系统3发起的日志级别调整请求进行共识、并按照系统智能合约规则来触发业务链区块链网络的日志调整操作，并反馈调整结果给运维管理系统3、系统合约共识及执行模块，具体包含有：指令校验单元131、指令共识单元132、指令通知发送单元133及日志搜集交互单元134。

指令校验单元131，是对动态日志配置信息进行校验并进行日志级别调整请求共识预处理的模块，负责校验日志级别调整请求的参数及来源等信息，校验通过后将生成日志级别调整请求区块的hash，将区块共识消息保存到本地磁盘中，将区块序号加1，将区块共识消息广播到业务链1中的所有验证节点2中。

指令共识单元132，是完成日志级别调整请求共识的核心模块，使用拜占庭共识算法对交易进行三段式共识过程，第一阶段为pre-prepare共识，第二阶段为prepare共识，第三阶段为commit共识，三个阶段为顺序执行，当前一阶段累计收到2f+1个其他交易共识节点的一致确认消息后当前阶段的共识完成并进入下一阶段，三个阶段的共识全部完成后代表该日志级别调整请求合法，按系统智能合约逻辑处理后的数据写入区块进行持久化背书，同时将结果更新到动态日志配置文件dynamicLog.ini中。

指令通知发送单元133，是完成日志级别调整请求共识结果流转的工作流模块，负责将日志级别调整请求的共识结果根据业务智能合约标识通知到对应的业务合约共识及执行模块14和运维管理系统3，由业务合约共识及执行模块14进行交易日志记录处理，由运维管理系统3根据日志级别调整请求的结果进行交易重现及重现后的日志搜集操作发起。

日志搜集交互单元134，是完成动态日志搜集的模块，接收运维管理系统3发出的日志搜集指令并广播到业务链1上的所有验证节点，接收其他验证节点传输的日志并放在固定的日志路径./logs/智能合约ID/交易下。

业务合约共识及执行模块14，是业务链业务交易请求处理的核心工作模块，负责对业务系统4发起的交易请求进行合法性校验、根据日志级别调整请求对设定交易进行详细日志记录，业务合约共识及执行模块14具体包含有：交易校验单元141、交易查询单元142、交易共识单元143、系统通知接收单元144。

交易校验单元141，是对交易请求中的参数进行校验和交易共识预处理的模块，负责校验交易请求参数及来源等信息，将交易请求区块的hash，将区块共识消息保存到本地磁盘中，将区块序号加1，将区块共识消息广播到业务链1中所有验证节点2中。

交易查询单元142，是完成查询类交易请求的交易处理模块，负责根据交易请求返回当前业务智能合约中的最新区块信息给业务系统3，数据查询直接从本地账本中获取，无需共识。

交易共识单元143，是完成更新类业务交易共识的核心模块，应用拜占庭共识算法对交易进行三段式共识处理，第一阶段为pre-prepare共识，第二阶段为prepare共识，第三阶段为commit共识，三个阶段为顺序执行，当前一阶段累计收到2f+1个其他交易共识节点的一致确认消息后当前阶段的共识完成并进入下一阶段，三个阶段的共识全部完成后代表该交易请求合法，按业务智能合约逻辑处理后的数据写入区块进行持久化，在处理过程中根据内存中的dynamicLog对应的交易名称进行日志记录。

指令通知接收单元144，是接收日志级别调整请求的工作流模块，负责接收系统合约共识及执行模块13发送的日志级别调整请求，将最新的动态日志配置信息加载到内存中，当前业务合约共识及执行模块根据最新的交易日志级别调整交易日志记录输出。

由上述描述可知，本申请提供的基于区块链的根因定位方法及装置，能够提高交易日志搜集的效率，进而能够提高异常交易根因定位的效率，保证交易过程的可靠性；可以在区块链网络正常运行过程中调整特定交易的日志级别，按照交易级别输出特定日志并进行归集，验证节点之间的协商操作简单、透明且高效，能够快速输出协助用户定位并分析异常交易的交易跟踪日志，快速解决问题。

从硬件层面来说，为了提高交易日志搜集的效率，进而提高异常交易根因定位的效率，本申请提供一种用于实现所述基于区块链的根因定位方法中的全部或部分内容的电子设备的实施例所述电子设备具体包含有如下内容：

处理器(processor)、存储器(memory)、通信接口(Communications Interface)和总线；其中，所述处理器、存储器、通信接口通过所述总线完成相互间的通信；所述通信接口用于实现所述基于区块链的验证节点以及用户终端等相关设备之间的信息传输；该电子设备可以是台式计算机、平板电脑及移动终端等，本实施例不限于此。在本实施例中，该电子设备可以参照实施例用于实现所述基于区块链的根因定位方法的实施例及用于实现所述基于区块链的验证节点的实施例进行实施，其内容被合并于此，重复之处不再赘述。

图7为本申请实施例的电子设备9600的系统构成的示意框图。如图7所示，该电子设备9600可以包括中央处理器9100和存储器9140；存储器9140耦合到中央处理器9100。值得注意的是，该图7是示例性的；还可以使用其他类型的结构，来补充或代替该结构，以实现电信功能或其他功能。

在本申请一个或多个实施例中，基于区块链的根因定位功能可以被集成到中央处理器9100中。其中，中央处理器9100可以被配置为进行如下控制：

步骤101：接收目标异常交易的交易重现请求，将该交易重现请求广播至区块链的各个验证节点，以使每个验证节点分别根据各自对应的动态日志配置文件和所述交易重现请求，执行所述目标异常交易并生成该目标异常交易对应的动态日志文件。

步骤102：若接收到日志搜集请求，则根据该日志搜集请求获得各个验证节点的动态日志文件，以根据各个验证节点的动态日志文件完成所述目标异常交易的根因定位。

从上述描述可知，本申请的实施例提供的电子设备，能够提高交易日志搜集的效率，进而提高异常交易根因定位的效率。

在另一个实施方式中，基于区块链的验证节点可以与中央处理器9100分开配置，例如可以将基于区块链的验证节点配置为与中央处理器9100连接的芯片，通过中央处理器的控制来实现基于区块链的根因定位功能。

如图7所示，该电子设备9600还可以包括：通信模块9110、输入单元9120、音频处理器9130、显示器9160、电源9170。值得注意的是，电子设备9600也并不是必须要包括图7中所示的所有部件；此外，电子设备9600还可以包括图7中没有示出的部件，可以参考现有技术。

如图7所示，中央处理器9100有时也称为控制器或操作控件，可以包括微处理器或其他处理器装置和/或逻辑装置，该中央处理器9100接收输入并控制电子设备9600的各个部件的操作。

其中，存储器9140，例如可以是缓存器、闪存、硬驱、可移动介质、易失性存储器、非易失性存储器或其它合适装置中的一种或更多种。可储存上述与失败有关的信息，此外还可存储执行有关信息的程序。并且中央处理器9100可执行该存储器9140存储的该程序，以实现信息存储或处理等。

输入单元9120向中央处理器9100提供输入。该输入单元9120例如为按键或触摸输入装置。电源9170用于向电子设备9600提供电力。显示器9160用于进行图像和文字等显示对象的显示。该显示器例如可为LCD显示器，但并不限于此。

该存储器9140可以是固态存储器，例如，只读存储器(ROM)、随机存取存储器(RAM)、SIM卡等。还可以是这样的存储器，其即使在断电时也保存信息，可被选择性地擦除且设有更多数据，该存储器的示例有时被称为EPROM等。存储器9140还可以是某种其它类型的装置。存储器9140包括缓冲存储器9141(有时被称为缓冲器)。存储器9140可以包括应用/功能存储部9142，该应用/功能存储部9142用于存储应用程序和功能程序或用于通过中央处理器9100执行电子设备9600的操作的流程。

存储器9140还可以包括数据存储部9143，该数据存储部9143用于存储数据，例如联系人、数字数据、图片、声音和/或任何其他由电子设备使用的数据。存储器9140的驱动程序存储部9144可以包括电子设备的用于通信功能和/或用于执行电子设备的其他功能(如消息传送应用、通讯录应用等)的各种驱动程序。

通信模块9110即为经由天线9111发送和接收信号的发送机/接收机9110。通信模块(发送机/接收机)9110耦合到中央处理器9100，以提供输入信号和接收输出信号，这可以和常规移动通信终端的情况相同。

基于不同的通信技术，在同一电子设备中，可以设置有多个通信模块9110，如蜂窝网络模块、蓝牙模块和/或无线局域网模块等。通信模块(发送机/接收机)9110还经由音频处理器9130耦合到扬声器9131和麦克风9132，以经由扬声器9131提供音频输出，并接收来自麦克风9132的音频输入，从而实现通常的电信功能。音频处理器9130可以包括任何合适的缓冲器、解码器、放大器等。另外，音频处理器9130还耦合到中央处理器9100，从而使得可以通过麦克风9132能够在本机上录音，且使得可以通过扬声器9131来播放本机上存储的声音。

上述描述可知，本申请的实施例提供的电子设备，能够提高交易日志搜集的效率，进而提高异常交易根因定位的效率。

本申请的实施例还提供能够实现上述实施例中的基于区块链的根因定位方法中全部步骤的一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，该计算机程序被处理器执行时实现上述实施例中的基于区块链的根因定位方法的全部步骤，例如，所述处理器执行所述计算机程序时实现下述步骤：

步骤101：接收目标异常交易的交易重现请求，将该交易重现请求广播至区块链的各个验证节点，以使每个验证节点分别根据各自对应的动态日志配置文件和所述交易重现请求，执行所述目标异常交易并生成该目标异常交易对应的动态日志文件。

步骤102：若接收到日志搜集请求，则根据该日志搜集请求获得各个验证节点的动态日志文件，以根据各个验证节点的动态日志文件完成所述目标异常交易的根因定位。

从上述描述可知，本申请实施例提供的计算机可读存储介质，能够提高交易日志搜集的效率，进而提高异常交易根因定位的效率。

本申请中上述方法的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。相关之处参见方法实施例的部分说明即可。

本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本申请是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

本申请中应用了具体实施例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本申请的限制。

Claims (10)

1.一种基于区块链的根因定位方法，其特征在于，包括：

接收目标异常交易的交易重现请求，将该交易重现请求广播至区块链的各个验证节点，以使每个验证节点分别根据各自对应的动态日志配置文件和所述交易重现请求，执行所述目标异常交易并生成该目标异常交易对应的动态日志文件；

若接收到日志搜集请求，则根据该日志搜集请求获得各个验证节点的动态日志文件，以根据各个验证节点的动态日志文件完成所述目标异常交易的根因定位。

2.根据权利要求1所述的基于区块链的根因定位方法，其特征在于，在所述接收目标异常交易的交易重现请求之前，还包括：

接收日志级别调整请求；

将所述日志级别调整请求广播至各个验证节点进行共识处理，以使每个验证节点根据共识处理成功后的日志级别调整请求中的动态日志配置信息，更新该验证节点对应的动态日志配置文件。

3.根据权利要求1所述的基于区块链的根因定位方法，其特征在于，所述每个验证节点分别根据各自对应的动态日志配置文件和所述交易重现请求，执行所述目标异常交易并生成该目标异常交易对应的动态日志文件，包括：

每个验证节点均从其对应的动态日志配置文件中，获得与所述目标异常交易对应的动态日志配置信息；根据所述动态日志配置信息，确定所述目标异常交易的日志级别；根据所述日志级别和交易重现请求，执行所述目标异常交易并生成该目标异常交易的动态日志文件。

4.根据权利要求3所述的基于区块链的根因定位方法，其特征在于，所述根据所述日志级别和交易重现请求，执行所述目标异常交易并生成该目标异常交易的动态日志文件，包括：

若所述目标异常交易的日志级别为调试级别，则根据所述交易重现请求，执行所述目标异常交易并生成该目标异常交易的动态日志文件，该动态日志文件包括：用于存储调试级别日志的调试日志文件和用于存储跟踪记录的交易跟踪文件。

5.一种验证节点，其特征在于，包括：

交易重现模块，用于接收目标异常交易的交易重现请求，将该交易重现请求广播至区块链的各个验证节点，以使每个验证节点分别根据各自对应的动态日志配置文件和所述交易重现请求，执行所述目标异常交易并生成该目标异常交易对应的动态日志文件；

根因定位模块，用于若接收到日志搜集请求，则根据该日志搜集请求获得各个验证节点的动态日志文件，以根据各个验证节点的动态日志文件完成所述目标异常交易的根因定位。

6.根据权利要求5所述的验证节点，其特征在于，还包括：

接收模块，用于接收日志级别调整请求；

日志配置调整模块，用于将所述日志级别调整请求广播至各个验证节点进行共识处理，以使每个验证节点根据共识处理成功后的日志级别调整请求中的动态日志配置信息，更新该验证节点对应的动态日志配置文件。

7.根据权利要求5所述的验证节点，其特征在于，所述交易重现模块，包括：

交易重现子模块，用于每个验证节点均从其对应的动态日志配置文件中，获得与所述目标异常交易对应的动态日志配置信息；根据所述动态日志配置信息，确定所述目标异常交易的日志级别；根据所述日志级别和交易重现请求，执行所述目标异常交易并生成该目标异常交易的动态日志文件。

8.一种基于区块链的根因定位系统，其特征在于，包括：

业务系统、运维管理系统和区块链，所述区块链包括：权利要求5至7任一项所述的验证节点；

所述业务系统，用于将目标异常交易的交易重现请求发送至验证节点，并接收验证节点的交易重现请求处理返回信息；

所述运维管理系统，用于将日志级别调整请求和/或日志搜集请求发送至验证节点。

9.一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其特征在于，所述处理器执行所述程序时实现权利要求1至4任一项所述的基于区块链的根因定位方法。

10.一种计算机可读存储介质，其上存储有计算机指令，其特征在于，所述指令被执行时实现权利要求1至4任一项所述的基于区块链的根因定位方法。

Images