一种服务内部或跨服务调用的事件总线框架方法及系统

技术领域

本发明属于软件技术领域，尤其涉及一种服务内部或跨服务调用的事件总线框架方法及系统。

背景技术

事件总线是一种单点发布，多点触发的事件流模型，它存在于现代软件设计的多种场景。是一种事件发布订阅结构，通过发布订阅的模式可以解耦不同的架构层级，同时解决业务之间的耦合。

事件总线存在三种必要元素：

1.定义事件(事件模型)

2.订阅事件(订阅者)

3.发布事件(发布者)

它的存在可以解耦业务逻辑，使得软件耦合度降低，基于事件通知形式处理相关业务。降低软件耦合度，提升复杂软件系统扩展性。

但是目前的事件总线模型的软件系统往往存在以下一个或多个问题：软件系统理解成本很高、获取方式不够统一便捷、安全性不够、实现较为繁琐、无法进行消息排队。

基于以上，本申请提供了解决以上技术问题的技术方案。

发明内容

本发明的第一目的是获得一种软件本发明的第二目的是获得一种软件系统理解成本低、获取方式统一便捷、安全性高、实现简单、和/或可进行消息排队的事件总线框架系统。

本发明的第三目的是获得一种采用软件系统理解成本低、获取方式统一便捷、安全性高、实现简单、和/或可进行消息排队的事件总线框架方法的电子设备。

本发明的第四目的是获得采用软件系统理解成本低、获取方式统一便捷、安全性高、实现简单、和/或可进行消息排队的事件总线框架方法的计算机可读存储介质。

本发明第一方面提供一种服务内部或跨服务调用的事件总线框架方法，所述事件总线包括事件模型、订阅者和发布者，所述事件总线框架方法包括如下定义步骤：

定义进程内事件模型接口；定义发布方法；定义配置中心；定义事件中心；定义订阅者接口约束；和定义约束特性；其中，上述定义中，将发布者和订阅者的订阅关系和事件关系进行绑定，

所述事件总线框架方法还包括打包步骤，包括：将上述定义步骤的代码进行打包，得到打包文件；

所述事件总线框架方法还包括可以任选的分发步骤，包括将所述打包文件上传至分发中心。

在本发明的一个具体实施方式中，定义进程内事件模型接口时，标识项目里面的“模型”以继承“事件模型接口”。

在本发明的一个具体实施方式中，所述定义发布方法包括定义进程内接口方法和定义跨进程发布订阅。

在本发明的一个具体实施方式中，所述定义进程内接口方法约束了发布时“只允许发布约束的事件模型”的事件。

在本发明的一个具体实施方式中，所述定义跨进程发布订阅重载了发布方法。

在本发明的一个具体实施方式中，实行全框架适用的统一化配置方案。

在本发明的一个具体实施方式中，事件中心可以包括对进程内事件模型进行定义，以及对跨进程事件模型进行定义。

在本发明的一个具体实施方式中，所述发布者和订阅者的订阅关系的绑定中，是利用时间模型的命名空间和类名在项目里唯一的特性。

更具体的，通过事件模型的【命名空间+模型的类型全称】绑定发布者和订阅者之间的关系。

在本发明的一个具体实施方式中，所述发布者和订阅者的事件关系的绑定中，跨实例或跨服务的通讯利用消息队列的通讯管道的特性。

更具体的，所述跨实例或跨服务的通讯利用消息队列的通讯管道的特性是，采用Kafka的Topic或者Redis的Channel。

在本发明的一个具体实施方式中，对跨进程事件模型进行定义时，将消息发送到消息中间件。

更具体的，例如，通过topic将消息发送到消息中间件。

在本发明的一个具体实施方式中，定义订阅者接口约束时，可以约束统一的调用。

更具体的，可以约束订阅者必须实现的方法。

在本发明的一个具体实施方式中，定义约束特性时，可以定义框架有统一的标记方式。

更具体的，可以标识订阅者消费的目标Topic，并且框架有统一的标记方式。

在本发明的一个具体实施方式中，所述定义配置中心中，采用C#语言的特性标签进行简化配置，或Java语言的@注解的形式简化配置。

在本发明的一个具体实施方式中，所述分发步骤中，采用Nuget或独立部署的Nexus平台分发给各个服务该项能力。

在本发明的一个具体实施方式中，还包括：将中间件技术依赖注入到项目中。

更优选的，所述注入方式包括通过.Net的DI注入方式或AutoFac的DI注入方式。

本发明的第二方面提供一种服务内部或跨服务调用的事件总线框架系统，所述事件总线包括事件模型、订阅者和发布者，所述事件总线框架系统包括如下定义模块：

进程内事件模型接口定义模块；发布方法定义模块；配置中心定义模块；事件中心定义模块；订阅者接口约束定义模块；约束特性定义模块；其中，上述定义模块中，设置为将发布者和订阅者的订阅关系和事件关系进行绑定，

所述事件总线框架系统还包括打包模块，设置为包括：将上述定义步骤的代码进行打包，得到打包文件；

所述事件总线框架方法还包括分发模块，设置为包括将所述打包文件上传至分发中心。

在本发明的一个具体实施方式中，进程内事件模型接口定义模块中，设置为标识项目里面的“模型”以继承“事件模型接口”。

在本发明的一个具体实施方式中，所述发布定义模块设置为：包括定义进程内接口方法和定义跨进程发布订阅。

在本发明的一个具体实施方式中，设置为所述进程内接口方法约束了发布时“只允许发布约束的事件模型”的事件。

在本发明的一个具体实施方式中，所述跨进程发布订阅模块设置为：重载了发布方法。

在本发明的一个具体实施方式中，设置为实行全框架适用的统一化配置方案。

在本发明的一个具体实施方式中，事件中心定义模块设置为：可以包括对进程内事件模型进行定义，以及对跨进程事件模型进行定义。

在本发明的一个具体实施方式中，设置为：所述发布者和订阅者的订阅关系的绑定中，利用时间模型的命名空间和类名在项目里唯一的特性。

更具体的，设置为通过事件模型的【命名空间+模型的类型全称】绑定发布者和订阅者之间的关系。

在本发明的一个具体实施方式中，所述发布者和订阅者的事件关系的绑定中设置为：跨实例或跨服务的通讯利用消息队列的通讯管道的特性。

更具体的，所述跨实例或跨服务的通讯利用消息队列的通讯管道的特性设置为，采用Kafka的Topic或者Redis的Channel。

在本发明的一个具体实施方式中，设置为：对跨进程事件模型进行定义时，将消息发送到消息中间件。

更具体的，例如，设置为通过topic将消息发送到消息中间件。

在本发明的一个具体实施方式中，所述订阅者接口约束定义模块设置为：可以约束统一的调用。

更具体的，设置为可以约束订阅者必须实现的方法。

在本发明的一个具体实施方式中，所述约束特性定义模块设置为，可以定义框架有统一的标记方式。

更具体的，设置为：可以标识订阅者消费的目标Topic，并且框架有统一的标记方式。

在本发明的一个具体实施方式中，所述配置中心定义模块设置为，采用C#语言的特性标签进行简化配置，或Java语言的@注解的形式简化配置。

在本发明的一个具体实施方式中，所述分发模块设置为，设置为采用Nuget或独立部署的Nexus平台分发给各个服务该项能力。

在本发明的一个具体实施方式中，还设置为：包括将中间件技术依赖注入到项目中。

更优选的，所述注入方式设置为包括通过.Net的DI注入方式或AutoFac的DI注入方式。

本发明的第三方面提供一种电子设备，包括：

处理器；

用于存储处理器可执行指令的存储器；

其中，所述处理器被配置为调用所述存储器存储的指令，以执行本发明所述事件总线框架的方法。

本发明第四方面提供一种计算机可读存储介质，其上存储有计算机程序指令，所述计算机程序指令被处理器执行时实现本发明所述事件总线框架的方法。

本发明能够带来以下至少一种有益效果：

1、提供一种分布式微服务事件发布订阅机制。

2、提供同进程事件的发布订阅模型的新型依赖关系。

3、提供一种统一便捷的获取方式，例如通过将事件总线类库打包的形式发布到分发平台，降低使用成本。

4、一次配置，全局使用，提升研发效能。

5、提升研发效率、降低研发难度、降低理解成本、降低软件工程复杂度。

附图说明

下面将以明确易懂的方式，结合附图说明优选实施方式，对上述特性、技术特征、优点及其实现方式予以进一步说明。

图1为现有技术中的进程内的事件风暴和跨服务容器的事件风暴的问题场景。

图2为现有技术采用事件总线模型降低软件耦合度的场景。

图3为本发明的示例性的事件总线框架的一个具体实施方式。

具体实施方式

以下对本发明的各个方面进行进一步详述。

除非另有定义或说明，本文中所使用的所有专业与科学用语与本领域技术熟练人员所熟悉的意义相同。此外任何与所记载内容相似或均等的方法及材料皆可应用于本发明方法中。

以下对术语进行说明。

除非另有明确的规定和限定，本发明中所述的“或”，包含了“和”的关系。所述“和”相当于布尔逻辑运算符“AND”，所述“或”相当于布尔逻辑运算符“OR”，而“AND”是“OR”的子集。

可以理解到，尽管术语“第一”、“第二”等等可以在此用来说明不同的元件，但是这些元件不应被这些术语限制。这些术语仅仅用来将一个元件与另一个元件区分开。因此，第一元件可以被称为第二元件，而不背离本发明构思的教导。

本发明中，术语“含有”、“包含”或“包括”表示各种成分可一起应用于本发明的混合物或组合物中。因此，术语“主要由...组成”和“由...组成”包含在术语“含有”、“包含”或“包括”中。

除非另有明确的规定和限定，本发明的术语“相连”、“连通”、“连接”应作广义理解，例如，可以是固定连接，也可以是通过中介媒介间相连，可以是两个元件内部的连通或者两个元件的相互作用关系。对于本领域的普通技术人员而言，可以根据具体情况理解上述术语在本申请中的具体含义。

本发明的其它方面由于本文的公开内容，对本领域的技术人员而言是显而易见的。

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对照附图说明本发明的具体实施方式。显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图，并获得其他的实施方式。

还需要说明的是，以下实施例中所提供的图示仅以示意方式说明本申请的基本构想，图式中仅显示与本申请中有关的组件而非按照实际实施时的组件数目、形状及尺寸绘制，其实际实施时各组件的型态、数量及比例可为一种随意的改变，且其组件布局型态也可能更为复杂。例如，在附图中的元件的厚度可以为了清楚性起见而被夸张。

实施例

目前的事件总线框架中，以下是几种常见的导致新问题的场景，以及为解决新问题而采用的对应解决措施的处理方案：

场景一、现有技术中采用事件总线模型处理事件风暴的优点

如图1所示，示出了进程内的事件风暴和跨服务容器的事件风暴。

如图2所示，示出了采用事件总线模型的存在，可以解耦业务逻辑，使得软件耦合度降低，基于事件通知形式处理相关业务。降低软件耦合度，提升复杂软件系统扩展性。

通常事件总线类型分为两种：进程内事件和跨进程事件。事件总线模型通常存在三种必要元素：

1.定义事件(事件模型)

2.订阅事件(订阅者)

3.发布事件(发布者)

场景二、采用事件总线模型导致的不可控性

当前云原生体系下的分布式系统的事件通知机制一般有两种形式：直接调取和通过消息队列中间件。

当采用直接调取作为事件通知机制时，直接调取的方式很难做到同服务不同实例间通讯，且对其他服务产生模块依赖，依赖关系的复杂又会增加项目的复杂程度，导致后续软件的扩展性变差。而且由于不同服务器间存在带宽瓶颈的问题，那么直接调取的方式就必然会产生一个不确定性，就是被调取方状态不确定，那么对于云计算平台来讲不可控就是系统最大的风险。所以需要可控的一个平台来解决这样的问题，而一般解决这类问题的通用方案都是采取消息队列的形式如：KafKa、RabbitMQ、RocketMQ、或RedisPubSub的形式来解决此一类共性问题。使用这样的方案之后，带宽瓶颈就成了确定的事情，为横向扩展提供了稳定可靠的数据依据和参考前提。

显然，这种解决方式需要额外的可控的一个平台将这些消息队列的第三方中间件都集成到一个统一的框架下，方便日后若技术标准和技术选型发生了根本的变化时可以轻易的调整。因此，需要为避免日后遇到这样的技术困境提供方案。

场景三、采用事件总线模型导致的易用性和架构复杂度的问题

如前所述，当前云原生体系下的分布式系统的事件通知机制一般有两种形式：直接调取和通过消息队列中间件。

当采用消息队列中间件作为事件通知机制是目前的主流方案，因为该方案能解耦服务之间的耦合，且对于本服务不同实例间存在的通讯需求可以满足。但是存在一个易用性和架构复杂度的问题。常规操作都是通过一个消息中间件的驱动类库，然后实例化一个通讯对象后对该对象进行各种配置，最后再通过该对象将需要发布的消息发布到中间件。

而该方式必然产生的问题就是，创造这样一个对象的过程要反复写在不同的应用场景下，而且不同消息中间件又存在不同的通讯方式和配置方案。这样就会导致项目如果使用了一套消息中间件之后架构就会被绑架在该中间件下，这个时候如果出现新的消息中间件，或者又存在新的技术方案，软件结构的优化无从谈起，且随着老的消息中间件的没落，项目维护的难度就会变得越来越差。

本发明的技术构思

综上所述，现有技术具有软件系统理解成本很高、获取方式不够统一便捷、安全性不够、实现较为繁琐、无法进行消息排队的一个或多个问题。

发明人分析了现有技术的各种场景，确定现有技术存在的主要缺陷，除了包括场景一至三指出的缺陷，还可能包括以下各种场景中的缺陷：

1-需要解决分布式微服务下，同服务不同实例之间的跨容器通讯。

2-进程内事件的依赖关系设计复杂，造成软件系统理解成本很高。

3-没有统一便捷的获取方式。

4-使用麻烦并将细节暴漏给用户，无法体现事件总线的价值，反而给研发工作带来了不必要的风险。

5-实现繁琐，无法快速上手微服务通讯。

6-无法进行消息排队，不能防止线程过多的创建。

为此，本发明的发明人需要解决的技术问题为：

1、分布式微服务事件发布订阅机制；

2、同进程事件的发布订阅模型的新型依赖关系；

3、统一便捷的获取方式，通过将事件总线类库打包的形式发布到分发平台，降低使用成本；

4、一次配置，全局使用，提升研发效能。

5、提升研发效率、降低研发难度、降低理解成本、降低软件工程复杂度本发明中，发明人经过了广泛和深入的试验，本发明采用的技术构思包括：

1-进行发布者和订阅者订阅关系的绑定，例如进程内利用【业务模型】(即：事件模型)的命名空间+类名在项目里唯一的特性；

2、进行发布者和订阅者的事件关系绑定，例如跨实例或跨服务的通讯利用消息队列的通讯管道的特性(例如：Kafka的Topic或者Redis的Channel)；

3、简化配置操作，例如利用；来进行，具体可见如下的操作说明；

4、分发给各个服务该项能力，例如利用Nuget平台；

5、利用中间件技术依赖注入到项目中，例如可以通过.Net的常规DI注入方式和AutoFac的DI注入方式

6、配置式事件总线的事件总线实现方案。

本发明与常规的事件总线框架方法和系统相比，采用本发明所涉及到的技术方案，可以很好的解决上述的技术问题。

结论：本发明的事件总线框架方法和系统面对所述技术问题，很好的解决了现有技术中的缺陷，获得了显著的技术效果。

实施例

如图3所示，本发明的示例性的事件总线框架的一个具体实施方式。本发明提供了一种服务内部或跨服务调用的事件总线框架方法，所述事件总线包括事件模型、订阅者和发布者，所述事件总线框架方法包括如下定义步骤：

定义进程内事件模型接口；定义发布方法；定义配置中心；定义事件中心；定义订阅者接口约束；定义约束特性；其中，上述定义中，将发布者和订阅者的订阅关系和事件关系进行绑定，

所述事件总线框架方法还包括打包步骤，包括：将上述定义步骤的代码进行打包，得到打包文件。

具体而言，当对进程内接口事件模型方法进行定义时，可以标识项目里面的【模型】继承【事件模型接口】，从而达到【标识事件模型】的目的。

在本发明的一个具体实施方式中，所述定义步骤中，所述定义发布方法包括定义进程内接口方法和定义跨进程发布订阅。

具体而言，所述定义发布方法中的定义进程内接口方法约束了发布时【只允许发布约束的事件模型】的事件，从而避免了误用，从编译层面提升了项目质量。

具体而言，所述定义发布方法中的定义跨进程发布订阅重载了发布方法，简化了调用的复杂程度而且与进程；兼容了市面上绝大多数的应用场景；减少耗时，以异步的形势可以提升吞吐量。

具体而言，本发明的定义配置中心可以实现统一化的配置方案，一处配置，全框架适用。

具体而言，本发明的事件中心可以包括对进程内事件模型进行定义，以及对跨进程事件模型进行定义。

在本发明的一个具体实施方式中，所述定义步骤所述发布者和订阅者的订阅关系的绑定中，是利用时间模型的命名空间和类名在项目里唯一的特性。

更具体的，对进程内事件模型进行定义时，例如，通过事件模型的【命名空间+模型的类型全称】绑定发布者和订阅者之间的关系。传统方式是通过标识字符串的形式绑定关系，而这里采用了【命名空间+模型的类型全称】的方式，简化了使用成本，提升了研发效率。结合发布者的类型约束，进而提升了项目质量。

更具体的，对跨进程事件模型进行定义时，例如，通过topic将消息发送到消息中间件，并代替用户监视异常。简化了以往每发一个消息都需要写一遍监听异常的操作。

在本发明的一个具体实施方式中，所述定义步骤所述发布者和订阅者的事件关系的绑定中，跨实例或跨服务的通讯利用消息队列的通讯管道的特性。

在本发明的一个具体实施方式中，所述跨实例或跨服务的通讯利用消息队列的通讯管道的特性是，采用Kafka的Topic或者Redis的Channel。

具体而言，定义订阅者接口约束时，可以约束订阅者必须实现的方法，从而有了统一的调用方式。并且泛型约束了事件模型。从而绑定了订阅者和事件模型的关系。从而让订阅者处理事件时可以直接拿到需要处理的事件模型。简化了操作，提升了效率，约束了风险。为事件总线在项目里面的全面铺开提供了前提。

具体而言，定义约束特性时，可以标识订阅者消费的目标Topic，并且框架有了统一的标记方式。简化了历史复杂度。还可以有更多的优点，请参见图3第五步的具体描述。

在本发明的一个具体实施方式中，所述定义步骤的所述配置中心中，采用C#语言的特性标签进行简化配置。

在本发明的一个具体实施方式中，所述事件总线框架方法还包括分发步骤，包括将所述打包文件上传至分发中心。

在本发明的一个具体实施方式中，所述分发步骤中，采用Nuget平台分发给各个服务该项能力。

在本发明的一个具体实施方式中，所述分发步骤中，采用独立部署的Nexus平台分发给各个服务该项能力。

在本发明的一个具体实施方式中，还包括：将中间件技术依赖注入到项目中。

例如，所述注入方式包括通过.Net的DI注入方式或AutoFac的DI注入方式。

为了更清楚地对上述内容进行描述，结合图3的具体实施方式对本发明进行一个示例性的展示，本领域技术人员可以根据实际场景进行各种要素的变更和替换。

第一步：定义进程内事件模型接口

例如：publicinterfaceIBusinessModel{}

好处：可以标识项目里面的【模型】继承【事件模型接口】，从而达到【标识事件模型】的目的。

第二步：定义发布方法

1.定义进程内接口方法：

a.例如：Task PublishAsync(TBusinessModel businessModel)whereTBusinessModel:IBusinessModel；

b.好处：约束了发布时【只允许发布约束的事件模型】的事件，从而避免了误用，从编译层面提升了项目质量。

2.定义跨进程发布订阅：

a.例如：Task PublishAsync(string topic,TBusinessModel redisMessage)where TBusinessModel:class；

b.好处：

i.重载了发布方法，简化了调用的复杂程度。

ii.与进程内的发布方式隔离

iii.目前市面上的所有消息队列都有topic的概念，比如：Kafka的Topic，RabbitMQ的Topic，Redis的Channel。他们的共性就是通过一个标识文本来确定发布者订阅者和消息队列之间的收发关系。所以这样设计兼容了市面上绝大多数的应用场景。

iv.因为跨进程的发布订阅关系就必然涉及到IO操作等耗时操作，以异步的形势可以提升吞吐量。

第三步：定义配置中心

配置中心需要有：

1.驱动配置(因为未来可能会更换消息中间件，比如RabbitMQ换用Kafaka)

2.异常回调策略(避免事件中心出现异常而无法察觉)

3.实例Id(直接通过静态属性生成一个实例Id，数据的发送方的唯一标识)

4.超时时间(避免消息中间件访问异常，而陷入无限等待的问题)

5.配置文件实例化对象(通过统一的配置文件控制发布订阅逻辑)

好处：统一化的配置方案，一处配置，全框架适用。

第四步：定义事件中心

1.进程内：通过事件模型的【命名空间+模型的类型全称】绑定发布者和订阅者之间的关系。

a.好处：传统方式是通过标识字符串的形式绑定关系，而这里采用了【命名空间+模型的类型全称】的方式，简化了使用成本，提升了研发效率。结合发布者的类型约束，进而提升了项目质量。

2.跨进程：通过topic将消息发送到消息中间件，并代替用户监视异常。

a.好处：简化了以往每发一个消息都需要写一遍监听异常的操作。

3.初始化订阅者，并开始监听消息。

a.好处：不需要单独像以往一样单独实例化监听对象，减少了代码冗余，并规避了错误写法的风险。

4.依赖DI的方式去实例化订阅者

好处：优化了内存占用，避免了重复创建订阅对象的问题。并且以依赖注入的形式创建可以在订阅者内部更便利的调用系统内的其他服务

第五步：定义订阅者接口约束

例如：public interface IBusinessModelHandler where TBusinessModel:IBusinessModel{Task Handle(TBusinessModel businessModel,CancellationTokencancellationToken)；}

好处：约束了订阅者必须实现的方法，从而有了统一的调用方式。并且泛型约束了事件模型。从而绑定了订阅者和事件模型的关系。从而让订阅者处理事件时可以直接拿到需要处理的事件模型。简化了操作，提升了效率，约束了风险。为事件总线在项目里面的全面铺开提供了前提。

第五步：定义约束特性(在C#中为特性标签，在Java中为注解以@方式引用)

1.Topic约束特性比如：[AttributeUsage(AttributeTargets.Class)]

public class TopicAttribute:Attribute

{

public string Topic{get；}

public TopicAttribute(stringtopic){Topic＝topic；}

}

a.好处：标识订阅者消费的目标Topic，并且框架有了统一的标记方式。简化了历史复杂度

2.配置消费特性[AttributeUsage(AttributeTargets.Class)]

public class ConfigureConsumptionAttribute:Attribute

{

public string ConfigureKey{get；}

public ConfigureConsumptionAttribute(string configureKey){ConfigureKey＝configureKey；}

}

a.好处：根据配置文件的配置方式决定实例是否消费，比传统的读取配置文件然后再确定是否消费的方式要简洁，并且提供了统一的方式，让项目有了扩展性和可维护性。

3.是否单一消费特性[AttributeUsage(AttributeTargets.Class)]

public class SingleConsumptionAttribute:Attribute{}

a.好处：根据该标识可以保证同一服务，多个实例之间如果存在同时订阅的关系，

可以通过该标识来区分是否单一消费。有效降低了以往判断一次写一次的编码弊端。

4.还有很多，不过核心的优点就是配置式编码给发布订阅体系带来的软件工程层面的优化，能大大降低历史代码的可读性差，代码冗余，逻辑冗余的历史困境。这也是框架化之后的优势，也是该框架的核心优势，装配式事件总线。

第六步：将代码打包为DLL文件或者打包为.nupkg

好处：这样就将框架具备了分发的能力，可以让项目里面所有的项目都轻而易举的使用该方式编写发布订阅相关的业务。大大简化了历史方案，每个项目都写一遍或者以类库文件存在的形式，无法做到有效分发和项目共享。

综上所述，如图3所示的本发明的具体实施方式获得了如下效果：

1、提供一种分布式微服务事件发布订阅机制。

2、提供同进程事件的发布订阅模型的新型依赖关系。

3、提供一种统一便捷的获取方式，例如通过将事件总线类库打包的形式发布到分发平台，降低使用成本。

4、一次配置，全局使用，提升研发效能。

5、提升研发效率、降低研发难度、降低理解成本、降低软件工程复杂度。

本发明的第二方面提供一种服务内部或跨服务调用的事件总线框架系统，所述事件总线包括事件模型、订阅者和发布者，所述事件总线框架系统包括如下定义模块：

定义进程内事件模型接口；定义发布方法；定义配置中心；定义事件中心；定义订阅者接口约束；定义约束特性；其中，上述定义中，将发布者和订阅者的订阅关系和事件关系进行绑定，

所述事件总线框架系统还包括打包模块，包括：将上述定义步骤的代码进行打包，得到打包文件；

所述事件总线框架方法还包括分发模块，包括将所述打包文件上传至分发中心。

在本发明的一个具体实施方式中，进程内事件模型接口定义模块中，设置为标识项目里面的“模型”以继承“事件模型接口”。

在本发明的一个具体实施方式中，所述发布定义模块设置为：包括定义进程内接口方法和定义跨进程发布订阅。

在本发明的一个具体实施方式中，设置为所述进程内接口方法约束了发布时“只允许发布约束的事件模型”的事件。

在本发明的一个具体实施方式中，所述跨进程发布订阅模块设置为：重载了发布方法。

在本发明的一个具体实施方式中，设置为实行全框架适用的统一化配置方案。

在本发明的一个具体实施方式中，事件中心定义模块设置为：可以包括对进程内事件模型进行定义，以及对跨进程事件模型进行定义。

在本发明的一个具体实施方式中，设置为：所述发布者和订阅者的订阅关系的绑定中，利用时间模型的命名空间和类名在项目里唯一的特性。

更具体的，设置为通过事件模型的【命名空间+模型的类型全称】绑定发布者和订阅者之间的关系。

在本发明的一个具体实施方式中，所述发布者和订阅者的事件关系的绑定中设置为：跨实例或跨服务的通讯利用消息队列的通讯管道的特性。

更具体的，所述跨实例或跨服务的通讯利用消息队列的通讯管道的特性设置为，采用Kafka的Topic或者Redis的Channel。

在本发明的一个具体实施方式中，设置为：对跨进程事件模型进行定义时，将消息发送到消息中间件。

更具体的，例如，设置为通过topic将消息发送到消息中间件。

在本发明的一个具体实施方式中，所述订阅者接口约束定义模块设置为：可以约束统一的调用。

更具体的，设置为可以约束订阅者必须实现的方法。

在本发明的一个具体实施方式中，所述约束特性定义模块设置为，可以定义框架有统一的标记方式。

更具体的，设置为：可以标识订阅者消费的目标Topic，并且框架有统一的标记方式。

在本发明的一个具体实施方式中，所述配置中心定义模块设置为，采用C#语言的特性标签进行简化配置，或Java语言的@注解的形式简化配置。

在本发明的一个具体实施方式中，所述分发模块设置为，设置为采用Nuget或独立部署的Nexus平台分发给各个服务该项能力。

在本发明的一个具体实施方式中，还设置为：包括将中间件技术依赖注入到项目中。

更优选的，所述注入方式设置为包括通过.Net的DI注入方式或AutoFac的DI注入方式。

本发明的第三方面提供一种电子设备包括：

处理器；

用于存储处理器可执行指令的存储器；

其中，所述处理器被配置为调用所述存储器存储的指令，以执行本发明所述事件总线框架的方法。

本发明的第四方面提供一种计算机可读存储介质，其上存储有计算机程序指令，所述计算机程序指令被处理器执行时实现本发明所述事件总线框架的方法。

基于本申请，所属领域的技术人员应了解，本文中所描述的一个方面可与任何其它方面独立地实施，且可以各种方式组合这些方面中的两者或两者以上。举例来说，可使用本文中所阐述的任何数目和方面来实施设备及/或实践方法。另外，可使用除了本文中所阐述的方面中的一或多者之外的其它结构及/或功能性实施此设备及/或实践此方法。

本领域技术人员知道，除了以纯计算机可读程序代码方式实现本发明提供的系统及其各个装置、模块、单元以外，完全可以通过将方法步骤进行逻辑编程来使得本发明提供的系统及其各个装置、模块、单元以逻辑门、开关、专用集成电路、可编程逻辑控制器以及嵌入式微控制器等的形式来实现相同功能。所以，本发明提供的系统及其各项装置、模块、单元可以被认为是一种硬件部件，而对其内包括的用于实现各种功能的装置、模块、单元也可以视为硬件部件内的结构；也可以将用于实现各种功能的装置、模块、单元视为既可以是实现方法的软件模块又可以是硬件部件内的结构。

应当说明的是，上述实施例均可根据需要自由组合。以上所述仅是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。

在本发明提及的所有文献都在本申请中引用作为参考，就如同每一篇文献被单独引用作为参考那样。此外应理解，在阅读了本发明的上述内容之后，本领域技术人员可以对本发明作各种改动或修改，这些等价形式同样落于本申请所附权利要求书所限定的范围。