发明内容
本申请实施例提供一种基础数据的传输方法及装置,用以降低系统的性能开销。
本申请实施例提供的具体技术方案如下:
一种基础数据的传输方法,包括:
基于用户的业务请求获取相应的第一基础数据集合,所述第一基础数据集合是包含有用于处理所述业务请求的全部基础数据;
在处理所述业务请求的过程中,确定需调用至少一个其他应用系统进行子业务处理时,根据预设的场景定义信息以及当前业务的属性信息,确定当前业务在所述至少一个其他应用系统下对应的场景标识,以及根据所述场景标识获取相应的第二基础数据集合,所述第二基础数据集合中包含有所述至少一个其他应用系统对应所述场景标识需要使用的基础数据;
确定所述第一基础数据集合和第二基础数据集合存在交集时,将交集中包含的基础数据发往所述至少一个其他应用系统。
较佳的,在预处理阶段,设置场景定义信息,包括:
根据各个业务所应用的应用系统以及业务的属性信息进行业务场景区分,并设置场景标识;
在应用系统标识、业务的属性信息以及场景标识之间建立映射关系,并将所述映射关系作为场景定义信息进行保存。
较佳的,根据所述场景标识获取相应的第二基础数据集合,所述第二基础数据集合中包含有所述至少一个其他应用系统对应所述场景标识需要使用的基础数据;
获取所述场景标识对应的所有基础数据,组成所述第二基础数据集合;
或者,
获取所述场景标识对应的符合预设筛选条件的部分基础数据,组成所述第二基础数据集合。
较佳的,获取所述场景标识对应的符合预设筛选条件的部分基础数据,组成所述第二基础数据集合,包括:
从所述场景标识对应的所有基础数据中筛选出使用率最高的N个基础数据,组成所述第二基础数据集合,其中,N为预设数目;
或者,
从所述场景标识对应的所有基础数据中筛选出使用率达到预设门限的基础数据,组成所述第二基础数据集合。
较佳的,将交集中的基础数据发往所述至少一个其他应用系统之后,进一步包括:
统计所述至少一个其他应用系统在当前子业务处理过程中所使用的各个基础数据;
结合所述各个基础数据的历史使用情况,对应所述场景标识对各个基础数据的使用率进行更新。
一种基础数据的传输装置,包括:
第一处理单元,用于基于用户的业务请求获取相应的第一基础数据集合,所述第一基础数据集合是包含有用于处理所述业务请求的全部基础数据;
第二处理单元,用于在处理所述业务请求的过程中,确定需调用至少一个其他应用系统进行子业务处理时,根据预设的场景定义信息以及当前业务的属性信息,确定当前业务在所述至少一个其他应用系统下对应的场景标识,以及根据所述场景标识获取相应的第二基础数据集合,所述第二基础数据集合中包含有所述至少一个其他应用系统对应所述场景标识需要使用的基础数据;
透传单元,用于在确定所述第一基础数据集合和第二基础数据集合存在交集时,将交集中包含的基础数据发往所述至少一个其他应用系统。
较佳的,进一步包括:
配置单元,用于在预处理阶段,设置场景定义信息,具体包括:根据各个业务所应用的应用系统以及业务的属性信息进行业务场景区分,并设置场景标识;在应用系统标识、业务的属性信息以及场景标识之间建立映射关系,并将所述映射关系作为场景定义信息进行保存。
较佳的,根据所述场景标识获取相应的第二基础数据集合时,所述第二处理单元具体用于:
获取所述场景标识对应的所有基础数据,组成所述第二基础数据集合;
或者,
获取所述场景标识对应的符合预设筛选条件的部分基础数据,组成所述第二基础数据集合。
较佳的,获取所述场景标识对应的符合预设筛选条件的部分基础数据,组成所述第二基础数据集合时,所述第二处理单元具体用于:
从所述场景标识对应的所有基础数据中筛选出使用率最高的N个基础数据,组成所述第二基础数据集合,其中,N为预设数目;
或者,
从所述场景标识对应的所有基础数据中筛选出使用率达到预设门限的基础数据,组成所述第二基础数据集合。
较佳的,进一步包括:
统计单元,用于在将交集中的基础数据发往所述至少一个其他应用系统之后,统计所述至少一个其他应用系统在当前子业务处理过程中所使用的各个基础数据;并结合所述各个基础数据的历史使用情况,对应所述场景标识对各个基础数据的使用率进行更新。
本申请实施例中,某一应用系统进行业务处理过程中,如果需要调用至少一个其他应用系统进行子业务处理,则从本地已获取的基础数据中将该至少一个其他应用系统需要的基础数据透传至对应的应用系统,这样,可以在整体上降低对同样的基础数据发起的RPC调用服务的次数,减少了基础数据获取计算量,避免了因重复计算而造成的资源浪费,提高了系统整体的响应能力,降低了系统整体的性能开销。
具体实施方式
在一次业务处理的过程中,可能一个应用系统使用到的基础数据在后续流程中也会被其他应用系统使用到。如果每个应用系统可以将基础数据传递给后续的应用系统,那么是可以减少后续应用系统重复调用基础数据所产生的系统开销的。为了实现此目的,本申请实施例中,对业务进行了场景区分,并基于不同的场景分别针对每个应用系统使用到的基础数据进行统计。而在系统调用基础数据时可以根据下游的应用系统所需要的基础数据进行数据透传,以此来降低整个业务处理链路对同一基础数据的重复调用,从而提高整体的系统性能。
下面结合附图对本申请优选的实施方式进行详细说明。
业务系统在进行业务处理时,会根据业务的某些属性做出不同的业务流程处理、分发,这就是不同的业务场景(例如PC付款、无线付款会根据支付来源区分为两个场景)。不同业务场景的一些业务细节处理上会有所不同,因此不同场景所使用到的基础数据也有所不同。在这种情况下如果上游系统将其所有数据都传递给后续系统,必定会导致所传递的基础数据的使用率不高,同时又占用网络流量巨大。因此需要根据业务属性识别出不同的场景,基于每个场景下对使用到的基础数据进行统计,并根据统计结果来决策透传的基础数据,这样对减少网络开销、提高透传的基础数据的使用率是非常有帮助的。
具体的,每个业务在经过流程处理时都会有业务属性,根据业务的核心属性信息可以对业务进行场景分类。
例如,一个业务的属性信息可以包括但不限于表1所示的内容:
表1
如表1所示,其中的部分属性信息会对相应的业务有决定性的影响,当这些属性信息的取值不一样时,相关的业务流程可能会有所不同,因此,较佳的,需要根据这些属性信息来区分业务场景。假设表1所示的bizType字段和channel字段对整个业务流程有重要影响,那么,可选的,可以根据这两个字段进行场景划分,具体如表2所示:
表2
如表2所示,其中,
systemCode,用于描述当前定义的场景属于哪一个应用系统。不同应用系统在定义同一个场景时可能会稍有差别。
sceneCode,用于描述场景名称。同一个场景名称可以对应多个应用系统生效。
sceneCondition,用于描述场景需要满足的条件组。只有当条件组中的所有条件都满足时,场景才会被识别。
从上述定义可以看出,场景的定义是基于业务属性的(如,业务类型、操作渠道、环境信息等等)。
例如,对于系统B,必须“bizType=业务1”并且“channel=PC渠道”时,当前场景才会被识别为场景2。
当应用系统启动后,预先配置的场景定义信息都被应用系统加载并进行缓存。
进一步地,在业务运行时,各个应用系统会根据场景定义信息识别当前业务所属场景,以及统计当前业务运行时所使用到的基础数据,基于多次的场景数据统计,可以得到各个应用系统在每一个场景下最有可能使用到的基础数据,这些统计结果会被基础数据平台存储起来,当再有业务需要处理时,若某一应用系统需要调用其他应用系统进行子业务处理,那么,调用系统便会从自身已获取的基础数据中将被调用系统最有可能使用到的基础数据透传至被调用系统,以减少被调用系统的计算量。
例如,参阅图3所示,系统B和系统C会根据场景定义识别当前的所属场景,以及统计这个场景下使用了哪些基础数据。基于多次的场景数据统计,可以得到系统B、系统C在每一个场景下最有可能使用的基础数据。这些统计结果会被存储起来。当再有业务需要处理时,系统A在调用系统B时会根据系统B的统计结果,将系统B有可能使用到的数据传递给系统B,以及在调用系统C时,将系统C有可能使用到的数据传递给系统C。
基于上述预配置信息,本申请实施例中,采用分布式架构的管理装置来实现基础数据传输流程,管理装置中的不同模块分布在不同的应用系统中,通过彼此间的协作来完成基础数据的传输及相关统计工作。
参阅图4所示,本申请实施例中,对基础数据进行传输的流程如下:
步骤400:管理装置基于用户的业务请求获取相应的第一基础数据集合,该第一基础数据集合中包含有用于处理该业务请求的全部基础数据。
具体的,管理装置可以通过布置在调用系统中的功能模块来完成步骤400。
例如,在系统A中设置有管理装置的处理模块,系统A中设置的管理装置的处理模块接收到用户的业务请求后,根据该业务请求确定相应的业务类型,以及根据业务类型确定进行业务处理所需的基础数据,如,处理模块根据用户的业务需求计算进行业务处理所需的基础数据,并从基础数据平台获取基数数据a、b、c、d、e、f。
步骤410:管理装置在处理业务请求的过程中,确定需要调用至少一个其他应用系统进行子业务处理时,根据预设的场景定义信息以及当前业务的属性信息,确定当前业务在上述至少一个其他应用系统下对应的场景标识,以及根据获得的场景标识获取相应的第二基础数据集合,该第二基础数据集合中包含有上述至少一个其他应用系统对应该场景标识需要使用的基础数据。
本申请实施例中,在预处理阶段,分布式的管理装置需要通过设置在基础数据平台上的配置模块来配置场景定义信息,具体的,配置模块可以根据各个业务所应用的应用系统以及业务的属性信息进行业务场景区分,并设置场景标识(同一业务在不同应用系统中可能分属不同场景),并在应用系统标识、业务的属性信息以及业务场景标识之间建立映射关系,该映射关系即为场景定义信息,具体参见表1和表2所示,在此不再赘述。配置模块需要将场景定义信息保存在基础数据平台中,以便各个应用系统随时调用。
实际应用中,一个应用系统需要调用另外一个应用系统完成子业务处理时,会识别当前业务在被调用系统下所属的业务场景,以及这一场景下最可能会使用到的基础数据,如果调用系统已经计算得到了这些基础数据,则会将这些基础数据传递给被调用系统。减少被调用系统重复对这些基础数据的计算调用。
例如,系统A中的处理模块确定需要调用系统B进行子业务处理时,根据预设的场景定义信息,识别当前业务在B系统下所属于的场景的场景标识为“场景1”。接着,需要确定系统B在“场景1”对应的业务场景下需要使用的基础数据,这些基础数据已在数据统计阶段存储至基础数据平台。
具体的,在执行步骤410时,管理装置中的处理模块可以基于获取的场景标识对应的所有基础数据组成第二基础数据集合,也可以基于上述场景标识对应的符合预设筛选条件的部分基础数据组成第二基础数据集合,例如,从场景标识对应的所有基础数据中筛选出使用率最高的N个基础数据组成第二基础数据集合,其中,N为预设数目;又例如,从场景标识对应的所有基础数据中筛选出使用率达到预设门限的基础数据组成第二基础数据集合。
例如,获取“场景1”下系统B使用率最高的2个基础数据组成第二基础数据集合。
又例如,获取“场景1”下系统B使用率达到预设门限的基站数据为a、e,组成第二基础数据集合。
步骤420:管理装置确定第一基础数据集合和第二基础数据集合存在交集时,将交集中包含的基础数据发往上述至少一个其他应用系统。
具体的,管理装置确定本地为进行业务处理而获取的基础数据中包含有至少一个其他应用系统所需的基础数据时,将各部分基础数据分别发往对应的其他应用系统。
例如,系统A中的处理模块将基础数据a、e数据设置到参数中,在调用系统B时传递给系统B。
这样,当系统B接收到系统A的调用信令后,从调用信令携带的参数中获取透传的基础数据a、e。并根据调用信令开始进行子业务处理,在业务处理过程中,如果使用到了基础数据a、e,则直接从透传的数据中获取基础数据a、e,不需要重复调用计算;当然,如果还需要使用到其它基础数据则需要另外进行调用计算。
进一步地,本申请实施例中提及的分布式的管理装置在被调用系统中也可以设置有统计模块,用于统计各类基础数据的使用情况。具体的,统计模块可以统计上述至少一个其他应用系统在当前子业务处理过程中所使用的各个基础数据,并结合各个基础数据的历史使用情况,对应当前的场景标识对各个基础数据的使用率进行更新。
例如,当系统B完成业务处理后,系统B中的统计模块会识别当前场景为场景1,并统计使用到的基础数据,假设系统B使用到了基站数据a、e、f,(其中基础数据a、e会从透传参数中获取,f会另外从基础数据平台计算获取),那么相关统计信息如表3所示:
表3
所属系统 |
场景 |
基础数据 |
使用次数 |
系统B |
场景1 |
A |
上次统计结果+1 |
系统B |
场景1 |
E |
上次统计结果+1 |
系统B |
场景1 |
G |
上次统计结果+1 |
很明显,基础数据a、e、f有使用率都得到了提高,虽然此次子业务处理赛程中,系统A仅仅将基础数据a、e进行了透传,但按照此种方式经过多次的统计后,系统B在场景1下基础数据a、e、f的使用率会达到理想门限值,那么,统计模块可以将统计结果存储至基础数据平台,系统A在下次进行基础数据透传时就可以根据基础数据平台上存储的最新的统计信息对调用的基础数据进行动态调整,即将透传给B基础数据改为a、e、f。
实际应用中,每个应用系统在完成业务处理后,均会识别当前业务所属的场景,并统计当前场景使用到的基础数据。基于同一场景多次的统计,即可得到这一业务场景下每个基础数据的使用率。当后续再有这一场景的业务单据处理时,即可得到处理过程中最可能用到的基础数据。
上述过程仅以系统B为例,系统C的调用过程与系统B类似,具体参阅图5所示,在此不再赘述。
基于上述实施例,参阅图6所示,本申请实施例中,管理装置采用分布式结构设置在各应用系统之中,通过各个功能模块之间的协作完成基础数据的传输,具体的,管理装置包括第一处理单元60、第二处理单元61和透传单元62,其中,
第一处理单元60,用于基于用户的业务请求获取相应的第一基础数据集合,第一基础数据集合是包含有用于处理业务请求的全部基础数据;
第二处理单元61,用于在处理业务请求的过程中,确定需调用至少一个其他应用系统进行子业务处理时,根据预设的场景定义信息以及当前业务的属性信息,确定当前业务在至少一个其他应用系统下对应的场景标识,以及根据场景标识获取相应的第二基础数据集合,第二基础数据集合中包含有至少一个其他应用系统对应场景标识需要使用的基础数据;
透传单元62,用于在确定第一基础数据集合和第二基础数据集合存在交集时,将交集中包含的基础数据发往至少一个其他应用系统。
较佳的,进一步包括:
配置单元63,布置在基础数据平台中,用于在预处理阶段,设置场景定义信息,具体包括:根据各个业务所应用的应用系统以及业务的属性信息进行业务场景区分,并设置场景标识;在应用系统标识、业务的属性信息以及场景标识之间建立映射关系,并将映射关系作为场景定义信息进行保存。
较佳的,根据场景标识获取相应的第二基础数据集合时,第二处理单元61具体用于:
获取场景标识对应的所有基础数据,组成第二基础数据集合;
或者,
获取场景标识对应的符合预设筛选条件的部分基础数据,组成第二基础数据集合。
较佳的,获取场景标识对应的符合预设筛选条件的部分基础数据,组成第二基础数据集合时,第二处理单元61具体用于:
从场景标识对应的所有基础数据中筛选出使用率最高的N个基础数据,组成第二基础数据集合,其中,N为预设数目;
或者,
从场景标识对应的所有基础数据中筛选出使用率达到预设门限的基础数据,组成第二基础数据集合。
较佳的,进一步包括:
统计单元64,布置在各个应用系统中,用于在将交集中的基础数据发往至少一个其他应用系统之后,统计至少一个其他应用系统在当前子业务处理过程中所使用的各个基础数据;并结合各个基础数据的历史使用情况,对应场景标识对各个基础数据的使用率进行更新。
综上所述,本申请实施例中,某一应用系统进行业务处理过程中,如果需要调用至少一个其他应用系统进行子业务处理,则从本地已获取的基础数据中将该至少一个其他应用系统需要的基础数据透传至对应的应用系统,这样,可以在整体上降低对同样的基础数据发起的RPC调用服务的次数,减少了基础数据获取计算量,避免了因重复计算而造成的资源浪费,提高了系统整体的响应能力,降低了系统整体的性能开销。
本申请实施例提供的技术方案可以使用任何计算机语言实现,且对于软件与硬件没有特殊要求
本领域内的技术人员应明白,本申请的实施例可提供为方法、系统、或计算机程序产品。因此,本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且,本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
本申请是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器,使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中,使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品,该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上,使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理,从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
尽管已描述了本申请的优选实施例,但本领域内的技术人员一旦得知了基本创造性概念,则可对这些实施例作出另外的变更和修改。所以,所附权利要求意欲解释为包括优选实施例以及落入本申请范围的所有变更和修改。
显然,本领域的技术人员可以对本申请实施例进行各种改动和变型而不脱离本申请实施例的精神和范围。这样,倘若本申请实施例的这些修改和变型属于本申请权利要求及其等同技术的范围之内,则本申请也意图包含这些改动和变型在内。