一种交易业务处理方法、装置、设备和存储介质

技术领域

本发明涉及金融科技技术领域，尤其是一种交易业务处理方法、装置、设备和存储介质。

背景技术

集中式架构具有的设备数量少、架构设计简单、响应快、数据可靠性和一致性好等优点，使其在系统运维管理、容灾设计和空间用电等方面具有较大优势，从而应用于大型银行核心系统中。但原有集中式架构已不能满足日益增加的业务种类和日渐增大的业务规模的需要，以及响应于国产化进展，银行核心系统由集中式架构全面转向分布式架构势在必行。

在银行核心系统从集中式架构转向分布式框架的背景下，必然会经历一段集中式核心和分布式核心并行运行的过渡态。集中式架构下，交易业务均由主机集中处理，而这种交易业务的处理方式并不能适用于分布式架构，因此，亟需设计一套能够兼容集中式架构和分布式架构时的交易业务处理方案。

发明内容

针对现有技术的上述问题，本文的目的在于，提供一种交易业务处理方法，以解决现有技术中，在集中式架构和分布式架构共存阶段，现有的交易业务处理方法不能兼容两种架构的问题。

为了解决上述技术问题，本文的具体技术方案如下：

第一方面，本文提供一种交易业务处理方法，包括：

获取交易请求的第一请求报文信息，所述第一请求报文信息中包括交易流水号；

根据所述第一请求报文信息和预设的路由策略，计算所述交易请求的路由信息；

将所述路由信息和所述交易流水号存储到数据库中；

根据所述第一请求报文信息或所述路由信息，将所述交易请求派发至集中式应用部署单元或分布式应用部署单元。

第二方面，本文还提供一种交易业务处理装置，包括：

第一获取单元，用于获取交易请求的第一请求报文信息，所述第一请求报文信息中包括交易请求的交易流水号；

计算单元，用于根据所述第一请求报文信息和预设的路由策略，计算所述交易请求的路由信息；

存储单元，用于将所述路由信息和所述交易流水号存储到数据库中；

第一派发单元，用于根据所述第一请求报文信息或所述路由信息，将所述交易请求派发至集中式应用部署单元或分布式应用部署单元。

第三方面，本文还提供一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现如上述技术方案所述的一种交易业务处理方法。

第四方面，本文海提供一种计算机可读存储介质，所述计算机可读存储介质存储有执行计算机程序，所述计算机程序被处理器执行时实现如上述技术方案提供的一种交易业务处理方法。

采用上述技术方案，本文提供的一种交易业务处理方法，根据交易请求的第一请求报文信息和预设的路由策略获得其对应的路由信息，进而根据路由信息将其派发至分布式应用部署单元或根据第一请求报文信息将其派发至集中式应用部署单元，满足了在集中式架构与分布式架构并行运行阶段交易请求业务处理的需求。

为让本文的上述和其他目的、特征和优点能更明显易懂，下文特举较佳实施例，并配合所附图式，作详细说明如下。

附图说明

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

图1示出了本文实施例提供的一种交易业务处理方法的步骤示意图；

图2示出了本文实施例提供的另一种交易业务处理方法的步骤示意图；

图3示出了本文实施例提供的一种交易业务处理装置的结构示意图；

图4示出了本文实施例提供的另一种交易业务处理装置的结构示意图；

图5示出了本文实施例中一种设备的结构示意图。

附图符号说明：

10、第一获取单元；

20、计算单元；

30、存储单元；

40、第一派发单元；

50、第一接收单元；

60、第二获取单元；

70、查询单元；

80、第二派发单元；

90、第二接收单元；

502、计算机设备；

504、处理器；

506、存储器；

508、驱动机构；

510、输入/输出模块；

512、输入设备；

514、输出设备；

516、呈现设备；

518、图形用户接口；

520、网络接口；

522、通信链路；

524、通信总线。

具体实施方式

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

需要说明的是，本文的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本文的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、装置、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

本说明书实施例中，集中式架构是指由一台或多台主计算机组成中心节点，数据的存储、业务的部署和功能的实现均在这个中心节点上，而其他节点仅仅负责数据的录入和输出。集中式架构具有设备数量少、架构设计简单、响应快、数据可靠性和一致性好等优点，因此在系统运维管理，容灾设计，空间用电等方面都具有较大优势，从而广泛应用于传统的银行、电信、交通、医疗等行业。

但现有的集中式架构已不能满足日益增加的业务种类和日渐增大的业务规模的需要，以及响应于国产化进展，银行核心系统由集中式架构全面转向分布式架构势在必行。

所述分布式架构则是指将一个硬件或软件组件分布在不同的网络计算机上，彼此之间仅仅通过消息传递进行通信和协调的系统。分布式架构可以很好的弥补集中式架构上单个节点不可用就会造成全局不可用的问题。

在集中式架构下，交易业务均在应用路由层寻址至主机集中处理。而分布式架构下，每个节点均有能力接受来自外部的请求并进行相应的处理，因此，集中式架构原有的对交易业务的处理方式并不能适用于分布式架构中。为了解决现有的交易业务处理方法，在并行运行阶段无法兼容集中式架构和分布式架构的问题，本文实施例提供了一种交易业务处理方法。

如图1所示，是本文实施例提供的一种交易业务处理方法的步骤示意图，需要说明的是，本说明书提供了如实施例或流程图所述的方法操作步骤，但基于常规或者无创造性的劳动可以包括更多或者更少的操作步骤。实施例中列举的步骤顺序仅仅为众多步骤执行顺序中的一种方式，不代表唯一的执行顺序。在实际中的系统或装置产品执行时，可以按照实施例或者附图所示的方法顺序执行或者并行执行。具体的如图1所示，所述方法可以包括：

S110：获取交易请求的第一请求报文信息，所述第一请求报文信息中包括所述交易请求的交易流水号；

需要说明的是，本说明书实施例中，所述交易请求包括正交易请求和查询请求，所述正交易请求是指银行等金融业务中的正向交易，例如：存取款、转账等；所述查询请求是指诸如对余额进行查询的交易请求。

所述交易流水号是一笔交易在交易路径上的唯一标识。通过交易流水号可以定位到唯一一笔交易；所述交易路径是指交易线在路径上的抽象和凝聚，并不包含明显的业务含义；所述交易线是指用于描述联机业务在请求和应答过程中对各种资源的使用及使用规则，是经过的应用平台和有向路段、交易接口、调用顺序、使用要求等的集合。

本说明书实施例中，报文是指在系统间相互调用时交换与传输的数据单元，即系统一次性要发送的数据块，包括请求报文和响应报文。一笔交易请求由业务发起方发起时的请求数据为请求报文，主机完成处理后的返回的数据则为响应报文。

S120：根据所述第一请求报文信息和预设的路由策略，计算所述交易请求的路由信息；

具体地，不同的交易请求其第一请求报文信息中的数据内容有所不同，且不同的交易请求对应的路由策略也会有所不同，因此计算得到的路由信息相应的也有所不同。优选地，本说明书实施例中，所述预设的路由策略预先存储于基于zookeeper的配置中心中。

在一可行的实施例中，所述交易请求的第一请求报文信息中可包含有该交易请求的业务发起方的客户账号，则其相应的路由策略可以是根据该客户账户判断该笔交易请求为对公服务业务还是对私服务业务，进而根据该笔交易请求的业务类型计算合适的路由信息。当然了，以上仅仅是一种可行的示例，还可以根据第一请求报文信息中其他数据信息或数据信息的组合进行路由信息的计算。

S140：将所述路由信息和所述交易流水号存储到数据库中；

具体地，步骤S140包括：

将所述路由信息和所述交易流水号存储于Redis数据库中。

或，

将所述路由信息和所述交易流水号均存储于Redis数据库和Cassandra数据库中。

Redis数据库是一种是开源的、使用ANSI由C语言编写、遵守BSD协议、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库，并提供多种语言的API。

Redis数据库由于是全内存操作，因此具有良好的读写性能，但又导致其存储的数据量跟机器本身的内存大小有关，如果内存增长过快，需要定期删除数据。Redis数据库本身有key过期策略，包括主动删除(定时删除和定期删除)，Redis数据库会定时和/或定期主动淘汰一批已过去的key；和被动删除(又称惰性删除)，用到的时候才会去检验key是不是已过期，若已过期就删除key，但是还是需要提前预估和节约内存。

如上所述，Redis数据库的容量有限且其存储时间较短，一般情况下仅能保留24小时甚至更短的一段时间，因此，本说明书实施例中，还可以将所述路由信息和所述交易流水号在存储于Redis数据库的前提下在异步存储至Cassandra数据库中。

Cassandra数据库中的数据可保留7天甚至更长时间，可解决容量问题，并且可作为数据备份以及解决可用性问题。

S150：根据所述第一请求报文信息或所述路由信息，将所述交易请求派发至集中式应用部署单元或分布式应用部署单元。

本说明书实施例提供的一种交易业务处理方法，根据交易请求的第一请求报文信息和预设的路由策略计算其对应的路由信息，进而根据路由信息将其派发至分布式应用部署单元，或对于未下移的交易业务直接根据其第一请求报文信息将其派发至集中式应用部署单元，满足了在集中式架构与分布式架构并行运行阶段交易请求业务处理的需求。

本说明书实施例中，步骤S150：根据所述第一请求报文信息或所述路由信息，将所述交易请求派发至集中式应用部署单元或分布式应用部署单元，可进一步地包括：

S151：判断所述第一请求报文信息中是否包括所述交易请求的交易码；

本说明书实施例中，所述交易码是指：可以被配置中心识别的、表征交易接口的唯一标识编码，一般由服务端系统根据一定规则制定发布给请求端系统，以便标识系统间交互的交易接口。

S152：若包括，则根据所述交易码和所述路由策略，计算所述交易请求的路由信息，根据所述路由信息将所述交易请求派发至所述分布式应用部署单元；

若所述第一请求报文信息中包括所述交易码，则表明该交易请求是可由配置中心识别并进行路由信息计算配置；进一步可由分布式应用部署单元进行业务处理的交易请求。即根据所述交易码确定该交易请求需派发至分布式应用部署单元中；进一步地，可根据第一请求报文信息中其他数据信息，例如：客户账号等，以及预先存储的路由策略，将该交易请求派发至分布式应用部署单元中的一个或多个，多个分布式应用部署单元之间可具有一定的业务执行顺序。

S153：若不包括，则根据所述第一请求报文信息将所述交易请求派发至所述集中式应用部署单元。

若所述第一请求报文信息中不包括所述交易码，则表明该交易请求为未下移至分布式应用部署单元的交易请求，即该交易请求在当前两种架构共存阶段仍需要派发至集中式应用部署单元进行业务处理。则对于此类交易请求，则无需由配置中心为其计算路由信息。本说明书实施例提供的交易业务处理方法既能满足在过渡阶段不同交易请求各自适配性的同时，也有利于减轻配置中心路由配置的工作，提高其工作效率。

需要说明的是，本说明书实施例中，步骤S140：将所述路由信息和所述交易流水号存储到数据库中之前，还包括：

S1310：根据所述第一请求报文信息，获取所述交易请求的流水索引项信息；

S1311：根据所述流水索引项信息，获取所述交易请求的交易类型；即所述流水索引项信息是所述第一请求报文信息中表征所述交易请求类型的一段数据；

S1312：根据所述交易类型判断是否存储所述交易请求的所述路由信息。

在一可行的实施例中，具体地，可根据所述流水索引项信息判断所述交易请求的交易类型是否为账户变动类；

若一交易请求为账户变动类的交易请求，则将所述交易请求的路由信息存储到数据库中。若一交易请求为非账户变动类的交易请求，则不存储该交易请求的路由信息。

本说明书实施例中，诸如转账、存取款的正交易请求就属于账户变动类的交易请求；而余额查询类的查询请求则为非账户变动类的交易请求。因此，当一交易请求为正交易请求时，配置中心计算得到其相应的路由信息后需将其路由信息进行存储；而当一交易请求为查询请求时，配置中心计算得到其路由信息后直接将该交易请求派发至路由信息对应的某个或某组分布式应用部署单元，进行相应的业务处理，而无需存储其路由信息。

这是由于余额查询类的查询请求，通常不会产生相应的流水查询业务，也就是说通常不会产生获取查询请求所属应用部署单元的需求。因此，若仍存储查询请求的路由信息，将会造成存数据库储资源的浪费；本申请中，将交易请求按照其流水索引项信息进行划分，分成正交易请求和查询请求两类，并仅对其中的正交易请求的路由信息进行存储，起到了节约存储资源，缓解数据库压力，以及提高数据库数据读写效率的作用。

本说明书实施例中，步骤S140：将所述路由信息和所述交易流水号存储到数据库中之前，还包括：

S1320：判断所述数据库中是否已存储有所述交易请求的路由信息；

若存在，则阻断所述交易请求派发并报错。

若所述数据库已经存储有所述交易请求的路由信息，则表明该交易请求已经被处理，且可能出现了正交易请求与冲正交易请求之间并发登记路由信息的情况，此时未避免重复处理需对交易请求进行阻断。并且，需要说明的是，优选地，对于步骤S1320：判断所述数据库中是否已经存储有所述交易请求的路由信息和步骤S140：将所述路由信息和所述交易流水号存储到数据库中需要在同一个事务内完成，具体地，可通过Redis+Lua解决两者的一致性问题。

如图2所示，本说明书实施例提供的一种交易业务处理方法，还包括：

S160：接收所述集中式应用部署单元或所述分布式应用部署单元反馈的所述交易请求的响应报文，所述响应报文包括所述交易请求的交易流水号。

即当所述集中式应用部署单元或所述分布式应用部署单元对所述交易请求进行了相应的业务处理后，会反馈响应报文，以便系统对该交易请求的进展及结果进行记录，并便于向该交易请求的业务发起方反馈该交易请求的执行情况。

进一步地，本说明书实施例提供的一种交易业务处理方法，还包括：

S210：获取所述交易请求的流水查询请求的第二请求报文信息，所述第二请求报文信息中包括所述交易请求的交易流水号；

本说明书实施例中，所述流水查询请求是指对一笔正交易的执行结果的查询请求，用于确认正交易的执行结果。例如，对于一笔转账X元的正交易请求，其相应的流水查询请求可以是：是否成功转账X元。

所述第二请求报文信息中包括所述交易请求的交易流水号，由于交易流水号能够唯一标识一笔交易请求，因此，根据第二请求报文信息可用于对某一唯一确定的交易请求进行流水查询。

S230：根据所述交易流水号查询所述数据库；

即根据所述交易流水号查询所述数据库中存储的所述交易请求对应的路由信息。

具体地，步骤S230：根据所述交易流水号查询所述数据库，进一步包括：

根据所述交易流水号查询所述Redis数据库；

若所述Redis数据库中存储有所述路由信息，则根据所述路由信息将所述流水查询请求派发至分布式应用部署单元；

若所述Redis数据库中未存储有所述路由信息，则将所述流水查询请求派发至所述集中式应用部署单元。

若所述Redis数据库中存储有所述交易请求的路由信息，则说明所述交易请求为能够被所述部署单元识别、进行路由信息计算配置，并由分布式应用部署单元进行业务处理的交易请求，因此，将所述流水查询请求派发至原来执行该交易请求的分布式应用部署单元中去。若所述Redis数据库中未存储有所述路由信息，则说明该交易请求为未下移至分布式应用部署单元的交易请求，即该交易请求仍由集中式应用部署单元执行业务处理，因此，将所述流水查询请求派发至集中式应用部署单元中。

或

根据所述交易流水号查询所述Redis数据库；

若所述Redis数据库中存储有所述路由信息，则根据所述路由信息将所述流水查询请求派发至分布式应用部署单元；

若所述Redis数据库中未存储有所述路由信息，则查询Cassandra数据库中是否存储有所述路由信息；

若Cassandra数据库中存储有所述路由信息，则根据所述路由信息将所述流水查询请求派发至所述分布式应用部署单元；

若所述Cassandra数据库中未存储有所述路由信息，则将所述流水查询请求派发至集中式应用部署单元。

由于Redis数据库中的路由信息在超过24小时或更短的一段时间就可能会被清除，而Cassandra数据库为了解决容量问题其中还有可能存储有该交易请求的路由信息，因此，当未能在Redis数据库中查询到相应的路由信息时，可进一步查找Cassandra数据库。

若Cassandra数据库确实存储有该交易请求的路由信息，则说明该交易请求为下移至分布式应用部署单元的交易请求，则根据相应的路由信息将所述流水查询请求派发至相应的分布式应用部署单元，以查询该交易请求的执行情况。若Cassandra数据库中未查询到该交易请求的路由信息，则说明该交易请求为未下移至分布式应用部署单元进行业务处理的交易请求，该交易请求仍是由集中式应用部署单元进行业务处理，则根据集中式架构业务处理的特点，直接将该流水查询请求派发至集中式应用部署单元即可获知该交易请求的执行情况。

需要说明的是，本说明书实施例中，步骤S230：根据所述交易流水号查询所述数据库之前，所述方法还包括：

S220：根据所述交易流水号获取所述交易请求的所述流水索引项信息；

由于所述交易流水号能唯一标识一笔交易请求，因此，根据所述交易流水号可获取所述交易请求的流水索引项信息，例如，业务发起方在发起相关的流水查询请求时，便携带有该交易请求的相关流水索引项信息。进而根据所述流水索引项信息判断该交易请求的类型，是否为账户变动类交易请求，即所述交易请求为正交易请求还是查询请求。

根据所述流水索引项信息，判断是否阻断所述流水查询请求并报错。

由于诸如余额查询类的查询请求通常不会产生相应的流水查询业务，也没有将查询请求的路由信息存储在存储器中，因此，若一笔流水查询请求携带的交易流水号对应的交易请求类型为查询请求时，则直接阻断该流水查询请求并报错，能够提高流水查询请求处理效率。

S240：根据查询结果将所述流水查询请求派发至所述集中式应用部署单元或所述分布式应用部署单元。

本说明书实施例提供的一种交易业务处理方法，当获取到一笔流水查询请求时，判断其对应的交易请求的交易类型，若对应的交易请求为查询请求时，直接阻断所述流水查询请求并报错；当对应的交易请求为正交易请求时，进一步在数据库中查询该正交易请求的路由信息；当查询到所述数据库中存储有的该交易请求的路由信息，则将所述流水查询请求派发至路由信息对应的分布式应用部署单元；若所述数据库中未存储有该交易请求的路由信息，则将所述流水查询请求派发至集中式应用部署单元。因此，本说明书实施例提供的交易业务处理方法，对流水查询请求对应的交易请求进行了分类，从而在集中式架构向分部式架构过渡的阶段，即集中式架构与分布式共存的环境下，将流水查询请求路由至执行与之对应的交易请求的所述应用部署单元，满足多种交易业务对流水查询的需求，解决了现有技术中，对一笔交易请求的流水查询请求业务处理方法无法兼容集中式架构与分布式架构的问题。

本说明书实施例提供的一种交易业务处理方法，还包括：

S250：接收所述分布式应用部署单元或所述集中式应用部署单元反馈的所述流水查询请求的响应报文。

需要说明的是，一般情况下(正常时序)，步骤S210是在步骤S160完成之后进行的，即一笔交易请求(具体是正交易请求)已经处理完成后，才进行对该交易请求(正交易请求)的流水查询请求。此时，流水查询请求能够在数据库中查询到交易请求的路由信息，并据此寻址至处理该交易请求的分布式应用部署单元或直接寻址至集中式应用部署单元。

但也有一些情况下(异常时序)，所述正交易请求尚未完成时就发出流水查询请求。此时，由于正交易请求的业务处理尚未完成，则当流水查询请求成功路由至处理该交易请求的应用部署单元(集中式应用部署单元或分布式应用部署单元)，也无法获知该交易业务的处理结果，此时将做报错处理，表明正交易请求业务处理失败。但实际上正交易请求的业务处理发生了一定的延时，当时序正常后，再次发起流水查询请求，则又会反馈正交易请求业务处理成功的响应报文。

优选地，为了减少由于时序异常导致的流水查询请求响应出现谬误的情况，本说明书实施例中，当流水查询请求路由至相应的应用部署单元但还未获取到相应的处理结构时可以采取等待一预设时长(例如，10秒)时间段的方式。在等待该时间段时，反馈给业务发起方一个交易超时的响应报文，当在等待的该时间段结束后，若查询到交易请求已完成业务处理的处理结果，则反馈交易成功的响应报文；查询到交易请求业务处理失败的机构或若仍为查询到处理结果，则反馈交易失败的响应报文。

本说明书实施例提供的一种交易业务处理方法，能够满足在集中式架构向分布式架构过渡的阶段，以及完全过渡至分布式架构的阶段，交易请求业务处理和流水查询请求业务处理的需求，并在正常时序和异常时序均能反馈给业务发起方准确的响应报文。

如图3所示，本说明书实施例还提供一种交易业务处理装置，包括：

第一获取单元10，用于获取交易请求的第一请求报文信息；

计算单元20，用于根据所述第一请求报文信息和预设的路由策略，计算所述交易请求的路由信息；

存储单元30，用于将所述路由信息存储到数据库中；

第一派发单元40，用于根据所述第一请求报文信息和所述路由信息，将所述交易请求派发至集中式应用部署单元或分布式应用部署单元。

如图4所示，所述装置还包括：

第一接收单元50，用于接收所述集中式应用部署单元或所述分布式应用部署单元反馈的所述交易请求的响应报文，所述响应报文包括所述交易请求的交易流水号。

所述装置还可以包括：

第二获取单元60，用于获取所述交易请求的流水查询请求的第二请求报文信息，所述第二请求报文信息中包括所述交易请求的交易流水号；

查询单元70，用于根据所述交易流水号查询所述数据库；

第二派发单元80，用于根据查询结果将所述流水查询请求派发至集中式应用部署单元或分布式应用部署单元。

以及

第二接收单元90，用于接收所述分布式应用部署单元或所述集中式应用部署单元反馈所述流水查询请求的响应报文。

本说明书实施例还提供一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现上述技术方案提供的交易业务处理方法。

如图5所示，为本文实施例提供的一种计算机设备，所述计算机设备502可以包括一个或多个处理器504，诸如一个或多个中央处理单元(CPU)，每个处理单元可以实现一个或多个硬件线程。计算机设备502还可以包括任何存储器506，其用于存储诸如代码、设置、数据等之类的任何种类的信息。非限制性的，比如，存储器506可以包括以下任一项或多种组合：任何类型的RAM，任何类型的ROM，闪存设备，硬盘，光盘等。更一般地，任何存储器都可以使用任何技术来存储信息。进一步地，任何存储器可以提供信息的易失性或非易失性保留。进一步地，任何存储器可以表示计算机设备502的固定或可移除部件。在一种情况下，当处理器504执行被存储在任何存储器或存储器的组合中的相关联的指令时，计算机设备502可以执行相关联指令的任一操作。计算机设备502还包括用于与任何存储器交互的一个或多个驱动机构508，诸如硬盘驱动机构、光盘驱动机构等。

计算机设备502还可以包括输入/输出模块510(I/O)，其用于接收各种输入(经由输入设备512)和用于提供各种输出(经由输出设备514))。一个具体输出机构可以包括呈现设备516和相关联的图形用户接口518(GUI)。在其他实施例中，还可以不包括输入/输出模块510(I/O)、输入设备512以及输出设备514，仅作为网络中的一台计算机设备。计算机设备502还可以包括一个或多个网络接口520，其用于经由一个或多个通信链路522与其他设备交换数据。一个或多个通信总线524将上文所描述的部件耦合在一起。

通信链路522可以以任何方式实现，例如，通过局域网、广域网(例如，因特网)、点对点连接等、或其任何组合。通信链路522可以包括由任何协议或协议组合支配的硬连线链路、无线链路、路由器、网关功能、名称服务器等的任何组合。

对应于图1-图2中的方法，本文实施例还提供了一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，该计算机程序被处理器运行时执行上述方法的步骤。

本文实施例还提供一种计算机可读指令，其中当处理器执行所述指令时，其中的程序使得处理器执行如图1至图2所示的方法。

应理解，在本文的各种实施例中，上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本文实施例的实施过程构成任何限定。

还应理解，在本文实施例中，术语“和/或”仅仅是一种描述关联对象的关联关系，表示可以存在三种关系。例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。另外，本文中字符“/”，一般表示前后关联对象是一种“或”的关系。

本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本文的范围。

所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，上述描述的系统、装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

在本文所提供的几个实施例中，应该理解到，所揭露的系统、装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另外，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口、装置或单元的间接耦合或通信连接，也可以是电的，机械的或其它的形式连接。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本文实施例方案的目的。

另外，在本文各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以是两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本文的技术方案本质上或者说对现有技术做出贡献的部分，或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本文各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

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