业务处理方法、装置、设备和计算机可读存储介质与流程

本申请涉及计算机应用技术领域，特别是涉及一种业务处理方法、装置、设备和计算机可读存储介质。

背景技术：

相关技术中的业务处理的系统通常包括服务平台和多个业务系统，通常由业务系统调用服务平台的某个api接口来实现某项业务处理。在一些情况下，多个业务系统在实现相同的业务处理时，可能会分别定义与该业务处理对应的接口，那么在服务平台上就需要分别实现这些业务系统定义的接口。

以服务平台a、业务系统b和业务系统c组成的业务处理系统为例：业务系统b和业务系统c都依赖于服务平台a的用户数据，即服务平台a存有业务系统b的用户数据，也存有业务系统c的用户数据。假设在服务平台a上有一个用户离职接口，当用户发生离职逻辑时，服务平台a需要在离职逻辑执行之后通知业务系统b和业务系统c，让业务系统b和业务系统c执行他们各自的关于离职之后的相关业务逻辑。在相关技术中，首先需要在服务平台a的代码中实现该离职用户属于业务系统b还是业务系统c的识别，然后再去调用对应业务系统的离职接口。因为业务系统b和业务系统c的离职接口都是业务系统自己定义的，接口并不一定相同，因此，服务平台a在实现离职接口时需要分别针对业务系统b和业务系统c各自写一份调用他们对应接口的代码。

由此可见，随着业务的不断发展、业务域(业务系统)越来越多、业务类型的不断增多以及不断添加的业务需求，使得服务平台的代码与各个业务系统的代码严重耦合而难以分离，各个业务系统之间的代码交织、难以拆解、也导致服务平台的代码臃肿。

针对相关技术中服务平台的代码与各个业务系统的代码严重耦合而难以分离的问题，尚未提出有效的解决方案。

技术实现要素：

基于此，本申请提供一种业务处理方法、装置、设备和计算机可读存储介质，用以解决相关技术中存在的服务平台的代码与各个业务系统的代码严重耦合而难以分离的问题。

第一方面，本申请提供一种业务处理方法，所述方法包括：

业务系统从服务平台获取spi接口的接口定义和用于实现所述spi接口所定义的sdk，以及用于标识所述spi接口的业务标识；

所述业务系统根据所述接口定义和所述sdk，实现与所述spi接口对应的服务，并将与所述spi接口对应的服务封装成api接口；

所述业务系统根据所述业务标识暴露所述api接口给所述服务平台，以供所述服务平台根据所述业务标识调用所述api接口。

在一种可能的实现方式中，所述业务系统根据所述业务标识暴露所述api接口给所述服务平台包括：

所述业务系统根据所述业务标识在dubbo上暴露所述api接口给所述服务平台。

在一种可能的实现方式中，所述业务系统根据所述接口定义和所述sdk，实现与所述spi接口对应的服务，并将所述spi接口对应的服务封装成api接口包括：

所述业务系统封装与所述接口定义对应的业务逻辑，得到与所述spi接口对应的服务；

所述业务系统通过dubbo将与所述spi接口对应的服务发布为api接口。

在一种可能的实现方式中，所述业务系统根据所述业务标识在dubbo上暴露所述api接口给所述服务平台包括：

所述业务系统通过dubbo的注解方式将所述api接口暴露给所述服务平台。

在一种可能的实现方式中，在业务系统从服务平台获取spi接口的接口定义和用于实现所述spi接口所定义的sdk之前，所述方法还包括：

所述服务平台获取所述业务系统的自定义需求；

所述服务平台根据所述自定义需求生成所述spi接口的接口定义和用于实现所述spi接口所定义的sdk。

在一种可能的实现方式中，在所述服务平台根据所述自定义需求生成所述spi接口的接口定义和用于实现所述spi接口所定义的sdk之后，所述方法还包括：

所述服务平台确定与所述spi接口对应的所述业务标识；

所述服务平台分配所述业务标识给所述业务系统，以供所述业务系统根据所述业务标识获取所述接口定义和用于实现所述spi接口所定义的sdk。

在一种可能的实现方式中，在所述业务系统根据所述业务标识在dubbo上暴露所述api接口给所述服务平台之后，所述方法还包括：

所述服务平台根据所述业务标识，通过dubbo发现并调用所述api接口。

第二方面，本申请提供一种业务处理装置，应用于业务系统，该装置包括：

获取模块，用于从服务平台获取spi接口的接口定义、用于实现所述spi接口所定义的sdk，以及用于标识所述spi接口的业务标识；

实现模块，用于根据所述接口定义和所述sdk，实现与所述spi接口对应的服务，并将与所述spi接口对应的服务封装成api接口；

暴露模块，用于根据所述业务标识暴露所述api接口给所述服务平台，以供所述服务平台根据所述业务标识调用所述api接口。

第三方面，本申请提供一种业务处理设备，该设备包括存储器、处理器，以及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现第一方面的业务处理方法。

第四方面，本申请提供一种计算机可读存储介质，该存储介质存储有计算机程序，所述计算机程序被处理器执行时实现第一方面的业务处理方法。

本申请提供的业务处理方法、业务处理装置、业务处理设备和计算机可读存储介质，通过业务系统从服务平台获取spi接口的接口定义、用于实现spi接口所定义的sdk，以及用于标识spi接口的业务标识；业务系统根据接口定义和sdk，实现与spi接口对应的服务，并将与spi接口对应的服务封装成api接口；业务系统根据业务标识暴露api接口给服务平台，以供服务平台根据业务标识调用api接口的方式，解决了相关技术中存在的服务平台的代码与各个业务系统的代码严重耦合而难以分离的问题，实现解耦系统依赖关系的有益效果。

本申请的一个或多个实施例的细节在以下附图和描述中提出，以使本申请的其他特征、目的和优点更加简明易懂。

附图说明

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

图1是根据本申请实施例的一种业务处理方法的流程图；

图2是根据本申请实施例的一种业务处理装置的结构框图；

图3是根据本申请实施例的一种业务处理设备的硬件结构示意图。

具体实施方式

为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行进一步详细说明。应当理解，此处描述的具体实施例仅仅用以解释本申请，并不用于限定本申请。基于本申请中的实例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实例，都属于本申请保护的范围。

显而易见地，下面描述中的附图仅仅是本申请的一些示例或实施例，对于本领域的普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图将本申请应用于其他类似情景。此外，还可以理解的是，虽然这种开发过程中所作出的努力可能是复杂并且冗长的，然而对于与本申请公开的内容相关的本领域的普通技术人员而言，在本申请揭露的技术内容的基础上进行的一些设计，制造或者生产等变更只是常规的技术手段，不应当理解为本申请公开的内容不充分。

在本申请中提及“实施例”意味着，结合实施例描述的特定特征、结构或特性可以包含在本申请的至少一个实施例中。在说明书中的各个位置出现该短语并不一定均是指相同的实施例，也不是与其它实施例互斥的独立的或备选的实施例。本领域技术人员显式地和隐式地理解的是，本文所描述的实施例可以与其它实施例相结合。

除非另作定义，权利要求书和说明书中使用的技术术语或者科学术语应当为本申请所属技术领域内具有一般技能的人士所理解的通常意义。本申请专利申请说明书以及权利要求书中使用的“一”、“一个”、“一种”、“该”等类似词语并不表示数量限制，可表示单数或复数。“包括”或者“包含”等类似的词语意指出现在“包括”或者“包含”前面的元件或者物件涵盖出现在“包括”或者“包含”后面列举的元件或者物件及其等同元件，并不排除其他元件或者物件。“连接”或者“相连”等类似的词语并非限定于物理的或者机械的连接，而是可以包括电气的连接，不管是直接的还是间接的。本申请专利申请说明书以及权利要求书中使用的“多个”是指两个或两个以上。“和/或”，描述关联对象的关联关系，表示可以存在三种关系，例如，a和/或b，可以表示：单独存在a，同时存在a和b，单独存在b这三种情况。字符“/”一般表示前后关联对象是一种“或”的关系。

本实施例应用于由服务平台和业务系统组成的系统中，尤其适用于由至少一个服务平台和多个业务系统组成的系统。通常，在上述系统中，业务平台使用服务平台的数据来实现具体的业务。

本实施例提供了一种业务处理方法，如图1所示，为根据本申请实施例的一种业务处理方法的流程图，该流程包括如下步骤：

步骤s102，业务系统从服务平台获取服务提供接口(serviceproviderinterface，简称为spi)的接口定义和用于实现spi接口所定义的软件开发工具包(softwaredevelopmentkit，简称为sdk)，以及用于标识所述spi接口的业务标识。

以一个服务平台和若干个业务系统组成的业务处理系统为例，业务系统依赖于服务平台的数据，通常，当用户在服务平台上执行完某个业务逻辑时，服务平台需要在业务逻辑执行之后通知若干个相关业务系统，让这几个业务系统执行他们各自的关于该业务逻辑之后的另外的相关业务逻辑。

在步骤s102中，服务平台上定义的spi接口是一种服务发现机制，业务系统可以通过spi接口定义发现某个实现业务逻辑的接口。服务平台定义的sdk中提供了实现spi接口所需要使用到的实现类，以及还可能提供范例、相关文档等用于实现上述的spi接口的文件。通过步骤s102，业务系统获得了实现api接口所需的信息。其中，实现类实例可以通过(serviceloader.load)方法获取。

步骤s104，业务系统根据接口定义和sdk，实现与spi接口对应的服务，并将与spi接口对应的服务封装成应用程序接口(applicationprogramminginterface，简称为api)。

比如，业务方引用通用服务平台定义的spi-sdk，实现与通用服务平台的自定义拓展服务相关的业务逻辑，并带上自己业务标识。

在本实施例中，业务系统根据从服务平台获取的spi接口的接口定义和用于实现该spi接口的sdk，实现与该spi接口对应的服务。为了服务平台能够调用该spi接口对应的服务，业务系统还将该spi接口对应的服务封装成api接口。

步骤s106，业务系统根据业务标识暴露api接口给服务平台，以供服务平台根据业务标识调用api接口。

通过该方法，业务系统从服务平台获取用于标识spi接口的业务标识，以使得在其实现与spi接口对应的服务，并将与spi接口对应的服务封装成api接口后，附着上与api接口对应的业务标识，并根据业务标识暴露api接口给服务平台。暴露的信息包括但不限于以下至少之一：ip地址、端口、服务名称(或者接口名称)、方法名称等。

在上述实施例中，服务平台可以根据需要实现的业务逻辑定义spi接口、配置用于实现spi接口所定义的sdk，并将spi接口的业务标识分配给对应的业务系统，从而由服务平台实现对业务拓展点的定义。业务系统在获得spi接口定义以及用于实现该spi接口所定义的sdk后，实现对应的服务，并将服务的业务标识再暴露给服务平台，以供服务平台根据业务标识调用由业务系统实现的服务，从而实现了由服务平台定义的业务拓展点。

通过上述步骤，业务系统引用服务平台定义的spi-sdk，实现并封装spi-sdk，即实现自己的业务逻辑，形成与spi-sdk对应的服务，通过dubbo将该服务暴露给服务平台。该方法解决了相关技术中存在的服务平台的代码与各个业务系统的代码严重耦合而难以分离的问题，通过插件化的开发解耦服务平台与业务系统的依赖关系，提升了交付效率。

在其中一些实施例中，在步骤s106中，业务系统根据业务标识在dubbo上暴露述api接口给服务平台。

在本实施例中，业务系统通过dubbo将api接口暴露给服务平台，以供服务平台调用该api接口。dubbo作为一种远程过程调用框架，能够在不同的服务器之间实现调用，而且能够提高项目的扩展性。

在本实施例中，提供了一个dubbo业务的工具服务，该dubbo业务的工具服务可以配置在服务平台和/或业务系统中，用于实现本实施例提供的全部或者部分方法。该工具服务包括但不限于以下至少之一的功能：

(1)具有spi暴露工具，便于业务系统往dubbo上暴露服务平台所拓展的自定义服务。

(2)具有spi服务获取工具，便于服务平台在业务逻辑执行中能通过业务标识来调用业务系统所实现的拓展的自定义服务。

(3)配置注解，便于服务平台获取不同业务系统的自定义需求，将获取的自定义需求抽象成可实现的接口，即定义spi-sdk；便于业务系统暴露带有自身业务标识的拓展的自定义服务。

在一个优选的实施例中，在步骤s106中，业务系统发布启动时，首先，可以通过构建spring-bean的方式对工具服务进行初始化，工具服务收集业务系统所实现的api接口，然后根据附着在api接口上的业务标识，在dubbo上根据api发布格式暴露api接口给服务平台，以声明提供该api接口对应的服务。

在其中一些实施例中，在步骤s104中，该方法还包括：业务系统封装与接口定义对应的业务逻辑，得到与spi接口对应的服务；业务系统通过dubbo将与spi接口对应的服务发布为api接口。

通过该方法，业务系统封装与接口定义对应的业务逻辑，可以使得不同业务系统实现自己的业务逻辑，业务系统通过dubbo将与spi接口对应的服务发布为api接口，以便于在步骤s106中，业务系统通过dubbo将api接口暴露给服务平台，以供服务平台调用api接口。

在其中一些实施例中，在步骤s106中，该方法还包括：业务系统通过dubbo的注解方式将api接口暴露给服务平台。

该方法通过注解方式，将api接口暴露给服务平台，不仅便于服务平台定义spi-sdk，同时还便于业务系统暴露附着有相应的业务标识的dubbo服务，以便于服务平台调用业务系统提供的dubbo服务。

在其中一些实施例中，在业务系统从服务平台获取spi接口的接口定义和用于实现spi接口所定义的sdk之前，该方法还包括：服务平台获取业务系统的自定义需求；服务平台根据自定义需求生成spi接口的接口定义和用于实现spi接口所定义的sdk。

通过该方法，服务平台获取不同业务系统的自定义需求，将获取的自定义需求抽象成可实现的接口，即定义spi-sdk，优选地，服务平台在定义spi-sdk后，将这些接口开放给业务系统，以拓展需要开放的自定义业务。

在其中一些实施例中，在服务平台根据自定义需求生成spi接口的接口定义和用于实现spi接口所定义的sdk之后，方法还包括：服务平台确定与spi接口对应的业务标识；服务平台分配业务标识给业务系统，以供业务系统根据业务标识获取接口定义和用于实现spi接口所定义的sdk。

通过该方法，在服务平台获取不同业务系统的自定义需求，将获取的自定义需求抽象成可实现的接口，即定义spi-sdk之后，服务平台确定与spi接口对应的业务标识，并分配业务标识给业务系统，以开放所拓展的自定义业务，使得业务系统根据业务标识获取接口定义和用于实现spi接口所定义的sdk，实现服务平台所拓展的自定义业务。这种由基础平台系统定义接口规范的方法，通过插件化的开发解耦服务平台与业务系统之间的依赖关系。

在其中一些实施例中，在业务系统根据业务标识在dubbo上暴露api接口给服务平台之后，该方法还包括：服务平台根据业务标识，通过dubbo发现并调用api接口。

通过该方法，服务平台根据业务逻辑中出现的业务标识，通过dubbo的referenceconfig，即使用工具服务的调用工具类来发现并调用业务系统暴露的api接口，以执行业务逻辑。

下面采用优选实施例对本申请实施例进行描述和说明。

以服务平台a、业务系统b和业务系统c组成的业务处理系统为例：业务系统b和业务系统c都依赖于服务平台a的用户数据，即服务平台a存有业务系统b的用户数据，也存有业务系统c的用户数据。假设在服务平台a上有一个用户离职接口，当用户发生离职逻辑时，服务平台a需要在离职逻辑执行之后通知业务系统b和业务系统c，让业务系统b和业务系统c执行他们各自的关于离职之后的相关业务逻辑。在相关技术中，首先需要在服务平台a的代码中实现该离职用户属于业务系统b还是业务系统c的识别，然后再去调用对应业务系统的离职接口。因为业务系统b和业务系统c的离职接口都是业务系统自己定义的，接口并不一定相同，因此，服务平台a在实现离职接口时需要分别针对业务系统b和业务系统c各自写一份调用他们对应接口的代码。

在本申请所提供的业务处理方法中，可以使用dubbo业务的工具服务，服务平台a只需要定义离职接口，由业务系统b和业务系统c各自去引用实现服务平台a所定义的离职接口，服务平台a就可以不需要再去写调用业务系统b和业务系统c的对应的离职接口了，因为接口已经被统一了。dubbo业务的工具服务会在业务执行中去根据业务标识去调用业务系统b或者业务系统c的离职接口。

若之后再有业务系统d接入的时候，服务平台a也不需要在自己的逻辑里面添加调用业务系统d离职接口的代码了。业务系统d业务只要引用实现服务平台a所定义的离职接口，dubbo业务的工具服务会在业务执行中去根据业务标识去调用所对应的离职接口，减少了服务平台a的业务耦合。服务平台a定义了拓展接口(离职接口)后，在对接新的业务系统只需要业务系统实现该拓展接口即可，服务平台a不需要重新发布，从而减少了服务平台和业务系统间的api交互，提升了业务的规范性。

总结以上优选实施例：服务平台a模型定义了一套spi-sdk，需要业务系统b、业务系统c或者其他业务系统去实现这套sdk，并将实现的api接口在dubbo上暴露,然后服务平台a在业务逻辑运行中根据业务场景标识在业务逻辑执行中选择性地调用业务系统b系统或者业务系统c所提供的dubbo业务的工具服务，即方便服务平台和业务系统在dubbo上的业务spi接口的暴露、发现、调用的工具。

通过上述优选实施例可知，本申请提供的业务处理方法可以通过向抽象模型中注入各个不同域业务化的数据，保障基础模型稳定的情况下也支持业务的拓展，将冗余的业务系统逻辑做成规范化的接口，让业务系统通过spi来实现这部分逻辑的服务外化，以此来降低基础服务于业务服务的耦合性。

在本实施例中还提供了一种业务处理装置，应用于业务系统，该装置用于实现上述实施例及优选实施例方式，已经进行过说明的不再赘述。如以下所使用的，术语“模块”、“子模块”可以实现预定功能的软件和/或硬件的组合。尽管以下实施例所描述的系统较佳地以软件来实现，但是硬件，或者软件和硬件的组合的实现也是可能并被构想的。

图2是根据本申请实施例的一种业务处理装置的结构框图，如图2所示，该装置包括：获取模块202，实现模块204，暴露模块206，其中，

获取模块202，用于从服务平台获取spi接口的接口定义、用于实现spi接口所定义的sdk，以及用于标识所述spi接口的业务标识；

实现模块204，耦合至获取模块202，用于根据接口定义和sdk，实现与spi接口对应的服务，并将与spi接口对应的服务封装成api接口；

暴露模块206，耦合至实现模块204，用于根据业务标识暴露api接口给服务平台，以供服务平台根据业务标识调用api接口。

在其中一些实施例中，获取模块206，用于从服务平台获取用于标识spi接口的业务标识。

在其中一些实施例中，暴露模块206，用于根据业务标识在dubbo上暴露api接口给服务平台，以供服务平台根据业务标识调用api接口。

在其中一些实施例中，实现模块204还包括：封装子模块，用于封装与接口定义对应的业务逻辑，得到与spi接口对应的服务；发布子模块，用于通过dubbo将与spi接口对应的服务发布为api接口。

在其中一些实施例中，暴露模块206，用于通过dubbo的注解方式将api接口暴露给服务平台。

在其中一些实施例中，装置还包括：第二获取模块，用于获取业务系统的自定义需求；生成模块，用于根据自定义需求生成spi接口的接口定义和用于实现spi接口所定义的sdk。

在其中一些实施例中，装置还包括：确定模块，用于确定与spi接口对应的业务标识；分配模块，用于分配业务标识给业务系统，以根据业务标识获取接口定义和用于实现spi接口所定义的sdk。

在其中一些实施例中，装置还包括：发现模块，用于根据业务标识，通过dubbo发现api接口；调用模块，用于根据业务标识，通过dubbo调用api接口。

另外，结合图1描述的本申请实施例的业务处理方法可以由业务处理设备来实现。图3示出了本申请实施例提供的业务处理设备的硬件结构示意图。

业务处理设备可以包括处理器301以及存储有计算机程序指令的存储器302。

具体地，上述处理器301可以包括中央处理器(cpu)，或者特定集成电路(applicationspecificintegratedcircuit，asic)，或者可以被配置成实施本申请实施例的一个或多个集成电路。

存储器302可以包括用于数据或指令的大容量存储器。举例来说而非限制，存储器302可包括硬盘驱动器(harddiskdrive，hdd)、软盘驱动器、闪存、光盘、磁光盘、磁带或通用串行总线(universalserialbus，usb)驱动器或者两个或更多个以上这些的组合。在合适的情况下，存储器302可包括可移除或不可移除(或固定)的介质。在合适的情况下，存储器302可在数据处理装置的内部或外部。在特定实施例中，存储器302是非易失性固态存储器。在特定实施例中，存储器302包括只读存储器(rom)。在合适的情况下，该rom可以是掩模编程的rom、可编程rom(prom)、可擦除prom(eprom)、电可擦除prom(eeprom)、电可改写rom(earom)或闪存或者两个或更多个以上这些的组合。

处理器301通过读取并执行存储器302中存储的计算机程序指令，以实现上述实施例中的任意一种业务处理方法。

在一个示例中，业务处理设备还可以括通信接口303和总线300。其中，如图3所示，处理器301、存储器302、通信接口303通过总线300连接并完成相互间的通信。

通信接口303，主要用于实现本申请实施例中各模块、装置、单元和/或设备之间的通信。

总线300包括硬件、软件或两者，将业务处理设备的部件彼此耦接在一起。举例来说而非限制，总线可包括加速图形端口(agp)或其他图形总线、增强工业标准架构(eisa)总线、前端总线(fsb)、超传输(ht)互连、工业标准架构(isa)总线、无限带宽互连、低引脚数(lpc)总线、存储器总线、微信道架构(mca)总线、外围组件互连(pci)总线、pci-express(pci-x)总线、串行高级技术附件(sata)总线、视频电子标准协会局部(vlb)总线或其他合适的总线或者两个或更多个以上这些的组合。在合适的情况下，总线110可包括一个或多个总线。尽管本申请实施例描述和示出了特定的总线，但本申请考虑任何合适的总线或互连。

该业务处理设备可以基于获取到的spi接口的接口定义、用于实现spi接口所定义的sdk，以及用于标识spi接口的业务标识，执行本申请实施例中的业务处理方法，从而实现结合图1描述的业务处理方法。

另外，结合上述实施例中的业务处理方法，本申请实施例可提供一种计算机可读存储介质来实现。该计算机可读存储介质上存储有计算机程序指令；该计算机程序指令被处理器执行时实现上述实施例中的任意一种业务处理方法。

以上实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。

以上所述实施例仅表达了本申请的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对本申请专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本申请构思的前提下，还可以做出若干变形和改进，这些都属于本申请的保护范围。因此，本申请专利的保护范围应以所附权利要求为准。