一种多业务复用处理方法、装置、及系统与流程

本申请涉及计算机应用
技术领域：
，尤其涉及一种多业务复用处理方法、装置、及系统。
背景技术：
：计算机和互联网技术的发展，为人们带来了前所未有的便捷，目前这些技术已经渗透到人们日常生活的各个方面，对于一些综合性的服务提供方而言，往往能够在多个领域的多个方面为用户提供服务。以互联网金融行业为例，对于用户的资产，需要有相应的账务系统进行管理。根据现有的账务系统设计模式，对于不同类型的业务，需要分别设计独立的账务系统。如图1所示，对于存款、理财、卡券业务，分别设计了三套业务系统，每套系统分别具有独立的业务逻辑，且使用不同的物理数据库以保证数据之间的隔离。但是，随着业务模式的发展和创新，用户资产的形式变得越来越多，例如：银行用户有存款账户、理财账户等，网站用户有余额账户、红包账户、代金券账户等。按照现有的业务系统设计模式，每增加一种用户资产类型，就需要新增一套业务系统来进行管理。除金融行业之外，在其他一些领域也存在类似的情况，这种情况所带来的问题是：每增加一种业务，必然要在新业务系统上投入一定的开发和维护成本。另外，不同业务系统之间采用相互独立的物理数据库，也导致了数据库资源的利用率低下。技术实现要素：针对上述技术问题，本申请提供一种多业务复用处理方法、装置、及系统，技术方案如下：根据本申请的第一方面，提供一种多业务复用处理方法，用于处理两种类型以上的、包含相同操作逻辑的业务，该方法包括：接收业务操作请求，确定待处理业务类型以及对应的操作类型；根据待处理业务类型，确定业务数据在数据库中的存储位置；根据待处理业务的操作类型，获得预设的用于处理该操作类型的通用业务操作指令，所述通用业务操作指令中未指定操作对象数据的实际存储位置；利用所确定的业务数据存储位置和所获得的通用业务操作指令，构建实际业务操作指令；执行所述实际业务操作指令，以响应所述业务操作请求。根据本申请的第二方面，提供一种多业务复用处理装置，用于处理两种类型以上的、包含相同操作逻辑的业务，该装置包括：请求接收模块，用于接收业务操作请求，确定待处理业务类型以及对应的操作类型；存储位置确定模块，用于根据待处理业务类型，确定业务数据在数据库中的存储位置；通用操作指令获得模块，用于根据待处理业务的操作类型，获得预设的用于处理该操作类型的通用业务操作指令，所述通用业务操作指令中未指定操作对象数据的实际存储位置；实际操作指令构建模块，用于利用所确定的业务数据存储位置和所获得的通用业务操作指令，构建实际业务操作指令；执行模块，用于执行所述实际业务操作指令，以响应所述业务操作请求。根据本申请的第三方面，提供一种多业务复用处理系统，用于处理两种类型以上的、包含相同操作逻辑的业务，该系统包括：业务接口层、业务数据路 由层、通用指令库和数据库；业务接口层，用于接收系统外部的发给系统的业务操作请求；业务数据路由层，用于从通用指令库调用通用业务操作指令，根据待处理业务类型构建实际业务操作指令，将业务接口层接收到的业务操作请求路由到相应的数据库；通用指令库：存储有通用业务操作指令，所述通用业务操作指令中未指定操作对象数据的实际存储位置；数据库，用于存储业务数据。本申请所提供的技术方案，基于业务操作逻辑的可复用性，在增加新业务时，只需要新增一套数据库配置，就可以直接实现业务功能，有效地降低了开发和维护成本。进一步地，通过数据路由算法，可以灵活地配置数据库的使用方式，从而实现数据库资源的优化利用。应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本申请。附图说明为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请中记载的一些实施例，对于本领域普通技术人员来讲，还可以根据这些附图获得其他的附图。图1是现有技术的账务系统结构示意图；图2是本申请的账务系统结构示意图；图3是本申请的多业务复用处理方法的流程示意图；图4是本申请的多业务复用处理装置的结构示意图。具体实施方式通过研究发现，在实际应用中，很多系统尽管处理的业务不同，但是实际 涉及的操作都是类似的，例如
背景技术：
中提到的例子，无论是存款、理财、还是余额、红包等业务系统，都要求具有查询、存入、取出、冻结、解冻等功能，从数据库操作的角度来看，不同业务间的同种操作对应的处理逻辑是完全相同的，区别仅在与操作对应的目标数据库不同。基于这种情况，本申请提出的方案是：开发一套通用的数据库操作逻辑，供多种业务进行复用，在处理某种具体业务时，只需将通用操作指向该业务所对应的数据库即可。为了使本领域技术人员更好地理解本申请中的技术方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行详细地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员所获得的所有其他实施例，都应当属于本申请保护的范围。仍然以账务系统为例，对本申请所提供的业务复用方案进行说明，图2所示，为本申请所提供的一种综合账务系统的架构示意图。该系统包括：业务接口层100、业务数据路由层200、通用指令库300、数据库400。业务接口层100：负责接收系统外部的发给系统的业务操作请求，在本申请方案中，系统可以接收多种类型业务的请求。如图1所示，综合账务系统可以接收存款业务、理财业务、卡券业务等多种业务的操作请求，而在接口层面，不同业务的操作请求的接收逻辑是统一的。业务数据路由层200：负责将业务接口层100接收到的业务操作请求路由到相应的数据库。这其中的主要功能包括：根据操作类型，从通用指令库300中调用相应的通用业务操作指令；根据业务类型，确定本次的业务操作对象数据的实际存储位置，并根据所调用的通用业务操作指令，构建用于处理本次业务的实际业务操作指令。根据数据库的实际的使用情况，这里的存储位置可能包括“库位置”和“表位置”两种具体信息，在后面的实施例将会进一步说明。通用指令库300：存储有若干条通用业务操作指令代码，例如查询操作语句、冻结操作语句、解冻操作语句等。在这些语句中，并不需要指明具体的操作对 象在数据库中的存储位置，语句中相应部分可以留空或者以某种标识替代。某一条具体的语句可以应用于所有的业务类型。当某条通用业务操作指令被业务数据路由层200调用以后，将与业务操作对象数据的实际存储位置一起，被重新构建为一条实际业务操作指令。数据库400：存储业务数据，在本申请所提供的方案中，不同的业务之间不仅可以分别使用独立的物理数据库，还可以采用共享相同物理数据库的方式以提高数据库资源的利用率。对于后一种方式，可将不同业务的数据存储位置以逻辑数据库的方式进行划分，结合业务数据路由层200的路由功能，将业务操作指向相应的逻辑数据库，从而保证业务之间的数据隔离。可见，在本申请所提供的多业务复用系统中，业务数据路由层200是核心功能组件，下面将结合具体的实例，对业务数据路由层200的基本功能进行说明：1)数据库配置：本申请所提供的方案，既支持不同业务分别使用独立的物理数据库资源，也支持不同业务共用相同的物理数据库资源。其中，前一种方式与现有技术的数据库资源使用方式相同，在本申请中不做进一步介绍；而后一种方式又可进一步分为是否分库存储、是否分表存储的情况。有些业务的访问量非常大，需要将数据库进行分库、分表，来支撑巨大的业务访问量。相反，如果业务访问量不大，则不需要浪费资源进行分库或分表，只需要配置单库单表或单库分表。假设系统存在m个物理数据库：db0、db1、…dbm-1，则对于任一项业务x：如果x配置为使用单库，即分库数量mx＝1，可以使用m个物理数据库中的任意1个存储业务数据；如果x配置为使用分库，即分库数量1<mx≤m，可以使用m个物理数据库中的任意mx个存储业务数据；对于单库的情况，可以直接配置为单表存储、也可以配置为分表存储；对于分库的情况，只能配置为分表存储。为了便于统一计算和扩展，一般将数据表的数量nx设为mx的整数倍。不同业务之间的数据表，以业务标识进行区分，例如：对于业务x，其对应使用的数据表名称为：x_000、x_001、x_002、……对于业务y，其对应使用的数据表名称为：y_000、y_001、y_002、……当然，上述命名规则仅用于示意性说明，不应理解为对本申请方案的限制。2)数据路由：数据路由包括两部分，库路由和表路由，实际应用时，需要根据业务类型以及业务操作目标数据的某项特征来准确路由到具体的分库及分表。假设对于业务x，其用户数据按照用户编号accountno依次存储在mx个分库的nx个分表中，则库路由和表路由计算方法如下：库路由：在单库的情况下，分库位＝业务类型编号％m；在分库的情况下，分库位＝(accountno％nx)/(nx/mx)表路由：在单表的情况下，不存在分表位，对应的表名称为“业务标识”；在分表的情况下，分表位＝(accountno％nx)，对应的表名称为“业务标识_分表位”。在上述公式中，“％”表示取余运算，“/”表示整除运算。下面结合具体的实例，对本申请的数据库配置及数据路由方案进行说明：假设系统同时支持存款业务、理财业务和卡券业务，且共有5个物理数据库db0、db1、…db4。根据业务需求，配置如下：存款业务：使用5个数据库、共100张数据表，每个数据库中包含20张数据表；理财业务：使用1个数据库、共10张数据表；卡券业务：使用1个数据库、1张数据表；具体配置信息如表1所示，其中“业务类型编码”用于区分不同业务、“类型编号”用于区分不同的分库、“类型后缀”用于区分不同业务的分表。业务类型业务类型编码类型编号类型后缀是否分库分库数量是否分表分表数量存款业务dttrans0dttrue5true100理财业务fdtrans1fdfalse1true10卡券业务fdtrans2cpfalse1false1表1假设用户编号accountno＝2015092201234，根据该编号以及表1中的配置，可以分别计算出该数据在各项业务数据中所对应的数据库以及数据表。对于存款业务：mx＝5，nx＝100；分库位＝(accountno％nx)/(nx/mx)＝34/20＝1，对应物理数据库为db1；分表位＝(accountno％nx)＝34，对应的表名称为dt_034。对于理财业务：mx＝1，nx＝10分库位＝业务类型编号％m＝1，对应物理数据库为db1；分表位＝(accountno％nx)＝4，对应的表名称为fd_004。对于卡券业务：mx＝1，nx＝1分库位＝业务类型编号％m＝2，对应物理数据库为db2；分表位不存在，对应的表名称为cp。可以理解的是，上述数据库配置以及数据路由方案，并不是本申请唯一的实施方式。举例说明：上述单库分库位使用计算公式：业务类型编号％m，其目的是将不同的单库业务平均分配到各个物理数据库中，而实际的数据库配置方式有很多，例如，对于存在5个物理数据库的情况，可以将全部单库业务都分配到数据库db0，将分库业务分配到数据库db1～db4，则数据路由计算公式也需要进行相应的调整。此外，实际应用中的数据库、数据表的命名规则，每条数据的存储分配规则等因素，都会影响到相应的数据路由计算公式。总之，上述具体的实施方式，不应理解为对本申请的限制。在上述数据库配置及数据路由方案的基础上，本申请提供一种多业务复用处理方法，该方法的执行主体为系统中的业务数据路由层200，在执行过程中，需要从将业务接口层100转发的业务操作请求中获得业务操作的基本信息、从通用指令库300调用通用业务操作指令、并且以数据库400作为最终操作对象，参见图3所示，该方法可以包括以下步骤：s101，接收业务操作请求，确定待处理业务类型以及对应的操作类型；仍然以前述的账务系统为例，待处理业务类型可能包括：存款业务、理财业务、卡券业务、等等，而对应的操作类型可能包括：查询、存入、取出、冻结、解冻、等等，这些信息均可以通过对业务操作请求进行解析得到，本申请不做进一步详细说明。s102，根据待处理业务类型，确定业务数据在数据库中的存储位置；如果不同的业务之间分别使用独立的物理数据库，则直接根据业务数据与物理数据库的对应关系，确定业务数据在数据库中的存储位置；如果不同的业务之间共享相同的物理数据库，则采用前面实施例所提供的方法，确定业务数据在通用物理数据库中的逻辑存储位置。根据具体的业务数据存储情况，可能包括确定分库位、分表位等操作，具体的过程在本实施例中不再重复说明。在多线程操作环境中，可以对每种类型的分配具有固定标识特征的处理线程，例如，将业务类型名称以特定的方式进行编码，在业务接口层100设置拦截器，按照预设的规则设置线程变量，从线程的角度看，每个线程都保持一个对其线程局部变量副本的隐式引用，线程变量在一个线程的生命周期内一直有效且可以被访问到，因此数据路由层处理时，可以直接根据当前业务处理进程的变量提取出业务编码，然后进一步确定相应的业务数据存储位置。这种方式在实质上不需要数据路由层真正了解业务类型，只需根据线程的标识特征进行查询即可，而且可以更好地满足多线程对于资源的共享问题。当然，这种方式并不应该理解为对本申请方案的限定。s103，根据待处理业务的操作类型，获得预设的用于处理该操作类型的通 用业务操作指令；在通用指令库中，预先存储有若干条通用业务操作指令代码，在这些指令代码中，仅包含基本的处理逻辑，而没有指明具体的操作对象在数据库中的存储位置。假设待处理业务的操作类型为“查询”，以查询账户信息为例，其通用的查询指令代码形式如下：connectto[库名称]//表示连接到指定库，此处为伪代码，在不同的操作环境下实现方式不同；select*from[表名称]whereaccount_no＝[用户编号]//此处为sql语句中括号中的内容没有具体指明，在后续步骤中，为中括号中的变量指明具体内容后，该语句就可以相应用于处理存款、理财、卡券业务等各种业务的查询操作。需要说明的是，s102和s103在执行顺序上并没有特定的先后限制。s104，利用所确定的业务数据存储位置和所获得的通用业务操作指令，构建实际业务操作指令；假设用户编号为2015092201234，需要处理的业务类型为“存款业务”，操作类型为“账户信息查询”，根据s102计算可知，业务数据存储在数据库db1的数据表dt_034中，根据s103获得的通用查询指令代码，替换掉其中未指定的内容，重构得到实际业务操作指令代码如下：connecttodb1//伪代码，表示连接到db1；select*fromdt_034inwhereaccount_no＝’2015092201234’//sql语句；s105，执行实际业务操作指令，以响应所述业务操作请求。可见，本申请所提供的方案，基于业务渠道的数据库水平扩展，将不同的 业务数据完全隔离，在不同业务体系下建立支持多种业务体系，对未来新业务的接入都提供了完整的解决方案；由于操作逻辑的可复用性，因此在增加新业务时，只需要新增一套数据库配置，就可以直接实现业务功能，有效地降低了开发和维护成本。另外，通过数据路由算法，可以灵活地配置数据库的使用方式，从而实现数据库资源的优化利用。另外，尽管上述实施例仅以账务系统应用进行说明，但是该应用场景并不应理解为对本申请方案的限定。例如，在游戏平台中，不同游戏内信息的管理逻辑是相同的，包括用户注册、登录、积分、内购、成就达成等等，可以将相应操作逻辑设计为通用操作指令，应用本申请的方案实现同一游戏平台对多个游戏的统一管理。类似的应用场景这里不再一一例举，总之根据本申请所提供的方案，本领域技术人员可以在不付出创造性劳动的情况下，设计出应用于其他场景的多业务复用方案。相应于上述方法实施例，本申请还提供一种多业务复用处理装置，该装置在功能上相当于前面实施例中的业务数据路由层，参见图4所示，该装置可以包括：请求接收模块110，用于接收业务操作请求，确定待处理业务类型以及对应的操作类型；存储位置确定模块120，用于根据待处理业务类型，确定业务数据在数据库中的存储位置；通用操作指令获得模块130，用于根据待处理业务的操作类型，获得预设的用于处理该操作类型的通用业务操作指令，所述通用业务操作指令中未指定操作对象数据的实际存储位置；实际操作指令构建模块140，用于利用所确定的业务数据存储位置和所获得的通用业务操作指令，构建实际业务操作指令；执行模块150，用于执行所述实际业务操作指令，以响应所述业务操作请求。在本申请的一种具体实施方式中，每种类型的业务对应具有固定标识特征的处理线程；相应地，存储位置确定模块120可以具体用于根据当前使用的业 务处理线程标识特征，确定业务数据在数据库中的存储位置。在本申请的一种具体实施方式中，不同类型的业务共用相同的物理数据库；相应地，存储位置确定模块120可以具体用于确定业务数据在通用物理数据库中的逻辑存储位置。上述装置中各个模块的功能和作用的实现过程具体详见上述方法中对应步骤的实现过程，在此不再赘述。通过以上的实施方式的描述可知，本领域的技术人员可以清楚地了解到本申请可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如rom/ram、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例或者实施例的某些部分所述的方法。本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于装置实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的模块可以是或者也可以不是物理上分开的，在实施本申请方案时可以把各模块的功能在同一个或多个软件和/或硬件中实现。也可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。以上所述仅是本申请的具体实施方式，应当指出，对于本
技术领域：
的普通技术人员来说，在不脱离本申请原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本申请的保护范围。当前第1页12