CN114637502A - 一种业务功能包的灵活组装的实现方法及系统 - Google Patents

Abstract

本发明公开了一种业务功能包的灵活组装的实现方法，包含以下步骤：根据一个或者多个相关的业务类型或者业务场景对业务功能包进行拆分，将业务功能包分为一级业务功能包、二级业务功能包……N级业务功能包，并发布在业务功能包市场；使用者从业务功能包市场按需选择业务功能包来构建应用，进行打包部署；打包部署的应用在启动时，自动上报所选择的业务功能包的相关信息；业务功能包管理控制台进行展示和管理。本发明的业务功能包通过配置项机制提高了可扩展性和可复用性，支持业务功能包扩展和叠加，减少了重复开发的交付时间；同时在应用运行期间，支持动态调整业务功能包的配置项选项，达到业务逻辑实时调整的目的。

Description

一种业务功能包的灵活组装的实现方法及系统

技术领域

本发明涉及应用开发领域，特别涉及一种业务功能包的灵活组装的实现方法及系统。

背景技术

在应用开发中，业务功能包是为了解决一个或者多个相关业务场景的API、DTO、配置项、SQL、代码等的组合，方便开发和安装维护等。

如果开发者可以对其他开发者提供的业务功能包进行扩展，或者选择多个业务功能包进行叠加，以便快速构建和部署应用，同时在应用运行期间可以动态的调整应用的配置项选项，这对企业而言，能够有效降低重复研发成本，减少重复开发的交付时间。

发明内容

本发明的主要目的在于克服现有技术的缺点与不足，提供一种业务功能包的灵活组装的实现方法。

本发明的另一目的在于提供一种业务功能包的灵活组装的实现系统。

本发明的目的通过以下的技术方案实现：

一种业务功能包的灵活组装的实现方法，包含以下步骤：

S1、根据一个或者多个相关的业务类型或者业务场景对业务功能包进行拆分，将业务功能包分为一级业务功能包、二级业务功能包……N级业务功能包，并发布在业务功能包市场；N≥2；

每个所述N-1级业务功能包下包含一个以上的N级业务功能包；所述N级业务功能包是实现所在的N-1级业务模块所对应的业务类型或者业务场景下的具体业务模块；通过业务功能包管理控制台来统一管理N-1级业务功能包和N级业务功能包之间的对应关系；

业务功能包业务功能包业务功能包业务功能包业务功能包业务功能包业务功能包业务功能包业务功能包业务功能包业务功能包S2、使用者从业务功能包市场按需选择业务功能包来构建应用，进行打包部署；

S3、打包部署的应用在启动时，自动上报所选择的业务功能包的相关信息，所述业务功能包的相关信息包括自描述文件、配置项、API、DTO；

S4、业务功能包管理控制台，展示和管理的内容包括：应用和业务功能包的关系、业务功能包之间的依赖关系、业务功能包的自描述文件、配置项、API、DTO。

例如，N＝2时，假设一级业务功能包是根据具体业务类型或者业务场景进行划分的，如团购业务功能包、秒杀业务功能包。例如，一共有M个业务功能包，在最开始，二级业务功能包则一定会是M个，但一级业务功能包的数量则不定，M个二级业务功能包分属于各个一级功能模块。即一个具体的业务功能包一定同时是某一类型的一级业务功能包以及二级业务功能包。同理，N＝3时，一共有M个业务功能包，在最开始，三级业务功能包则一定会是M个，但二级业务功能包的数量则不定，M个三级业务功能包分属于各个二级功能模块，二级业务功能包的数量不大于三级业务功能包的数量(M个)，一级业务功能包的数量不大于二级业务功能包的数量。即一个具体的业务功能包一定同时是某一类型的三级业务功能包以及二级业务功能包。N取其他值时，依次类推。

不同使用者之间是隔离的，使用者会不同的运行环境调参数，例如：是否要发布事件，则相应的配置项会设置的不一样。

为了规范化二级业务功能包的工程规范，每个所述二级业务功能包都是通过脚手架(没有具体业务的代码模版)生成初始工程，开发验证后发布到业务功能包市场中。

步骤S2中，所述打包部署的同时，扫描业务功能包的源代码，生成业务功能包的相关信息，所述业务功能包的相关信息包括自描述文件、配置项、API、DTO。

所述业务功能包通过配置项机制提高了可扩展性和可复用性，所述配置项包括业务参数、扩展点、领域事件。

所述配置项为扩展点，此时所述配置项机制为：一个扩展点包括多种扩展实现，在业务功能包的运行过程中，会基于当前运行环境的上下文信息运行不同的SPI扩展实现逻辑，以满足不同的业务场景；

所述当前运行环境的上下文信息包括当前的业务请求参数；

如果一个开发团队先开发了业务功能包module#1，业务功能包module#1包括一个扩展点SPI#1，这个扩展点SPI#1存在2种扩展实现；在业务发展过程中，另外的开发团队可以开发自己的业务功能包module#2(依赖业务功能包module#1)，对SPI#1进行扩展，增加新的扩展实现，然后发布和部署业务功能包module#2，其他开发团队可以基于业务功能包module#2进行扩展、增加新的扩展实现，以此类推叠加和复用。

所述配置项为业务参数，此时所述配置项机制为：当为业务场景时，订单下单后超时未支付则会取消订单，在业务功能包管理控制台可以设置超时的时间，超过该时间则自动取消订单；

业务功能包的业务参数配置项开发，分为5个阶段：

a、开发业务参数：在业务功能包中，按照一定的接口规范定义业务参数，提供统一的业务参数注解，标注在业务参数的定义上，用于描述业务参数的元数据信息；

b、编译打包业务功能包：编译业务功能包，扫描业务参数的注解信息，生成可执行的程序文件，程序文件中包含了该业务功能包中所有开发的业务参数信息；

c、部署运行业务功能包：业务功能包在启动时，会读取该模块内所有的业务参数信息，然后上报到管理控制台；

d、业务功能包管理控制台设置配置项值：业务管理人员，可以通过管理控制台浏览和设定每个业务参数的具体值；

e、业务流程读取具体配置项：执行到具体业务流程时，会查询该配置项的配置值，进行具体的业务规则执行，如获取下单未支付时长的设定值，然后设置定时器，如果超过该时间订单没有支付，则自动取消订单。

所述配置项为领域事件，此时所述配置项机制为：当为业务场景时，领域事件是当满足某个条件，通过通知机制，触发其他订阅该领域事件的应用进行下一步的业务处理；当用户中心(发布者)的用户注册是一个领域事件，消息中心(订阅者)订阅了用户注册事件，那么当用户注册完成后，用户中心会发布用户注册事件，消息系统会收到该事件，然后发送短信提醒用户注册成功。

统一所述配置项的定义规则，建立业务功能包配置项开发的标准规范。

所述配置项为扩展点，此时所述扩展点的定义规则包括：

(1)扩展点的元数据描述信息：提供了统一的注解，在扩展点上通过统一的注解描述扩展点的元数据信息，通过代码扫描获取扩展点的元数据信息并且入库；

(2)扩展点自身的定义：所有的扩展点通过继承统一的接口，标识出扩展点。

所述配置项为业务参数，此时所述业务参数的定义规则包括：业务参数继承统一的接口，标识这是一个业务参数，接口提供了统一的方法用于获取业务参数当前的设定值。

所述配置项为领域事件，此时所述领域事件的定义规则包括：领域事件消息体、事件发布者统一服务API、事件订阅者统一服务API。

所述应用运行期间，支持动态调整业务功能包的配置项选项，达到业务逻辑实时调整的目的。

所述配置项为扩展点时，动态调整业务功能包的配置项选项具体为：业务功能包中的扩展点和它的扩展实现都会被扫描入库，然后可以通过前端配置要执行的扩展实现；在业务功能包启动时，在扩展点的调用处，通过为扩展点生成代理对象，在代理对象中读取扩展点的配置(即当前要执行的扩展实现，可以为多个；当是多个时，可以设置串行或者并行执行)，然后调用扩展实现。

所述配置项为业务参数时，动态调整业务功能包的配置项选项具体为：当下单未支付超时时长，不是在业务功能包代码中设定一个具体的值(例如30min)，这会导致运行期间就只有一个值，无法线上动态调整；是在业务功能包运行期间，由系统管理人员先在管理控制台设置业务参数的具体取值，然后业务功能包去管理控制台查询设定的具体取值，达到运行期间动态调整业务参数的目的。

所述配置项为领域事件时，动态调整业务功能包的配置项选项具体为：业务场景中，以用户中心(发布者)的用户注册为例，消息中心(订阅者)和会员中心都订阅了用户注册事件，那么当用户注册完成后，用户中心会发布用户注册事件：

a、消息中心接收到该事件，然后发送短信提醒用户注册成功；

b、会员中心接收到该事件，免费赠送用户积分；

事件订阅者，都继承统一的领域事件监听器接口，那么在业务功能包编译打包时，会通过代码扫描的方式，在可执行程序文件中生成该业务功能包的所有订阅者信息；

在业务功能包启动时，会将所有的事件订阅者上报到管理控制台，管理员可以设置开启或者关闭事件订阅者；

在业务功能包接收到事件消息后，会查询管理控制台，如果该事件订阅者是开启状态，则继续处理下一步业务；如果该事件订阅者是关闭状态，则丢弃该消息不处理。

本发明的另一目的通过以下的技术方案实现：

一种业务功能包的灵活组装的实现系统，包含业务功能包市场、业务功能包管理控制台；其中，业务功能包市场用于发布一级业务功能包(分组用途)、二级业务功能包；使用者从业务功能包市场选取所需业务功能包之后，进行打包部署；业务功能包管理控制台来统一管理一级业务功能包和二级业务功能包之间的对应关系，同时对业务功能包的相关信息进行展示。

本发明与现有技术相比，具有如下优点和有益效果：

1、本发明的业务功能包通过配置项机制提高了可扩展性和可复用性，支持业务功能包扩展和叠加，减少了重复开发的交付时间。

2、本发明统一配置项的定义规则，建立业务功能包配置项开发的标准规范。

3、本发明支持应用按需组装与部署业务功能包。

4、本发明应用启动时自动执行业务功能包相关的DDL、DML，减少人工操作。

5、本发明支持应用自动上报所引用的业务功能包的自描述文件、配置项、API、DTO等信息，支持业务功能包信息的可视化。

6、本发明应用运行期间，支持动态调整业务功能包的配置项选项，达到业务逻辑实时调整的目的。

附图说明

图1是本发明所述一种业务功能包的灵活组装的实现系统的结构示意图；

图2是本发明所述基于业务场景分析和开发业务功能包的流程图；

图3是本发明所述构建和部署应用，以及注册上报业务功能包信息的流程图。

图4为业务功能包的业务参数配置项开发的流程图。

图5为动态化扩展中，领域事件与监听机制的工作示意图。

图6为基础认证二级业务功能包和密码安全二级业务功能包的部署方式示意图。

具体实施方式

下面结合实施例及附图对本发明作进一步详细的描述，但本发明的实施方式不限于此。

如图1，一种业务功能包的灵活组装的实现系统，包含业务功能包市场、业务功能包管理控制台；其中，业务功能包市场用于发布一级业务功能包(分组用途)、二级业务功能包；使用者从业务功能包市场选取所需业务功能包之后，进行打包部署；业务功能包管理控制台来统一管理一级业务功能包和二级业务功能包之间的对应关系，同时对业务功能包的相关信息进行展示。

业务功能包的开发和配置注册流程如下：

(1)如图2，基于业务场景分析和开发业务功能包：脚手架的作用是按照开发规范(例如命名规则等)，生成一个空壳工程，不包含具体的业务。此处是指先生成一个业务功能包的空壳工程，在空壳工程的基础上再开发自身的业务需求，自身的业务需求是每个项目特有的。

(2)管理控制台配置一级业务功能包和二级业务功能包的关系：例如交易领域的团购业务为一级业务功能包，包括2个二级业务功能包，分别是团购业务web前端实现(二级业务功能包)，团购业务交易中心实现(二级业务功能包)。

(3)如图3，构建和部署应用，以及注册上报业务功能包信息：

构建应用，是指根据脚手架先生成一个空壳应用(不包含任何业务功能包)，然后将选择的业务功能包引入到应用中，进行应用打包，生成可执行的程序文件。

部署运行，是指将上一步的应用程序文件部署到开发、生产等环境中。

上报业务功能包信息，是指上一步应用程序启动时，会将其包含的业务功能包中的元数据信息(包括DTO、API、配置项等)上报入库，基于入库的信息进行前端展示和设定，设定的值(例如设定一个扩展点要执行哪一个扩展实现逻辑)影响业务功能包的运行逻辑。

一种业务功能包的灵活组装的实现方法，包含以下步骤：

S1、根据一个或者多个相关的业务类型或者业务场景对业务功能包进行拆分，将业务功能包分为一级业务功能包(分组用途)、二级业务功能包，并发布在业务功能包市场；

每个所述一级业务功能包下包含一个以上的二级业务功能包；所述二级业务功能包是实现所在的一级业务模块所对应的业务类型或者业务场景下的具体业务模块；通过业务功能包管理控制台来统一管理一级业务功能包和二级业务功能包之间的对应关系；

S2、使用者从业务功能包市场按需选择业务功能包来构建应用，进行打包部署；

S3、打包部署的应用在启动时，自动上报所选择的业务功能包的相关信息，所述业务功能包的相关信息包括自描述文件、配置项、API、DTO；

S4、业务功能包管理控制台，展示和管理的内容包括：应用和业务功能包的关系、业务功能包之间的依赖关系、业务功能包的自描述文件、配置项、API、DTO。

一级业务功能包是根据具体业务类型或者业务场景进行划分的，如团购业务功能包、秒杀业务功能包。例如，一共有M个业务功能包，在最开始，二级业务功能包则一定会是M个，但一级业务功能包的数量则不定，M个二级业务功能包分属于各个一级功能模块。即一个具体的业务功能包一定同时是某一类型的一级业务功能包以及二级业务功能包。

不同使用者之间是隔离的，使用者会不同的运行环境调参数，例如：是否要发布事件，则相应的配置项会设置的不一样。

为了规范化二级业务功能包的工程规范，每个所述二级业务功能包都是通过脚手架(没有具体业务的代码模版)生成初始工程，开发验证后发布到业务功能包市场中。

步骤S2中，所述打包部署的同时，扫描业务功能包的源代码，生成业务功能包的相关信息，所述业务功能包的相关信息包括自描述文件、配置项、API、DTO。

所述业务功能包通过配置项机制提高了可扩展性和可复用性，所述配置项包括业务参数、扩展点、领域事件。

所述配置项为扩展点，此时所述配置项机制为：一个扩展点包括多种扩展实现，在业务功能包的运行过程中，会基于当前运行环境的上下文信息运行不同的SPI扩展实现逻辑，以满足不同的业务场景；

所述当前运行环境的上下文信息包括当前的业务请求参数；

如果一个开发团队先开发了业务功能包module#1，业务功能包module#1包括一个扩展点SPI#1，这个扩展点SPI#1存在2种扩展实现；在业务发展过程中，另外的开发团队可以开发自己的业务功能包module#2(依赖业务功能包module#1)，对SPI#1进行扩展，增加新的扩展实现，然后发布和部署业务功能包module#2，其他开发团队可以基于业务功能包module#2进行扩展、增加新的扩展实现，以此类推叠加和复用。

所述配置项为业务参数，此时所述配置项机制为：

以业务场景举例：订单下单后超时未支付则会取消订单，在业务功能包管理控制台可以设置超时的时间，超过该时间则自动取消订单。

如图4，业务功能包的业务参数配置项开发，分为5个阶段：

a、开发业务参数：在业务功能包中，按照一定的接口规范定义业务参数，提供统一的业务参数注解，标注在业务参数的定义上，用于描述业务参数的元数据信息。

b、编译打包业务功能包：编译业务功能包，扫描业务参数的注解信息，生成可执行的程序文件，程序文件中包含了该业务功能包中所有开发的业务参数信息。

c、部署运行业务功能包：业务功能包在启动时，会读取该模块内所有的业务参数信息，然后上报到管理控制台。

d、业务功能包管理控制台设置配置项值：业务管理人员，可以通过管理控制台浏览和设定每个业务参数的具体值。

e、业务流程读取具体配置项：执行到具体业务流程时，会查询该配置项的配置值，进行具体的业务规则执行，如获取下单未支付时长的设定值，然后设置定时器，如果超过该时间订单没有支付，则自动取消订单。

所述配置项为领域事件，此时所述配置项机制为：

如图5，以业务场景举例：领域事件是当满足某个条件，通过通知机制，触发其他订阅该领域事件的应用进行下一步的业务处理。例如用户中心(发布者)的用户注册是一个领域事件，消息中心(订阅者)订阅了用户注册事件，那么当用户注册完成后，用户中心会发布用户注册事件，消息系统会收到该事件，然后发送短信提醒用户注册成功。

统一所述配置项的定义规则，建立业务功能包配置项开发的标准规范。

所述配置项为扩展点，此时所述扩展点的定义规则包括：

(1)扩展点的元数据描述信息：提供了统一的注解，在扩展点上通过统一的注解描述扩展点的元数据信息，通过代码扫描获取扩展点的元数据信息并且入库；

(2)扩展点自身的定义：所有的扩展点通过继承统一的接口，标识出扩展点。

所述配置项为业务参数，此时所述业务参数的定义规则包括：业务参数继承统一的接口，标识这是一个业务参数，接口提供统一的方法用于获取业务参数当前的设定值。

业务参数通过统一的注解描述其元数据信息，描述信息包括业务参数编码、名称、描述、领域。

所述配置项为领域事件，此时所述领域事件的定义规则包括：领域事件的消息体，通过注解标注事件的元数据描述信息，包括领域事件编码、名称、描述、发送通道标识。

事件发布者调用统一的服务API(领域事件编码,领域事件消息体)，发送事件。

事件订阅者，继承统一的事件监听器接口，监听消费事件。

所述应用运行期间，支持动态调整业务功能包的配置项选项，达到业务逻辑实时调整的目的。

所述配置项为扩展点时，动态调整业务功能包的配置项选项具体为：业务功能包中的扩展点和它的扩展实现都会被扫描入库，然后可以通过前端配置要执行的扩展实现；在业务功能包启动时，在扩展点的调用处，通过为扩展点生成代理对象，在代理对象中读取扩展点的配置(即当前要执行的扩展实现，可以为多个；当是多个时，可以设置串行或者并行执行)，然后调用扩展实现。

所述配置项为业务参数时，动态调整业务功能包的配置项选项具体为：

以下单未支付超时时长为例，不是在业务功能包代码中设定一个具体的值(例如30min)，这会导致运行期间就只有一个值，无法线上动态调整。

业务参数，在业务功能包中只是提供了一个查询的接口，例如INotPaidDurationParam，INotPaidDurationParam继承于接口ICubeParam，ICubeParam提供了各类业务参数的统一读取方法。

在业务功能包启动时，会将业务参数INotPaidDurationParam上报到管理控制台，管理员可以设置业务参数INotPaidDurationParam的具体值。

在业务功能包启动时，会识别所有继承于ICubeParam的业务参数，为其生成代理对象。那么在调用INotPaidDurationParam#getValue()获取下单超时未支付时长时，代理对象实际是从管理控制台查询业务参数INotPaidDurationParam的设定值，然后INotPaidDurationParam#getValue()调用返回当前的设定值，到达动态调整业务参数的目的。

所述配置项为领域事件时，动态调整业务功能包的配置项选项具体为：

以业务场景为例：以用户中心(发布者)的用户注册为例，消息中心(订阅者)和会员中心都订阅了用户注册事件，那么当用户注册完成后，用户中心会发布用户注册事件：

a、消息中心接收到该事件，然后发送短信提醒用户注册成功。

b、会员中心接收到该事件，免费赠送用户积分。

事件订阅者，都继承统一的领域事件监听器接口，那么在业务功能包编译打包时，会通过代码扫描的方式，在可执行程序文件中生成该业务功能包的所有订阅者信息。

在业务功能包启动时，会将所有的事件订阅者上报到管理控制台，管理员可以设置开启或者关闭事件订阅者。

在业务功能包接收到事件消息后，会查询管理控制台，如果该事件订阅者是开启状态，则继续处理下一步业务；如果该事件订阅者是关闭状态，则丢弃该消息不处理。

下面更进一步，以具体的例子来说明“一种业务功能包的灵活组装的实现方法”整个技术方案：

以用户认证域为例，标准产品“基础认证二级业务功能包”提供的能力是当用户登录时，如果输错了密码，“基础认证二级业务功能包”总是返回失败，提示用户密码输入错误。

其他项目在使用“基础认证二级业务功能包”时，项目的需求是用户当天输入密码错误达到一定次数后，要锁定账号一段时间，“基础认证二级业务功能包”并不能满足项目需求，所以要结合项目自身的需求，并且按照配置项的方式对“基础认证二级业务功能包”进行扩展，基于“基础认证二级业务功能包”再开发一个新的模块“密码安全二级业务功能包”。然后以“基础认证二级业务功能包”，加上“密码安全二级业务功能包”的方式进行部署。

如图6，“基础认证二级业务功能包”和“密码安全二级业务功能包”的部署方式是，新建一个认证应用程序(空壳工程，无任何业务逻辑)，Maven引用“基础认证二级业务功能包”和“密码安全二级业务功能包”，然后部署运行该应用程序。

认证应用程序在启动时，会将其包含的业务功能包(“基础认证二级业务功能包”和“密码安全二级业务功能包”)中的元数据信息(包括DTO、API、配置项等)上报入库，基于入库的信息进行前端展示和设定，设定的值(设定一个扩展点要执行哪一个扩展实现逻辑，例如登录失败扩展点ILoginParamVerifyExt，设定其执行“密码安全二级业务功能包”中定义的登录失败SPI扩展增强实现：LoginParamVerifyEnhancedExtImpl，那么用户用户密码登录失败达到一定次数后会锁定账号)影响业务功能包的运行逻辑。

上述实施例为本发明较佳的实施方式，但本发明的实施方式并不受上述实施例的限制，其他的任何未背离本发明的精神实质与原理下所作的改变、修饰、替代、组合、简化，均应为等效的置换方式，都包含在本发明的保护范围之内。

Claims (16)

1.一种业务功能包的灵活组装的实现方法，其特征在于，包含以下步骤：

S1、根据一个或者多个相关的业务类型或者业务场景对业务功能包进行拆分，将业务功能包分为一级业务功能包、二级业务功能包……N级业务功能包，并发布在业务功能包市场；N≥2；

每个所述N-1级业务功能包下包含一个以上的N级业务功能包；所述N级业务功能包是实现所在的N-1级业务模块所对应的业务类型或者业务场景下的具体业务模块；通过业务功能包管理控制台来统一管理N-1级业务功能包和N级业务功能包之间的对应关系；

S2、使用者从业务功能包市场按需选择业务功能包来构建应用，进行打包部署；

S3、打包部署的应用在启动时，自动上报所选择的业务功能包的相关信息，所述业务功能包的相关信息包括自描述文件、配置项、API、DTO；

S4、业务功能包管理控制台，展示和管理的内容包括：应用和业务功能包的关系、业务功能包之间的依赖关系、业务功能包的自描述文件、配置项、API、DTO。

2.根据权利要求1所述业务功能包的灵活组装的实现方法，其特征在于，每个所述二级业务功能包都是通过脚手架生成初始工程，开发验证后发布到业务功能包市场中。

3.根据权利要求1所述业务功能包的灵活组装的实现方法，其特征在于，步骤S2中，所述打包部署的同时，扫描业务功能包的源代码，生成业务功能包的相关信息。

4.根据权利要求1所述业务功能包的灵活组装的实现方法，其特征在于，所述业务功能包通过配置项机制提高了可扩展性和可复用性，所述配置项包括业务参数、扩展点、领域事件。

5.根据权利要求4所述业务功能包的灵活组装的实现方法，其特征在于，所述配置项为扩展点，此时所述配置项机制为：一个扩展点包括多种扩展实现，在业务功能包的运行过程中，会基于当前运行环境的上下文信息运行不同的扩展实现逻辑，以满足不同的业务场景；

所述当前运行环境的上下文信息包括当前的业务请求参数；

如果一个开发团队先开发了业务功能包module#1，业务功能包module#1包括一个扩展点，这个扩展点存在2种扩展实现；在业务发展过程中，另外的开发团队可以开发自己的业务功能包module#2，对该扩展点进行扩展，增加新的扩展实现，然后发布和部署业务功能包module#2，其他开发团队可以基于业务功能包module#2进行扩展、增加新的扩展实现，以此类推叠加和复用。

6.根据权利要求4所述业务功能包的灵活组装的实现方法，其特征在于，所述配置项为业务参数，此时所述配置项机制为：当为业务场景时，订单下单后超时未支付则会取消订单，在业务功能包管理控制台可以设置超时的时间，超过该时间则自动取消订单；

业务功能包的配置项开发，分为5个阶段：

a、开发配置项：在业务功能包中，按照一定的接口规范定义配置项，如开发一个配置项“下单未支付超时时长”，提供统一的配置项注解，标注在配置项的定义上，用于描述配置项的元数据信息；

b、编译打包业务功能包：编译业务功能包，扫描配置项的注解信息，生成可执行的程序文件，程序文件中包含了该业务功能包中所有开发的配置项信息；

c、部署运行业务功能包：业务功能包在启动时，会读取该模块内所有的配置项信息，然后上报到管理控制台；

d、业务功能包管理控制台设置配置项值：业务管理人员，可以通过管理控制台浏览和设定每个配置项的具体值；

e、业务流程读取具体配置项：执行到具体业务流程时，会查询该配置项的配置值，进行具体的业务规则执行，如获取下单未支付时长的设定值，然后设置定时器，如果超过该时间订单没有支付，则自动取消订单。

7.根据权利要求4所述业务功能包的灵活组装的实现方法，其特征在于，所述配置项为领域事件，此时所述配置项机制为：当为业务场景时，领域事件是当满足某个条件，通过通知机制，触发其他订阅该领域事件的应用进行下一步的业务处理；当用户中心的用户注册是一个领域事件，消息中心订阅了用户注册事件，那么当用户注册完成后，用户中心会发布用户注册事件，消息系统会收到该事件，然后发送短信提醒用户注册成功。

8.根据权利要求1所述业务功能包的灵活组装的实现方法，其特征在于，统一所述配置项的定义规则，建立业务功能包配置项开发的标准规范。

9.根据权利要求8所述业务功能包的灵活组装的实现方法，其特征在于，所述配置项为扩展点，此时所述扩展点的定义规则包括扩展点的元数据描述信息、扩展点自身的定义。

10.根据权利要求8所述业务功能包的灵活组装的实现方法，其特征在于，所述配置项为业务参数，此时所述业务参数的定义规则包括：业务参数继承统一的接口，该接口用于获取业务参数当前的设定值；

业务参数描述其元数据信息。

11.根据权利要求8所述业务功能包的灵活组装的实现方法，其特征在于，所述配置项为领域事件，此时所述领域事件的定义规则包括：领域事件的消息体，标注事件的元数据描述信息，包括领域事件编码、名称、描述、发送通道标识；

事件发布者发送事件；

事件订阅者监听消费事件。

12.根据权利要求1所述业务功能包的灵活组装的实现方法，其特征在于，所述应用运行期间，支持动态调整业务功能包的配置项选项，达到业务逻辑实时调整的目的。

13.根据权利要求12所述业务功能包的灵活组装的实现方法，其特征在于，所述配置项为扩展点时，动态调整业务功能包的配置项选项具体为：业务功能包中的扩展点和它的扩展实现都会被扫描入库，然后可以通过前端配置要执行的扩展实现；在业务功能包启动时，在扩展点的调用处，通过为扩展点生成代理对象，在代理对象中读取扩展点的配置，然后调用扩展实现。

14.根据权利要求12所述业务功能包的灵活组装的实现方法，其特征在于，所述配置项为业务参数时，动态调整业务功能包的配置项选项具体为：

配置项在业务功能包中只是提供了一个查询的接口；

在业务功能包启动时，会将业务参数上报到管理控制台，管理员设置业务参数的具体值；

在业务功能包启动时，会识别业务参数，为其生成代理对象；在获取下单超时未支付时长时，代理对象实际是从管理控制台查询业务参数的设定值，然后调用返回当前的设定值，到达动态调整业务参数的目的。

15.根据权利要求12所述业务功能包的灵活组装的实现方法，其特征在于，所述配置项为领域事件时，动态调整业务功能包的配置项选项具体为：业务场景中，若用户中心的用户注册，消息中心和会员中心都订阅了用户注册事件，那么当用户注册完成后，用户中心会发布用户注册事件：

a、消息中心接收到该事件，然后发送短信提醒用户注册成功；

b、会员中心接收到该事件，免费赠送用户积分；

事件订阅者，在业务功能包编译打包时，在可执行程序文件中生成该业务功能包的所有订阅者信息；

在业务功能包启动时，会将所有的事件订阅者上报到管理控制台，管理员可以设置开启或者关闭事件订阅者；

在业务功能包接收到事件消息后，会查询管理控制台，如果该事件订阅者是开启状态，则继续处理下一步业务；如果该事件订阅者是关闭状态，则丢弃该消息不处理。

16.一种业务功能包的灵活组装的实现系统，其特征在于：包含业务功能包市场、业务功能包管理控制台；其中，业务功能包市场用于发布一级业务功能包、二级业务功能包；使用者从业务功能包市场选取所需业务功能包之后，进行打包部署；业务功能包管理控制台来统一管理一级业务功能包和二级业务功能包之间的对应关系，同时对业务功能包的相关信息进行展示。

Images