具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本发明相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本发明的一些方面相一致的装置和方法的例子。

随着网络技术的发展，应用系统的功能不断扩充。一个应用系统可以支持多种业务类型。以电商系统为例，电商系统可以支持商家业务、订单业务、复核业务等。

针对商家业务，按照商家维度进行划分，商家业务可以进一步被划分为不同类型的商家对应的业务。例如：零售商家业务、大客户商家业务、重要客户(KA)商家业务等。针对订单业务，按照订单维度进行划分，订单业务可以进一步划分为不同类型的订单对应的业务。例如：普通客户订单业务、大客户订单业务、采购订单业务、退供订单业务、内配订单业务等。针对复核业务，按照被复核的订单维度进行划分，复核业务可以进一步划分为：普通客户订单复核业务、大客户订单复核、内配订单复核等。

随着电商系统接入的商家类型不断增多、以及支持的订单类型不断增多，不同的商家或者不同的订单可能具有不同的个性化需求。例如，每接入一个商家，都需要针对该商家的个性化需求开发出对应的功能，或者在原有代码基础上进行修改，补充新的功能、逻辑分支等。

在实现本发明过程中，发明人发现现有技术中至少存在如下问题：应用系统的代码通用性和扩展性较差，导致代码维护成本和维护难度加大，并且代码运行效率较低。主要体现在如下几个方面：

(1)在需要增加新的业务、或者需要为某种业务类型增加新的功能时，存在严重的程序重新研发的问题，代码扩展性差，研发人员需要大量的研发时间，代码维护成本和维度难度不断加大。

(2)通过对原有代码进行修改以补充开发新的业务类型或者新的功能，对于原有代码侵入影响严重，需要进行大量的回归测试，影响系统的稳定性，进一步加大了代码维护成本和维护难度。

(3)采用上述方式维护的应用系统代码中，经常会出现对于某些特殊商家的特殊判断，例如，存在大量的if(商家标识＝＝“111”){特殊流程处理}这种程序块。这样，在应用系统的程序执行时，可能会对所有业务类型进行上述特殊判断，导致代码运行效率降低。

能够理解，随着应用系统的业务功能不断扩充，应用系统的代码量不断增加，上述几方面的技术问题对于应用系统的影响程度将不断增加。

本发明实施例提供一种数据处理方法，旨在解决上述技术问题中的至少一个。图1为本发明实施例适用的一种可能的系统架构的示意图。如图1所示，该系统架构中包括客户端和服务端。客户端可以向服务端发起业务请求，服务端可以根据业务请求进行数据处理，并将数据处理结果返回给客户端。一些示例中，客户端和服务端可以集成在一个电子设备中。另一些示例中，客户端和服务端可以分别位于不同的电子设备中。本实施例对此不作限定。

本实施例提供的数据处理方法可以由服务端执行。本实施例中，将不同业务的处理过程进行隔离，即不同业务对应不同的业务实现类。这样，当需要针对某种业务进行数据处理时，只需要找到该业务对应的业务实现类，并执行该业务实现类即可。当需要新增业务时，只需要开发出该新增业务对应的业务实现类，不会对其他的业务实现类带来影响。当需要删除某种业务时，只需要删除该业务对应的业务实现类即可，也不会对其他的业务实现类带来影响。当需要修改某种业务的功能时，只需要对该业务对应的业务实现类中的部分方法进行修改，不会对其他的业务实现类带来影响。可见，提高了代码的扩展性和可维护性，并且，还可以提高执行效率。

下面以具体地实施例对本发明的技术方案以及本发明的技术方案如何解决上述技术问题进行详细说明。下面这几个具体的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例中不再赘述。下面将结合附图，对本发明的实施例进行描述。

为了便于理解，首先结合图2至图6对本发明中的业务实现类的设计方式进行介绍。

具体的，针对每个业务定义并实现该业务对应的业务实现类。例如，针对业务1定义了业务实现类1，用于实现业务1相关的数据处理流程；针对业务2定义了业务实现类2，用于实现业务2相关的数据处理流程；针对业务3定义了业务实现类3，用于实现业务3相关的数据处理流程，等等。

本实施例中，每个业务实现类可以具体包括一个或者多个类。当包括多个类时，不同的类可以用于实现该业务的不同功能。

可选的，一个业务对应的业务实现类可以包括基础实现类和扩展实现类。其中，基础实现类用于实现该业务相关的共性功能，扩展实现类用于实现该业务相关的个性化功能。

图2为本发明实施例提供的业务实现类的示意图。假设应用系统包括订单业务、复核业务和商家业务。如图2所示，针对每一个业务，都定义了基础实现类，并且，针对该业务的每个子业务，都定义了该子业务对应的扩展实现类。

以订单业务为例，订单业务可以进一步划分为多个子业务，例如：普通客户订单业务、大客户订单业务、采购订单业务、退供订单业务、内配订单业务等。这些不同子业务之间通常存在共性的业务逻辑，同时，每个子业务可能也会存在个性化、差异化的业务逻辑。因此，可以针对多个子业务之间共性的业务逻辑开发得到订单业务对应的基础实现类，并且，针对每个子业务个性化的业务逻辑开发得到该子业务对应的扩展实现类。以普通客户订单业务对应的扩展实现类为例，将普通客户订单业务中存在的一些个性化的业务逻辑(例如：参数校验、数据设置、消息发送等)，即，其他的订单业务(例如大客户订单业务、采购订单业务等)不具备的业务逻辑，都在普通客户订单业务对应的扩展实现类中来实现。这样，如图2所示，订单业务对应的业务实现类包括基础实现类和多个扩展实现类。

复核业务、商家业务对应的业务实现类的结构是类似的，此处不作赘述。

可选的，当业务有更细的划分时，可以对扩展实现类进行分级实现，例如，扩展实现类可以包括一级扩展实现类和二级扩展实现类。

一些实施方式中，一级扩展实现类用于对基础实现类的功能进行扩展，二级扩展实现类用于对一级扩展实现类的功能进行扩展。例如，图2中，若针对普通客户订单业务，还存在更细的划分，比如：普通零售客户订单业务、普通团购客户订单业务等。这时，可以将普通客户订单业务扩展实现类作为一级扩展实现类，该一级扩展实现类还可以关联一个或者多个二级扩展实现类，每个二级扩展实现类用于实现更细子业务的个性化业务逻辑(例如，普通零售客户订单业务扩展实现类、普通团购客户订单业务扩展实现类等，图2中未示出)。这样，每种业务的扩展实现类结构清晰，不同子业务之间相互隔离，便于扩展和维护。

另一些实施例中，一级扩展实现类用于对基础实现类的功能进行第一维度的扩展，二级扩展实现类用于对基础实现类的功能进行第二维度的扩展。也就是说，一级扩展实现类和二级扩展实现类可以从不同维度对基础实现类进行扩展。例如，一级扩展实现类可以按照商家维度划分(零售、大客户、Ka商家等)，二级扩展实现类按照订单维度划分(客户订单、商家订单、采购订单、内配订单等)。这样，一级扩展实现类和二级扩展实现类可以按需组合，从而实现更加灵活。

本实施例中，一个业务可以对应1个基础实现类、0个或者多个一级扩展实现类、0个或者多个二级扩展实现类。其中，基础实现类和扩展实现类可以通过业务的标识进行关联。例如，可以根据业务的标识，确定出该业务对应的基础实现类、一级扩展实现类和二级扩展实现类。

需要说明的是，本实施例中，是以两级扩展为例进行示意的，实际应用中，还可以存在更多级扩展。并且，不同的业务可以包括不同级扩展，例如，订单业务包括两级扩展，商家业务包括三级扩展，等。

图3为本发明实施例提供的应用系统的层级示意图。如图3所示，应用系统的上层为业务层，下层为服务层。业务层中，应用服务获取到业务请求后，由业务执行器执行业务数据处理过程。业务执行器的处理流程中，可以支持基础实现类和扩展实现类的动态匹配执行。例如，通过业务标识匹配出执行哪个基础实现类，进而，在该业务标识关联的多个扩展实现类中动态匹配出执行哪个或者哪些扩展实现类。其中，每个业务的扩展实现类可以仅包括一级扩展实现类，还可以包括一级扩展实现类和二级扩展实现类。通过采用动态匹配的方式执行基础实现类和扩展实现类，使得扩展更加灵活，并且能够提高执行效率。

结合图3，服务层用于向业务层提供基础服务，其内部的方法可以为业务层提供单一功能，供业务层来灵活使用。同时，服务层的能力方法支持动态扩展，也可以按照业务层的动态扩展方式来匹配扩展实现，达到动态执行部分代码的效果。

下面结合具体的实例描述基础实现类和扩展实现类的定义方式以及实现方式。

图4为本发明实施例提供的基础实现类的定义及实现的示意图。如图4所示的基础实现类定义，该定义是业务执行过程中的主(Main)流程定义类，每一个业务都需要包含唯一的该类实现，即主流程业务的实现。基础实现类包含的方法定义如下：

(1)创建上下文()，用于创建业务流程的上下文信息，可以扩展自定义，将请求参数设置到上下文信息中。

(2)加载上下文()，用于设置上下文信息，主要是根据请求参数从数据库查询相关数据，并设置到上下文信息中。

(3)业务处理()，用于设置上下文信息中的业务处理结果，包括：任务对象、对象结果、要操作(插入、更新、删除)数据库的对象列表等。

(4)数据库处理()，用于操作数据库。

图4中以订单业务为例，示例了订单业务对应的基础实现类的实现，包括了上述4个方法的实现。

图5为本发明实施例提供的一级扩展实现类的定义及实现的示意图。如图5所示的一级扩展(Extend)实现类定义，该定义是业务执行过程中的一级扩展(Extend)流程定义类，每一个业务流程都可以包含0-N个的该类实现，即，可以没有一级扩展实现类，也可以包括N个一级扩展实现类。一级扩展实现类包含的方法定义如下：

(1)匹配上下文()，用于确定该一级扩展实现类是否与当前的业务请求匹配。例如，当前业务请求是请求对客单进行处理，但是该一级扩展实现类是针对退工单的实现，则说明当前业务请求与该一级扩展实现类不匹配。

(2)加载上下文()，用于设置上下文信息，主要是根据请求参数从数据库查询相关数据，并设置到上下文信息中。

(3)业务处理()，用于设置上下文信息中的业务处理结果，包括：任务对象、对象结果、要操作(插入、更新、删除)数据库的对象列表等。

图5中以订单业务为例，示例了普通客户订单业务和大客户订单业务对应的一级扩展实现类的实现，这两个一级扩展实现类中包括了上述3个方法的实现。需要说明的是，具体实施过程中，一级扩展实现类中可以仅实现上述3个方法中的部分方法。

图6为本发明实施例提供的二级扩展实现类的定义及实现的示意图。如图6所示的二级扩展(Extend)实现定义，该定义是业务执行过程中的二级扩展(Extend)流程定义类，可以对一级扩展实现类的定义进行扩展，每一个业务流程都可以包含0-N个该类实现，即，可以没有二级扩展实现类，也可以包括N个二级扩展实现类。一级扩展实现类包含的方法定义如下：

(1)匹配上下文()，用于确定该二级扩展实现类是否与当前的业务请求匹配。例如，当前业务请求是请求对客单进行处理，但是该二级扩展实现类是针对退工单的实现，则说明当前业务请求与该二级扩展实现类不匹配。

(2)业务处理()，用于设置上下文信息中的业务处理结果，包括：任务对象、对象结果、要操作(插入、更新、删除)数据库的对象列表等。

图6中以订单业务为例，示例了普通零售客户订单业务、普通团购客户订单业务对应的二级扩展实现类的实现，这两个二级扩展实现类中包括了上述2个方法的实现。需要说明的是，具体实施过程中，二级扩展实现类中可以仅实现上述2个方法中的部分方法。

本实施例中，通过将业务处理流程拆分为基础实现流程和扩展实现流程，对业务的隔离非常有效，并且对于代码实现更加规范，提高了代码的可扩展性和可维护性。当需要删除某种扩展业务时，仅需要删除该扩展业务对应的扩展实现类即可，使得维护更加简单。

基于上述任意实施例描述的业务实现类，下面对本发明实施例提供的数据处理方法进行介绍。

图7为本发明一个实施例提供的数据处理方法的流程示意图。如图7所示，本实施例的方法可以包括：

S701：获取业务请求，所述业务请求用于指示对第一业务的数据进行处理，所述业务请求包括所述第一业务的标识和请求参数。

示例性的，客户端根据第一业务的数据处理需求向服务端发送业务请求，以指示服务端对第一业务的数据进行处理。服务端从客户端接收业务请求。其中，第一业务可以是客户端请求处理的任意一种业务，例如，可以为订单业务、商家业务、或者复核业务等。

业务请求中包括第一业务的标识和请求参数。其中，第一业务的标识可以是能够唯一标识该业务的信息，例如，可以是业务名称，业务编号等。请求参数用于指示第一业务待处理数据的详细信息。应理解，对于不同的业务，其对应的请求参数可能不同。示例性的，当第一业务为订单业务时，请求参数可以进一步指示订单类型，例如，指示是需要对普通客户订单进行处理，还是需要对大客户订单进行处理，或者是需要对采购订单进行处理等。

S702：根据所述第一业务的标识，从多个候选业务实现类中确定与所述第一业务匹配的第一业务实现类。

具体的，服务端已事先针对每个业务定义并实现了该业务对应的业务实现类。这样，当服务端接收到业务请求之后，可以根据其中携带的第一业务的标识，从多个业务实现类中动态匹配出与第一业务匹配的第一业务实现类。

S703：根据所述请求参数执行所述第一业务实现类中的方法，得到所述业务请求对应的处理结果。

服务端确定出第一业务实现类后，可以根据请求参数执行第一业务实现类中的方法，得到业务请求对应的处理结果。

本实施例中，将不同业务的实现流程进行隔离，即不同业务对应不同的业务实现类。这样，当需要针对某种业务进行数据处理时，只需要找到该业务对应的业务实现类，并执行该业务实现类即可，无需对其他业务实现类进行遍历执行，提高了执行效率。

另外，由于不同业务对应不同的业务实现类，当需要新增业务类型时，只需要开发出该新增业务类型对应的业务实现类，不会对其他业务实现类带来影响。当需要删除某种业务类型时，只需要删除该业务类型对应的业务实现类即可，也不会对其他业务实现类带来影响。当需要修改某种业务类型的功能时，只需要对该业务类型对应的业务实现类中的部分方法进行修改，不会对其他业务实现类带来影响。可见，提高了代码的扩展性和可维护性。

可选的，第一业务实现类中可以包括基础实现类和扩展实现类。相应的，S703可以具体包括：根据请求参数，执行基础实现类的方法，并执行扩展实现类的方法，从而得到业务请求对应的处理结果。

其中，基础实现类和扩展实现类的执行顺序不作限定。基础实现类和扩展实现类中的方法可以先后执行，还可以交叉执行。一些示例中，基础实现类和扩展实现类中的方法的执行顺序还可以是动态确定的，即，针对不同的业务类型，可以有不同的执行顺序。

本实施例中，第一业务实现类中包括的扩展实现类的数量可以有一个或者多个，服务端在执行时，可以仅执行其中部分扩展实现类中的方法。例如，可以采用动态匹配的方式，确定执行哪些扩展实现类的方法。

可选的，扩展实现类可以包括多个一级扩展实现类。

该情况下，服务端可以根据请求参数，从多个一级扩展实现类中确定出与第一业务匹配的一级扩展实现类，并执行与第一业务匹配的一级扩展实现类中的方法。例如，以第一业务为订单业务为例，若请求参数指示的是对普通客户订单业务进行数据处理，则从订单业务关联的多个一级扩展实现类中，确定出用于对普通客户订单进行处理的一级扩展实现类，从而只需要执行该确定出的一级扩展实现类中的方法，无需遍历执行其他一级扩展实现类中的方法，从而提高执行效率。

可选的，扩展实现类还可以包括多个二级扩展实现类。

该情况下，服务端在执行一级扩展实现类中的方法之后，还可以包括：根据请求参数，从多个二级扩展实现类中获取与第一业务匹配的二级扩展实现类，并执行与第一业务匹配的二级扩展实现类中的方法。例如，以第一业务为订单业务为例，若请求参数指示的是对普通零售客户订单业务进行数据处理，则从订单业务关联的多个二级扩展实现类中，确定出用于对普通零售客户订单进行处理的二级扩展实现类，从而只需要执行该确定出的二级扩展实现类中的方法，无需遍历执行其他二级扩展实现类中的方法，从而提高执行效率。

下面结合图4至图6所示的基础实现类和扩展实现类的定义及实现，以一个具体的实例描述本实施例中的数据处理过程。

图8为本发明另一个实施例提供的数据处理方法的流程示意图。如图8所示，本实施例的方法包括：

S801：获取业务请求，业务请求包括第一业务的标识和请求参数。

具体的，服务端的应用系统包括服务接口，服务接口接收到客户端发送的业务请求。服务端执行下述的S802至S811的数据处理流程。

S802：根据第一业务的标识，从多个候选业务实现类中确定出与第一业务匹配的第一业务实现类，第一业务实现类中包括基础实现类、多个一级扩展实现类、以及多个二级扩展实现类。

示例性的，若第一业务为订单业务，则从多个候选业务实现类中确定出订单业务对应的业务实现类，该业务实现类中可以具体包括基础实现类、多个一级扩展实现类(例如普通客户订单业务扩展实现类、大客户订单业务扩展实现类等)、以及多个二级扩展实现类(普通零售客户订单业务扩展实现类、普通团购用户订单业务扩展实现类等)。

S803：执行基础实现类中的创建上下文方法。

具体的，根据请求参数，执行基础实现类中的创建上下文方法，得到第一业务对应的上下文信息，并将请求参数设置到上下文信息中。

S804：执行基础实现类中的加载上下文方法。

具体的，根据请求参数，执行基础实现类中的加载上下文方法，主要是设置上下文信息中的参数。例如，根据请求参数从数据库、或者第三方系统中获取相关数据设置到上下文信息中。

S805：根据请求参数，执行多个一级扩展实现类中的匹配上下文方法，根据执行结果从多个一级扩展实现类中确定出与第一业务匹配的一级扩展实现类。

具体的，针对第一业务实现类中包括的多个一级扩展实现类，分别根据请求参数执行匹配上下文方法，以确定出每个一级扩展实现类是否与第一业务匹配。这样，从多个一级扩展实现类中确定出与第一业务匹配的一级扩展实现类。

假设业务请求中的请求参数指示的是对普通客户的订单业务进行数据处理，则此处匹配出的一级扩展实现类可以为：普通客户订单业务扩展实现类。

应理解，根据请求参数的不同，匹配的结果可能也不同。即，匹配出的一级扩展实现类的数量可能为0个、1个或者多个。若匹配出的一级扩展实现类的数量为0个，则无需执行S806、S808。

S806：执行与第一业务匹配的一级扩展实现类中的加载上下文方法。

具体的，根据请求参数，执行匹配的一级扩展实现类中的加载上下文方法，主要是设置上下文信息中的参数。例如，根据请求参数从数据库、或者第三方系统中获取相关数据设置到上下文信息中。

S807：执行基础实现类中的业务处理方法。

具体的，根据上述步骤得到的上下文信息，执行基础实现类中的业务处理方法，对业务请求的相关数据进行处理，例如：对请求数据进行修改、计算、第三方数据发送等。

S808：执行与第一业务匹配的一级扩展实现类中的业务处理方法。

具体的，根据上述步骤得到的上下文信息，执行匹配的一级扩展实现类中的业务处理方法，对业务请求的相关数据进行处理，例如：对请求数据进行修改、计算、第三方数据发送等。

S809：根据请求参数，执行多个二级扩展实现类中的匹配上下文方法，根据执行结果从多个二级扩展实现类中确定出与第一业务匹配的二级扩展实现类。

具体的，针对第一业务实现类中包括的多个二级扩展实现类，分别根据请求参数执行匹配上下文方法，以确定出每个二级扩展实现类是否与第一业务匹配。这样，从多个二级扩展实现类中确定出与第一业务匹配的二级扩展实现类。

假设业务请求中的请求参数指示的是对普通零售客户的订单业务进行数据处理，则此处匹配出的二级扩展实现类可以为：普通零售客户订单业务扩展实现类。

应理解，根据请求参数的不同，匹配的结果可能也不同。即，匹配出的二级扩展实现类的数量可能为0个、1个或者多个。若匹配出的二级扩展实现类的数量为0个，则无需执行S810。

S810：执行与第一业务匹配的二级扩展实现类中的业务处理方法。

具体的，根据上述步骤得到的上下文信息，执行匹配的二级扩展实现类中的业务处理方法，对业务请求的相关数据进行处理，例如：对请求数据进行修改、计算、第三方数据发送等。

S811：执行基础实现类中的数据库处理方法。

具体的，根据上述步骤得到的上下文信息，执行基础实现类中的数据库处理方法，即，对该业务请求的数据处理结果进行数据库修改。

S812：得到业务请求对应的数据处理结果。

经过上述S802至S811的数据处理过程后，得到本次业务请求对应的数据处理结果。进一步的，服务端可以将该数据处理结果返回给客户端。

本实施例中，在执行第一业务的数据处理流程时，先根据第一业务的标识确定与第一业务匹配的基础实现类和扩展实现类，进而根据请求参数确定出执行哪些扩展实现类。通过上述动态控制，针对不同的业务，只需要执行与其匹配的基础实现类或者扩展实现类即可，提高执行效率，保证了业务之间的隔离性。另外，当某个业务不再需要时，直接删除该业务关联的基础实现类和/或扩展实现类即可，对其他业务的实现不会造成影响，保证了应用系统的稳定性。

图9为本发明实施例提供的数据处理装置的结构示意图。本实施例的数据处理装置可以为软件和/或硬件的形式，该装置可以设置在服务端。如图9所示，本实施例提供的数据处理装置10，可以包括：获取模块11和处理模块12。

其中，获取模块11，用于获取业务请求，所述业务请求用于指示对第一业务的数据进行处理，所述业务请求包括所述第一业务的标识和请求参数；

处理模块12，用于根据所述第一业务的标识，从多个候选业务实现类中确定与所述第一业务匹配的第一业务实现类；

所述处理模块12，还用于根据所述请求参数执行所述第一业务实现类中的方法，得到所述业务请求对应的处理结果。

一种可能的实现方式中，所述第一业务实现类包括基础实现类和扩展实现类；所述处理模块12具体用于：根据所述请求参数，执行所述基础实现类的方法，并执行所述扩展实现类的方法，得到所述业务请求对应的处理结果。

一种可能的实现方式中，所述扩展实现类包括：多个一级扩展实现类；所述处理模块12具体用于：根据所述请求参数，从所述多个一级扩展实现类中确定与所述第一业务匹配的一级扩展实现类，并执行与所述第一业务匹配的一级扩展实现类中的方法。

一种可能的实现方式中，所述扩展实现类还包括：多个二级扩展实现类；所述处理模块12还具体用于：根据所述请求参数，从所述多个二级扩展实现类中确定与所述第一业务匹配的二级扩展实现类，并执行与所述第一业务匹配的二级扩展实现类中的方法。

一种可能的实现方式中，所述扩展实现类包括多个一级扩展实现类；所述处理模块12具体用于：

根据所述请求参数，执行所述基础实现类中的创建上下文方法、加载上下文方法，并执行所述扩展实现类中的加载上下文方法，得到所述第一业务对应的上下文信息；

根据所述请求参数，执行所述多个一级扩展实现类中的匹配上下文方法，根据执行结果从所述多个一级扩展实现类中确定出与所述第一业务匹配的一级扩展实现类；

根据所述第一业务对应的上下文信息，执行所述基础实现类中的业务处理方法，并执行与所述第一业务匹配的一级扩展实现类中的业务处理方法。

一种可能的实现方式中，所述扩展实现类还包括多个二级扩展实现类；所述处理模块12还具体用于：

根据所述请求参数，执行所述多个二级扩展实现类中的匹配上下文方法，根据执行结果从所述多个二级扩展实现类中确定出与所述第一业务匹配的二级扩展实现类；

根据所述第一业务对应的上下文信息，执行与所述第一业务匹配的二级扩展实现类中的业务处理方法。

一种可能的实现方式中，所述处理模块12还具体用于：执行所述基础实现类中的数据库处理方法。

一种可能的实现方式中，所述一级扩展实现类用于对所述基础实现类的功能进行扩展，所述二级扩展实现类用于对所述一级扩展实现类的功能进行扩展；或者，

所述一级扩展实现类用于对所述基础实现类的功能进行第一维度的扩展，所述二级扩展实现类用于对所述基础实现类的功能进行第二维度的扩展。

本实施例提供的数据处理装置，可用于执行上述任一方法实施例中的技术方案，其实现原理和技术效果类似，此处不作赘述。

图10为本发明实施例提供的电子设备的结构示意图。该电子设备可以作为服务端。如图10所示，本实施例的电子设备20，包括：处理器21以及存储器22；其中，存储器22，用于存储计算机程序；处理器21，用于执行存储器中存储的计算机程序，以实现上述实施例中的数据处理方法。具体可以参见前述方法实施例中的相关描述。

可选地，存储器22既可以是独立的，也可以跟处理器21集成在一起。

当所述存储器22是独立于处理器21之外的器件时，所述电子设备20还可以包括：总线23，用于连接所述存储器22和处理器21。

可选的，电子设备20还可以包括通信部件24，用于与客户端进行通信。

本实施例提供的电子设备，可用于执行上述任一方法实施例中的技术方案，其实现原理和技术效果类似，本实施例此处不再赘述。

本发明实施例还提供一种计算机可读存储介质，所述计算机可读存储介质包括计算机程序，所述计算机程序用于实现如上任一方法实施例中的技术方案。

本发明实施例还提供一种芯片，包括：存储器、处理器以及计算机程序，所述计算机程序存储在所述存储器中，所述处理器运行所述计算机程序执行上述任一方法实施例中的技术方案。

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

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

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

上述以软件功能模块的形式实现的集成的模块，可以存储在一个计算机可读取存储介质中。上述软件功能模块存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或处理器(英文：processor)执行本发明各个实施例所述方法的部分步骤。

应理解，上述处理器可以是中央处理单元(英文：Central Processing Unit，简称：CPU)，还可以是其他通用处理器、数字信号处理器(英文：Digital Signal Processor，简称：DSP)、专用集成电路(英文：Application Specific Integrated Circuit，简称：ASIC)等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合申请所公开的方法的步骤可以直接体现为硬件处理器执行完成，或者用处理器中的硬件及软件模块组合执行完成。

存储器可能包含高速RAM存储器，也可能还包括非易失性存储NVM，例如至少一个磁盘存储器，还可以为U盘、移动硬盘、只读存储器、磁盘或光盘等。

总线可以是工业标准体系结构(Industry Standard Architecture，ISA)总线、外部设备互连(Peripheral Component，PCI)总线或扩展工业标准体系结构(ExtendedIndustry Standard Architecture，EISA)总线等。总线可以分为地址总线、数据总线、控制总线等。为便于表示，本发明附图中的总线并不限定仅有一根总线或一种类型的总线。

上述存储介质可以是由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器(SRAM)，电可擦除可编程只读存储器(EEPROM)，可擦除可编程只读存储器(EPROM)，可编程只读存储器(PROM)，只读存储器(ROM)，磁存储器，快闪存储器，磁盘或光盘。存储介质可以是通用或专用计算机能够存取的任何可用介质。

一种示例性的存储介质耦合至处理器，从而使处理器能够从该存储介质读取信息，且可向该存储介质写入信息。当然，存储介质也可以是处理器的组成部分。处理器和存储介质可以位于专用集成电路(Application Specific Integrated Circuits，简称：ASIC)中。当然，处理器和存储介质也可以作为分立组件存在于电子设备或主控设备中。

本领域普通技术人员可以理解：实现上述各方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成。前述的程序可以存储于一计算机可读取存储介质中。该程序在执行时，执行包括上述各方法实施例的步骤；而前述的存储介质包括：ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本发明的其它实施方案。本发明旨在涵盖本发明的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本发明的一般性原理并包括本发明未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本发明的真正范围和精神由下面的权利要求书指出。

应当理解的是，本发明并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本发明的范围仅由所附的权利要求书来限制。