CN116662430A - 应用于多系统交互的数据查询方法、装置、设备、介质和产品 - Google Patents

Abstract

本公开提供了一种应用于多系统交互的数据查询方法，可以应用于大数据技术领域。该应用于多系统交互的数据查询方法包括：拦截当前业务系统与对应目标业务系统之间的业务请求进程；根据预设动态配置规则，确定所述业务请求进程对应的请求日志数据；以及通过预设单线程消费规则，存储所述请求日志数据为数据库数据，以实现针对所述数据库数据的查询。本公开还提供了一种应用于多系统交互的数据查询装置、设备、存储介质和程序产品。

Description

应用于多系统交互的数据查询方法、装置、设备、介质和产品

技术领域

本公开涉及大数据技术领域，更具体地涉及一种应用于多系统交互的数据查询方法、装置、设备、介质和产品。

背景技术

随着经济社会的快速的发展，设备之间、应用程序之间、应用程序与网页应用之间等内容交互的场景越发常见，这些交互的场景实际上涉及至少两个应用服务系统之间的功能交互、数据交互等。然而，随着数据交互的大规模扩展，在现有的多系统交互过程中出现的问题往往无法实现快速定位。例如在数据下发过程中，当目标数据从A系统下发到B系统之后经B系统再下发给C系统时，如果下发的数据结果不符合目标预期，则容易出现无法有效快速定位的情况。面对这种情况，通常是需要各个系统(A-B-C)查找各自系统日志来确定，但是由于各个系统的系统日志涉及日志内容多而杂，造成问题定位往往比较困难。

发明内容

鉴于上述问题至少之一，本公开提供了提高日志数据定位效率的应用于多系统交互的数据查询方法、装置、设备、介质和程序产品。

本公开的一个方面提供了一种应用于多系统交互的数据查询方法，其中，包括：拦截当前业务系统与对应目标业务系统之间的业务请求进程；根据预设动态配置规则，确定所述业务请求进程对应的请求日志数据；以及通过预设单线程消费规则，存储所述请求日志数据为数据库数据，以实现针对所述数据库数据的查询。

根据本公开的实施例，在所述拦截当前业务系统与对应目标业务系统之间的业务请求进程之前，包括：响应于业务处理请求，执行所述当前业务系统的当前业务信息；基于所述当前业务信息，建立所述当前业务系统和所述目标业务系统之间的业务请求进程。

根据本公开的实施例，在所述基于所述当前业务信息，建立所述当前业务系统和所述目标业务系统的业务请求进程中，包括：响应于所述当前业务信息的执行，通过所述当前业务系统向所述目标业务系统发送数据业务请求；通过所述数据业务请求，建立所述目标业务系统和所述当前业务系统之间的所述业务请求进程。

根据本公开的实施例，在所述拦截当前业务系统与对应目标业务系统之间的业务请求进程中，包括：响应于所述业务请求进程，生成对应的请求回执信息；响应于所述请求回执信息，执行针对所述业务请求进程的拦截，获得日志拦截数据。

根据本公开的实施例，在所述根据预设动态配置规则，确定所述业务请求进程对应的请求日志数据中，包括：根据预设动态配置规则，生成所述日志拦截数据对应的日志对象数据；生成所述日志对象数据在对应的阻塞消息队列中的请求日志数据。

根据本公开的实施例，在所述根据预设动态配置规则，生成所述日志拦截数据对应的日志对象数据中，包括：根据预设动态配置规则，确定所述日志拦截数据对应的日志记录数据；解析所述日志记录数据，生成日志参数信息；以及组装所述日志参数信息生成所述日志对象数据。

根据本公开的实施例，在所述通过预设单线程消费规则，存储所述请求日志数据为数据库数据中，包括：基于所述预设单线程消费规则，循环消费所述阻塞消息队列中的请求日志数据；读取所述阻塞消息队列的请求日志数据以存储为数据库数据。

根据本公开的实施例，该应用于多系统交互的数据查询方法还包括：响应于数据查询请求，查询所述数据库数据中与所述数据查询请求对应的日志存储数据。

本公开的另一方面提供了一种应用于多系统交互的数据查询装置，其中，包括进程拦截模块、数据确定模块和数据存储模块。进程拦截模块用于拦截当前业务系统与对应目标业务系统之间的业务请求进程；数据确定模块用于根据预设动态配置规则，确定所述业务请求进程对应的请求日志数据；以及数据存储模块用于通过预设单线程消费规则，存储所述请求日志数据为数据库数据，以实现针对所述数据库数据的查询。

本公开的第三方面提供了一种电子设备，包括：一个或多个处理器和存储器，存储器用于存储一个或多个程序，其中，当所述一个或多个程序被所述一个或多个处理器执行时，使得一个或多个处理器执行上述应用于多系统交互的数据查询方法。

本公开的第四方面还提供了一种计算机可读存储介质，其上存储有可执行指令，该指令被处理器执行时使处理器执行上述应用于多系统交互的数据查询方法。

本公开的第五方面还提供了一种计算机程序产品，包括计算机程序，该计算机程序被处理器执行时实现上述应用于多系统交互的数据查询方法。

附图说明

通过以下参照附图对本公开实施例的描述，本公开的上述内容以及其他目的、特征和优点将更为清楚，在附图中：

图1示意性示出了根据本公开实施例的应用于多系统交互的数据查询方法、装置、设备、介质和程序产品的应用场景图；

图2示意性示出了根据本公开实施例的应用于多系统交互的数据查询方法的流程图；

图3示意性示出了根据本公开实施例的应用于多系统交互的数据查询方法的一场景流程图；

图4示意性示出了根据本公开实施例的应用于多系统交互的数据查询方法的一具体场景流程图；

图5示意性示出了根据本公开实施例的应用于多系统交互的数据查询装置的结构框图；以及

图6示意性示出了根据本公开实施例的适于实现应用于多系统交互的数据查询方法的电子设备的方框图。

具体实施方式

以下，将参照附图来描述本公开的实施例。但是应该理解，这些描述只是示例性的，而并非要限制本公开的范围。在下面的详细描述中，为便于解释，阐述了许多具体的细节以提供对本公开实施例的全面理解。然而，明显地，一个或多个实施例在没有这些具体细节的情况下也可以被实施。此外，在以下说明中，省略了对公知结构和技术的描述，以避免不必要地混淆本公开的概念。

在此使用的术语仅仅是为了描述具体实施例，而并非意在限制本公开。在此使用的术语“包括”、“包含”等表明了所述特征、步骤、操作和/或部件的存在，但是并不排除存在或添加一个或多个其他特征、步骤、操作或部件。

在此使用的所有术语(包括技术和科学术语)具有本领域技术人员通常所理解的含义，除非另外定义。应注意，这里使用的术语应解释为具有与本说明书的上下文相一致的含义，而不应以理想化或过于刻板的方式来解释。

在使用类似于“A、B和C等中至少一个”这样的表述的情况下，一般来说应该按照本领域技术人员通常理解该表述的含义来予以解释(例如，“具有A、B和C中至少一个的系统”应包括但不限于单独具有A、单独具有B、单独具有C、具有A和B、具有A和C、具有B和C、和/或具有A、B、C的系统等)。

现有系统功能交互过程中，存在多系统间交互定位难的问题，主要在于各个业务系统的数据平台存在相互独立的可能，使得在业务处理进程中，存在在后的业务系统无法有效获取在先业务系统的日志数据的情况，这就使得当其中任一业务处理进程中出现问题之后，需要对业务系统全局执行排查，极大地耗费人力和时间。

为了解决上述多系统间交互存在问题定位难的问题，现有方案主要通过硬编码的方式记录系统日志，利用对系统日志的查询检索实现问题定位。但是这种硬编码的传统方案往往具有编码工作量大、不易维护且程序扩展性差。且现有方案不能动态调整，无法根据实际情景临时新增和删除需监控的请求。比如新增一个请求调用C系统，就必须编写对应的日志记录代码，直接导致维护成功居高不下。同时硬编码的方式导致系统日志量无法控制，存在日志量大量攀升，占用过多存储空间，资源使用不合理等问题。而且由于自身应用系统与第三方应用系统对接越来越多，越来越频繁，需要配合分析的问题也逐步增长。

鉴于上述问题至少之一，本公开提供了提高日志数据定位效率的应用于多系统交互的数据查询方法、装置、设备、介质和程序产品。借此，能够实现系统间调用链路日志的快速查询分析，实现日志数据高效定位，提供一种多系统间交互日志记录和动态管理方案。

需要说明的是，本公开实施例的应用于多系统交互的数据查询方法和装置可以应用于大数据技术领域和信息安全技术领域，也可以应用于除大数据技术领域和信息安全技术领域之外的任意领域，如金融服务领域，本公开实施例的应用于多系统交互的数据查询方法和装置的应用领域不作具体限定。

此外，在本公开的技术方案中，所涉及的用户个人信息的收集、存储、使用、加工、传输、提供、公开和应用等处理，均符合相关法律法规的规定，采取了必要保密措施，且不违背公序良俗。在本公开的技术方案中，在获取或采集用户个人信息之前，均获取了用户的授权或同意。

本公开的实施例提供了一种应用于多系统交互的数据查询方法，包括：拦截当前业务系统与对应目标业务系统之间的业务请求进程；根据预设动态配置规则，确定所述业务请求进程对应的请求日志数据；以及通过预设单线程消费规则，存储所述请求日志数据为数据库数据，以实现针对所述数据库数据的查询。

图1示意性示出了根据本公开实施例的应用于多系统交互的数据查询方法、装置、设备、介质和程序产品的应用场景图。

如图1所示，根据该实施例的应用场景100可以包括终端设备101、102、103、网络104和服务器105。网络104用以在终端设备101、102、103和服务器105之间提供通信链路的介质。网络104可以包括各种连接类型，例如有线、无线通信链路或者光纤电缆等等。

用户可以使用终端设备101、102、103通过网络104与服务器105交互，以接收或发送消息等。终端设备101、102、103上可以安装有各种通讯客户端应用，例如购物类应用、网页浏览器应用、搜索类应用、即时通信工具、邮箱客户端、社交平台软件等(仅为示例)。

终端设备101、102、103可以是具有显示屏并且支持网页浏览的各种电子设备，包括但不限于智能手机、平板电脑、膝上型便携计算机和台式计算机等等。

服务器105可以是提供各种服务的服务器，例如对用户利用终端设备101、102、103所浏览的网站提供支持的后台管理服务器(仅为示例)。后台管理服务器可以对接收到的用户请求等数据进行分析等处理，并将处理结果(例如根据用户请求获取或生成的网页、信息、或数据等)反馈给终端设备。

需要说明的是，本公开实施例所提供的应用于多系统交互的数据查询方法一般可以由服务器105执行。相应地，本公开实施例所提供的应用于多系统交互的数据查询装置一般可以设置于服务器105中。本公开实施例所提供的应用于多系统交互的数据查询方法也可以由不同于服务器105且能够与终端设备101、102、103和/或服务器105通信的服务器或服务器集群执行。相应地，本公开实施例所提供的应用于多系统交互的数据查询装置也可以设置于不同于服务器105且能够与终端设备101、102、103和/或服务器105通信的服务器或服务器集群中。

应该理解，图1中的终端设备、网络和服务器的数目仅仅是示意性的。根据实现需要，可以具有任意数目的终端设备、网络和服务器。

以下将基于图1描述的场景，通过图2～图5对公开实施例的应用于多系统交互的数据查询方法进行详细描述。

图2示意性示出了根据本公开实施例的应用于多系统交互的数据查询方法的流程图；图3示意性示出了根据本公开实施例的应用于多系统交互的数据查询方法的一场景流程图；图4示意性示出了根据本公开实施例的应用于多系统交互的数据查询方法的一具体场景流程图。

如图2所示，该实施例的应用于多系统交互的数据查询方法包括操作S201～操作S203。

在操作S201，拦截当前业务系统与对应目标业务系统之间的业务请求进程；

在操作S202，根据预设动态配置规则，确定所述业务请求进程对应的请求日志数据；以及

在操作S203，通过预设单线程消费规则，存储所述请求日志数据为数据库数据，以实现针对所述数据库数据的查询。

如图3所示，多系统主要是指相互之间可以存在功能交互实现业务处理的多个业务系统，通常用户可以通过终端设备(如手机或者柜机等)实现对当前业务系统的访问，并通过该当前业务系统与目标业务系统之间的功能交互实现最终的业务处理。其中，当前业务系统为该终端设备所匹配的业务系统。

目标业务系统为与当前业务系统具有功能交互关系或者可以随时或有条件的建立交互关系，以确保最终实现业务处理全流程的业务系统。例如，当前业务系统可以是银行的终端服务系统，而目标业务系统可以是与该银行终端服务系统之间具有数据交互访问功能的即时聊天工具的数据服务系统或者在线购物工具的数据服务系统。

业务请求进程为实现当前业务系统和目标业务系统之间的功能交互而建立的数据处理请求进程，具体可以基于http请求协议实现请求进程，主要应用于当前业务系统至第一业务系统之间的业务处理。对该业务请求进程执行拦截，即可以对当前业务系统和目标业务系统之间的交互日志数据实现拦截获取。具体可以采用诸如字节码增强技术等实现对业务请求进程的拦截，同时可以保证对业务请求进程的正常处理产生最小的负面影响，或者不会产生负面影响。

预设动态配置规则为对拦截所获取的当前业务系统和目标业务系统之间的交互日志数据执行动态配置的设定规则，其主要的作用在于对交互日志数据执行特定需求的筛选，该特定需求需要根据具体的数据定位场景进行确定。具体地，该预设动态配置规则可以利用Apollo动态变量管理技术实现动态实时的修改特定需求的请求记录i清单，而无需安装其他版本应用，可高效实现交互记录的动态管理。

基于上述预设动态配置规则可以实现对交互日志数据的动态配置处理，进而可以确定所拦截的业务请求进程中对应的请求日志数据。该请求日志数据可以是对经动态配置处理之后的交互日志数据进行数据预处理之后的生成数据，从而更加有利于后续的数据定位。

预设单线程消费规则可以是对请求日志数据执行单线程消费处理的进程规则，主要用于对该请求日志数据的访问获取，以实现将请求日志数据的有效存储，从而进一步利于数据查询定位的实现。其中，将请求日志数据执行对应数据库的存储之后，可以在该数据库中生成对应的数据库数据，该数据库数据为根据特殊需求的应用场景执行数据定位的基础数据。

因此，本公开实施例的上述应用于多系统交互的数据查询方法，提供了一种多系统间交互日志记录和动态管理方案，可通过如字节码增强技术等技术实现请求进程的高效数据拦截，统一记录多系统间的交互日志数据，之后可以通过动态配置管理，实现可动态调整所需记录的接口清单，借此实现最终的数据查询，从而提高数据定位的效率。

如图2.图4所示，根据本公开的实施例，在操作S201拦截当前业务系统与对应目标业务系统之间的业务请求进程之前，包括：响应于业务处理请求，执行所述当前业务系统的当前业务信息；基于所述当前业务信息，建立所述当前业务系统和所述目标业务系统之间的业务请求进程。

业务处理请求可以是用户终端设备响应于用户的操作根据当前业务系统的业务处理规则所产生的业务处理相关的请求指令。当前业务信息可以是为实现用户在当前业务系统中的相应业务处理内容的数据信息，例如当前业务信息可以包括账户名、账户ID、业务名、业务类型、业务格式、业务执行内容等。通过当前业务系统执行该当前业务信息，能够建立所述当前业务系统和所述目标业务系统之间的业务请求进程。

如图2-图4所示，根据本公开的实施例，在基于所述当前业务信息，建立所述当前业务系统和所述目标业务系统的业务请求进程中，包括：响应于所述当前业务信息的执行，通过所述当前业务系统向所述目标业务系统发送数据业务请求；通过所述数据业务请求，建立所述目标业务系统和所述当前业务系统之间的所述业务请求进程。

通过执行当前业务信息，可以在当前业务系统中产生向目标业务系统发送的数据业务请求。该数据业务请求可以为当前业务系统和目标业务系统二者之间建立交互进程的请求信息，例如该数据业务请求可以包括相应的账户名、账户ID、业务名、业务类型、业务格式等，还可以同时包括当前业务执行日志、业务处理状态以及请求交互的指令信息等。通过该数据业务请求可以建立当前业务系统和目标业务系统之间的业务请求进程。

如图3所示，当前业务系统310可以向目标第一业务系统320发送数据业务请求，使得目标第一业务系统320响应于该数据业务请求，向当前业务系统反馈进程建立的回执消息，从而实现当前业务系统310和目标第一业务系统320之间的业务请求进程S1的建立。其中，第一业务系统320还可以作为当前业务系统实现与第二业务系统330之间的业务请求进程S2的建立，相应地，也可以实现当前业务系统310与第二业务系统330之间的业务请求进程S3的建立。

需要说明的是，上述如图3所示的当前业务系统也可以是第一业务系统或第二业务系统，换言之，该多系统交互的场景可以同时具有两个或两个以上的业务系统，主要基于用户不同位置的操作以作区分，在此不作赘述。

如图2-图4所示，根据本公开的实施例，在操作S201拦截当前业务系统与对应目标业务系统之间的业务请求进程中，包括：响应于所述业务请求进程，生成对应的请求回执信息；响应于所述请求回执信息，执行针对所述业务请求进程的拦截，获得日志拦截数据。

如图3所示，对于业务请求进程S1，其在建立之前需要第一业务系统320向当前业务系统310发送请求回执，以通知当前业务系统310收到对应的数据业务请求，并能够实现所述目标业务系统和所述当前业务系统之间的所述业务请求进程的建立。其中，该请求回执即请求回执信息，该请求回执信息为用于作为两个业务系统之间建立握手关系成立业务请求进程的响应信息。

其中，该日志拦截数据可以是前述所提及的交互日志数据，主要可以包括两个业务系统之间的业务交易相关数据和请求进程建立数据等日志数据，例如图3和图4所示进程S1中的所有Http请求数据。

对于业务请求进程S1而言，通过采用诸如字节码增强技术，例如通过使用spring算法的aop切面拦截方案，将当前业务系统的所有外部请求都通过rest-template发起，进一步使用@After-Returning手段返回切面，对rest-template的GET、POST等内容进行切面拦截，并在实现template拦截后，进入操作S301-S304。其中，在拦截进程之前，还可以通过获取请求外部系统的请求地址与预设动态配置规则中设定的所需记录的请求清单做匹配，判断是否需要对当前请求进程进行拦截处理。如果不需要则继续执行原有主流程，如果需要则进行相应的日志拦截操作。

如图3和图4所示，虚线箭头可以为字节码增强处理的业务逻辑，此技术不会影响主进程(例如进程S1-进程S2的进程)的业务处理。其中，进程S1中的所有Http请求数据都可以被拦截。

如图2.图4所示，根据本公开的实施例，在操作S202根据预设动态配置规则，确定所述业务请求进程对应的请求日志数据中，包括：根据预设动态配置规则，生成所述日志拦截数据对应的日志对象数据；生成所述日志对象数据在对应的阻塞消息队列中的请求日志数据。

如图3所示操作S301-S304和如图4所示操作S401-S404，根据预设动态配置规则可以判断拦截得到的日志拦截数据是否需要做请求日志记录，如果不需要则可以继续进行主进程的业务处理，如果需要作请求日志记录，则可以对日志拦截数据进行数据处理执行，生成日志对象数据。

其中，预设动态配置规则可以定义在多系统交互场景下需记录的日志数据的请求清单，具体可以通过动态配置管理实现不同场景下的清单调整，并基于该请求清单实现对该预设动态配置规则的生成。其中，该基于动态配置实现的请求清单一般可以记录用户所需的多系统间交互日志，而排除其他非交互的日志数据和非必要系统间的日志数据，从而可以节省存储空间，减少系统开销和运行压力。例如，对于当前业务系统310、第一业务系统320、第二业务系统330而言，可以只配置记录当前业务系统310的交互日志，而避免第一业务系统320和第二业务系统330交互日志。

日志对象数据为日志拦截数据经数据处理之后的生成数据，该数据处理的过程主要是针对日志拦截数据执行相应的数据解析和再组装等。阻塞消息队列可以是非kafka中间件消息队列形式的消息处理队列，其具有数据丢失容忍度更高，交易复杂度更加简易且功能简单更易于执行的优势，能够快速实现对日志对象数据的处理，例如阻塞消息队列可以是Blocking Queue消息队列。请求日志数据是日志对象数据经过阻塞消息队列依序排布处理之后生成的日志数据，其具有队列排布的特征。

因此，利用基于上述请求清单的预设动态配置规则的动态变量管理技术可以实现动态实时的修改需记录的请求清单，而无需安装版本即可以实现交互记录的动态管理，从而可以使得最后排布在阻塞消息队列中的请求日志数据可以为合理、有效且必要的交互记录日志数据。

如图2.图4所示，根据本公开的实施例，在根据预设动态配置规则，生成所述日志拦截数据对应的日志对象数据中，包括：根据预设动态配置规则，确定所述日志拦截数据对应的日志记录数据；解析所述日志记录数据，生成日志参数信息；以及组装所述日志参数信息生成所述日志对象数据。

如图3所示操作S301-S304和如图4所示操作S401-S404，如果日志拦截数据中的当前请求数据位于符合预设动态配置规则的所需记录日志请求清单内，则开始请求日志记录流程，获取请求数据地址、处理方式、输入参数、开始时间、返回结果、traceID、结束时间和输出参数等日志数据，构成作为日志记录数据的返回信息。

进一步地，可以根据例如java反射解析技术等对上述返回信息的日志记录数据执行解析，以获取可以构成日志参数信息的数据内容，具体可以包括接口地址、调用方、请求参数、返回信息、traceID等。

将上述日志参数信息中所涉及的诸如接口地址、调用方、请求参数、返回信息、traceID等数据信息组装，可以构成相应的日志对象数据。其中，对于主流进程S1、S2、S3并不会产生影响，这些进程都可以正常的同时执行相应业务处理内容。

相应地，若将第一业务系统320作为当前业务系统，第二业务系统330作为第一业务系统320的目标业务系统，则针对第一业务系统320和第二业务系统330之间的进程S2执行拦截，依然可以通过上述Apollo拦截技术实现，相应拦截处理过程可以参照上述针对图3和图4的描述，在此不作赘述。

如图2-图4所示，根据本公开的实施例，在操作S203通过预设单线程消费规则，存储所述请求日志数据为数据库数据中，包括：基于所述预设单线程消费规则，循环消费所述阻塞消息队列中的请求日志数据；读取所述阻塞消息队列的请求日志数据以存储为数据库数据。

进一步地，如图3所示操作S303-S304和图4所示操作S405-S407，将此类数据信息最终放入消息队列，可以通过单线程消费实现将消费队列中的消息数据进行调用，并存储到数据库DB，最终实现请求日志的记录。

其中，预设单线程消费规则为基于单线程消费者技术所构成的数据执行规则，能够在被执行时用于实现针对阻塞消息队列中的请求日志数据的消费处理。例如，单线程开启消费者，可以循环取出消息队列中的请求日志数据的消息数据，逐个将数据存储到数据库DB中。在存储到数据DB之中之前，可以判断阻塞消息队列中是否存在数据，若队列数据不存在(队列为空)，则可以将单线程消费进程休眠1min等特定周期之后继续重新循环对阻塞消息队列执行访问。借助于该预设单线程消费规则可以极大地简化数据存储的调用过程，实现循环性的数据处理操作，确保自动化的数据执行过程。

具体地，关于上述循环执行单线程消费的过程主要说明如下：如图4所示，在操作S405中，开启单线程，循环消费放入Blocking Queue阻塞消息队列的请求日志数据的消息数据；在操作S406中，判断Blocking Queue消息队列中是否存在数据排布，存在数据排布则继续执行操作S407完成数据消费，不存在则继续回到操作S405，并基于特定周期(如1min)继续执行队列消息数据的调用。在操作S407中，将读取的Blocking Queue消息队列的消息转存至数据库DB，同时可以将记录信息存储到mysql中构成交互日志记录表，该交互日志记录表的数据库数据主要可以包括调用系统、应用id、traceID、请求地址、请求方式、输入参数、返回参数、调用结果和调用时间等。

因此，相对于目前大部分调用日志记录主要通过硬编码的方式在每个调用位置进行保存的传统方案，可以将多系统的交互日志存储到数据库，从而借助于该数据库的数据库数据精准实现调用日志的快速查询，而且还可以根据调用链路快速确认日志数据问题，可以同时提高数据查询定位的快速性、精准性，从而极大节省查询精力的查询成本，快速定位数据。

如图2-图4所示，根据本公开的实施例，该应用于多系统交互的数据查询方法还包括：响应于数据查询请求，查询所述数据库数据中与所述数据查询请求对应的日志存储数据。

数据查询请求可以是响应于用户在终端设备上进行的特定数据查询功能的操作而生成的请求指令，用于调取数据查询定位的功能。通过该数据查询请求的执行，可以实现对数据库数据中的日志存储数据的定位查询，确定数据位置，提供数据反馈。其中，该数据查询请求可以自带相应的数据标识，例如traceID，通过该数据标识与数据库数据中的相应ID数据执行匹配操作，在二者相互匹配的情况下，可以将与数据标识相匹配的日志存储数据作为查询结果输出。

其中，通过traceID可快速定位当前请求链路所有服务请求，由于请求时按顺序存储至队列，消费时也是按顺序存储，日志可按时间查看整个调用链路情况。借此，当多系统间交互出现问题时，首先可以判断当前接口是否已经配置所需记录请求清单中，如果已经配置记录日志，则可以根据关键字查询数据库，快速定位原因。

此外，动态调整作用：如果当前接口未记录日志，则可以通过调整动态变量，将接口配置到所需记录请求清单，此时重新发起请求，则会记录到日志表；如果部分接口访问量突增导致，数据库存储会存在压力，或导致BlockingQueue阻塞，则可以通预设动态配置规则对所需记录请求清单进行调整，甚至将当前接口的记录日志清单直接移除，从而可以极大地减轻环境服务压力。

本公开实施例的上述应用于多系统交互的数据查询方法，提供了一种多系统间交互日志记录和动态管理方案，可快速动态调整需要记录的调用日志，并且能够根据实际场景需求快速查询数据库获取调用链路日志，无需检索大量日志文件，提升问题分析效率；而且，通过利用如java字节码增强技术等拦截技术可做到一次编码全局生效，从而可以较好地提升系统的可维护性和可扩展性，配合动态变量可动态调整需监控记录的调用日志范围，实现监控范围可控性，达到记录范围最小化，资源利用最大化。借此，可以实现针对数据查询的高效定位，同时极大降低了人力工作量，减小查询成本。

基于上述应用于多系统交互的数据查询方法，本公开还提供了一种应用于多系统交互的数据查询装置。以下将结合图5对该装置进行详细描述。

图5示意性示出了根据本公开实施例的应用于多系统交互的数据查询装置的结构框图。

如图5所示，该实施例的应用于多系统交互的数据查询装置500包括进程拦截模块510、数据确定模块520和数据存储模块530。

进程拦截模块510用于拦截当前业务系统与对应目标业务系统之间的业务请求进程。在一实施例中，进程拦截模块510可以用于执行前文描述的操作S201，在此不再赘述。

数据确定模块520用于根据预设动态配置规则，确定所述业务请求进程对应的请求日志数据。在一实施例中，数据确定模块520可以用于执行前文描述的操作S202，在此不再赘述。

数据存储模块530用于通过预设单线程消费规则，存储所述请求日志数据为数据库数据，以实现针对所述数据库数据的查询。在一实施例中，数据存储模块530可以用于执行前文描述的操作S203，在此不再赘述。

根据本公开的实施例，进程拦截模块510、数据确定模块520和数据存储模块530中的任意多个模块可以合并在一个模块中实现，或者其中的任意一个模块可以被拆分成多个模块。或者，这些模块中的一个或多个模块的至少部分功能可以与其他模块的至少部分功能相结合，并在一个模块中实现。根据本公开的实施例，进程拦截模块510、数据确定模块520和数据存储模块530中的至少一个可以至少被部分地实现为硬件电路，例如现场可编程门阵列(FPGA)、可编程逻辑阵列(PLA)、片上系统、基板上的系统、封装上的系统、专用集成电路(ASIC)，或可以通过对电路进行集成或封装的任何其他的合理方式等硬件或固件来实现，或以软件、硬件以及固件三种实现方式中任意一种或以其中任意几种的适当组合来实现。或者，进程拦截模块510、数据确定模块520和数据存储模块530中的至少一个可以至少被部分地实现为计算机程序模块，当该计算机程序模块被运行时，可以执行相应的功能。

图6示意性示出了根据本公开实施例的适于实现应用于多系统交互的数据查询方法的电子设备的方框图。

如图6所示，根据本公开实施例的电子设备600包括处理器601，其可以根据存储在只读存储器(ROM)602中的程序或者从存储部分608加载到随机访问存储器(RAM)603中的程序而执行各种适当的动作和处理。处理器601例如可以包括通用微处理器(例如CPU)、指令集处理器和/或相关芯片组和/或专用微处理器(例如，专用集成电路(ASIC))等等。处理器601还可以包括用于缓存用途的板载存储器。处理器601可以包括用于执行根据本公开实施例的方法流程的不同动作的单一处理单元或者是多个处理单元。

在RAM 603中，存储有电子设备600操作所需的各种程序和数据。处理器601、ROM602以及RAM 603通过总线604彼此相连。处理器601通过执行ROM 602和/或RAM 603中的程序来执行根据本公开实施例的方法流程的各种操作。需要注意，所述程序也可以存储在除ROM 602和RAM 603以外的一个或多个存储器中。处理器601也可以通过执行存储在所述一个或多个存储器中的程序来执行根据本公开实施例的方法流程的各种操作。

根据本公开的实施例，电子设备600还可以包括输入/输出(I/O)接口605，输入/输出(I/O)接口605也连接至总线604。电子设备600还可以包括连接至I/O接口605的以下部件中的一项或多项：包括键盘、鼠标等的输入部分606；包括诸如阴极射线管(CRT)、液晶显示器(LCD)等以及扬声器等的输出部分607；包括硬盘等的存储部分608；以及包括诸如LAN卡、调制解调器等的网络接口卡的通信部分609。通信部分609经由诸如因特网的网络执行通信处理。驱动器610也根据需要连接至I/O接口605。可拆卸介质611，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器610上，以便于从其上读出的计算机程序根据需要被安装入存储部分608。

本公开还提供了一种计算机可读存储介质，该计算机可读存储介质可以是上述实施例中描述的设备/装置/系统中所包含的；也可以是单独存在，而未装配入该设备/装置/系统中。上述计算机可读存储介质承载有一个或者多个程序，当上述一个或者多个程序被执行时，实现根据本公开实施例的方法。

根据本公开的实施例，计算机可读存储介质可以是非易失性的计算机可读存储介质，例如可以包括但不限于：便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本公开中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。例如，根据本公开的实施例，计算机可读存储介质可以包括上文描述的ROM 602和/或RAM 603和/或ROM 602和RAM 603以外的一个或多个存储器。

本公开的实施例还包括一种计算机程序产品，其包括计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。当计算机程序产品在计算机系统中运行时，该程序代码用于使计算机系统实现本公开实施例所提供的方法。

在该计算机程序被处理器601执行时执行本公开实施例的系统/装置中限定的上述功能。根据本公开的实施例，上文描述的系统、装置、模块、单元等可以通过计算机程序模块来实现。

在一种实施例中，该计算机程序可以依托于光存储器件、磁存储器件等有形存储介质。在另一种实施例中，该计算机程序也可以在网络介质上以信号的形式进行传输、分发，并通过通信部分609被下载和安装，和/或从可拆卸介质611被安装。该计算机程序包含的程序代码可以用任何适当的网络介质传输，包括但不限于：无线、有线等等，或者上述的任意合适的组合。

在这样的实施例中，该计算机程序可以通过通信部分609从网络上被下载和安装，和/或从可拆卸介质611被安装。在该计算机程序被处理器601执行时，执行本公开实施例的系统中限定的上述功能。根据本公开的实施例，上文描述的系统、设备、装置、模块、单元等可以通过计算机程序模块来实现。

根据本公开的实施例，可以以一种或多种程序设计语言的任意组合来编写用于执行本公开实施例提供的计算机程序的程序代码，具体地，可以利用高级过程和/或面向对象的编程语言、和/或汇编/机器语言来实施这些计算程序。程序设计语言包括但不限于诸如Java，C++，python，“C”语言或类似的程序设计语言。程序代码可以完全地在用户计算设备上执行、部分地在用户设备上执行、部分在远程计算设备上执行、或者完全在远程计算设备或服务器上执行。在涉及远程计算设备的情形中，远程计算设备可以通过任意种类的网络，包括局域网(LAN)或广域网(WAN)，连接到用户计算设备，或者，可以连接到外部计算设备(例如利用因特网服务提供商来通过因特网连接)。

附图中的流程图和框图，图示了按照本公开各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，上述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图或流程图中的每个方框、以及框图或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

本领域技术人员可以理解，本公开的各个实施例和/或权利要求中记载的特征可以进行多种组合或/或结合，即使这样的组合或结合没有明确记载于本公开中。特别地，在不脱离本公开精神和教导的情况下，本公开的各个实施例和/或权利要求中记载的特征可以进行多种组合和/或结合。所有这些组合和/或结合均落入本公开的范围。

以上对本公开的实施例进行了描述。但是，这些实施例仅仅是为了说明的目的，而并非为了限制本公开的范围。尽管在以上分别描述了各实施例，但是这并不意味着各个实施例中的措施不能有利地结合使用。本公开的范围由所附权利要求及其等同物限定。不脱离本公开的范围，本领域技术人员可以做出多种替代和修改，这些替代和修改都应落在本公开的范围之内。

Claims (12)

1.一种应用于多系统交互的数据查询方法，其中，包括：

拦截当前业务系统与对应目标业务系统之间的业务请求进程；

根据预设动态配置规则，确定所述业务请求进程对应的请求日志数据；以及

通过预设单线程消费规则，存储所述请求日志数据为数据库数据，以实现针对所述数据库数据的查询。

2.根据权利要求1所述的方法，其中，在所述拦截当前业务系统与对应目标业务系统之间的业务请求进程之前，包括：

响应于业务处理请求，执行所述当前业务系统的当前业务信息；

基于所述当前业务信息，建立所述当前业务系统和所述目标业务系统之间的业务请求进程。

3.根据权利要求1所述的方法，其中，在所述基于所述当前业务信息，建立所述当前业务系统和所述目标业务系统的业务请求进程中，包括：

响应于所述当前业务信息的执行，通过所述当前业务系统向所述目标业务系统发送数据业务请求；

通过所述数据业务请求，建立所述目标业务系统和所述当前业务系统之间的所述业务请求进程。

4.根据权利要求1所述的方法，其中，在所述拦截当前业务系统与对应目标业务系统之间的业务请求进程中，包括：

响应于所述业务请求进程，生成对应的请求回执信息；

响应于所述请求回执信息，执行针对所述业务请求进程的拦截，获得日志拦截数据。

5.根据权利要求4所述的方法，其中，在所述根据预设动态配置规则，确定所述业务请求进程对应的请求日志数据中，包括：

根据预设动态配置规则，生成所述日志拦截数据对应的日志对象数据；

生成所述日志对象数据在对应的阻塞消息队列中的请求日志数据。

6.根据权利要求1所述的方法，其中，在所述根据预设动态配置规则，生成所述日志拦截数据对应的日志对象数据中，包括：

根据预设动态配置规则，确定所述日志拦截数据对应的日志记录数据；

解析所述日志记录数据，生成日志参数信息；以及

组装所述日志参数信息生成所述日志对象数据。

7.根据权利要求5所述的方法，其中，在所述通过预设单线程消费规则，存储所述请求日志数据为数据库数据中，包括：

基于所述预设单线程消费规则，循环消费所述阻塞消息队列中的请求日志数据；

读取所述阻塞消息队列的请求日志数据以存储为数据库数据。

8.根据权利要求1所述的方法，其中，还包括：

响应于数据查询请求，查询所述数据库数据中与所述数据查询请求对应的日志存储数据。

9.一种应用于多系统交互的数据查询装置，其中，包括：

进程拦截模块，用于拦截当前业务系统与对应目标业务系统之间的业务请求进程；

数据确定模块，用于根据预设动态配置规则，确定所述业务请求进程对应的请求日志数据；以及

数据存储模块，用于通过预设单线程消费规则，存储所述请求日志数据为数据库数据，以实现针对所述数据库数据的查询。

10.一种电子设备，包括：

一个或多个处理器；

存储装置，用于存储一个或多个程序，

其中，当所述一个或多个程序被所述一个或多个处理器执行时，使得所述一个或多个处理器执行根据权利要求1～8中任一项所述的方法。

11.一种计算机可读存储介质，其上存储有可执行指令，该指令被处理器执行时使处理器执行根据权利要求1～8中任一项所述的方法。

12.一种计算机程序产品，包括计算机程序，所述计算机程序被处理器执行时实现根据权利要求1～8中任一项所述的方法。