基于事件驱动的组件架构

本架构主要目的是改进软件开发中松耦合、增长模块的重用性、提升开发效率。

在常规的模块间方法直接调用式开发中，新增的功能对原有模块代码的稳定性、重用性破坏大,不利于软件的后期维护，且开发效率低。

另外，在传统的软件开发方法中，若是新增的功能的逻辑在其它模块须要重复使用，则只能经过copy代码或方法调用的方式来重用，仍是须要改动原代码。
经过本技术方案，能够将一些功能抽像为组件，这些组件能够被动态的插入的现有模块中，不须要改动原有模块代码，从而增长了重用性，提升了开发效率。

技术解决方案

A. 相关概念抽像及定义

首先在软件的业务模块中抽像出核心业务逻辑(Core Service)及核心业务数据(Core Data Model)，同时抽像出核心业务逻辑相对应的事件接口(Event Interface)。
在核心业务以外的业务被称之为组件(Component)，组件是由一组业务插件（Plugin）组成的，这些插件是一个或多个核心业务的事件的实现体，核心业务和事件的关联，

是经过插件桩（Plugin Bundle）收集起来的，具体的关联关系是在一个名为Component.xml(组件描述文件)中定义的。

 

B. 组件的开发

当须要在核心业务逻辑中插入新的逻辑时，须要定义出相应的插件，使插件实现相应的业务事件接口，在插件中实现具体业务逻辑代码，其须要的核心业务数据会经过事件接口作为参数传递过来，这样插件就能够无入侵式的操做核心业务数据了。

 

 

C. 组件的加载和启动

首先组件有如下状态：安装状态和启动状态，分别为已安装和未安装，已启动和未启动。
当系统启动时，组件加载模块查找全部的Component.xml，并解析出插件和核心业务的关联关系，并将这种关系经过组件视图（Component View）记录在内存中。
在加载过程当中，检测数据中是否有此组件的记录，若是没有则在数据中记录，此时组件的状态被标记为未安装、未启动。若是数据库中已经存在则检测其状态，若是是已启动状态，则将此组件启动，并标记为已启动状态。
在系统的控制台中展现组件的列表，并提供操做按钮，能够执行如下操做：安装/卸载、启动/停用。
综上所述，组件被启动可能经过两种途径：系统加载时或在控制台中手动启动。组件被启动后，根据组件视图中记录的关系将插件和插件桩进行关系绑定，即将插件动态插入到插件桩中，即完成业务逻辑动态地、无侵入式地插入到核心业务逻辑中。

D. 插件调用逻辑说明

在软件运行中，当核心业务逻辑被调用的同时调用事件接口，同时向接口传递核心业务数据，这个过程被称为事件激发。
当事件激时，插件桩里已经收集了相应的插件集合（事件的实现体），进而在插件桩中一个个的调用插件，传递核心数据，这样插件被执行。

 

方案的效果

经过上述组件的技术方案，能够实现对原系统无侵入式的、松耦合式的开发，开发人员无需关系核心代码细节，只要了解事件接口就能够完成对核心业务的扩展，开发效率高、重用性高。
效果举例：以电子商务系统为例，在一个电商业务中建立订单是核心的业务逻辑，在订单建立成功后，可能须要发送一条手机短信给顾客， 基于此种组件方案，开发人员须要开发一款基于某个电信网关的短信发送组件。开发人员没必要了解订单建立的具体代码，只需关心如何跟电信网关对接便可，组件机制会将订单信息、顾客手机号等核心数据经过订单的建立事件传递给插件，插件拿到上述数据， 根据具体接入的电信网关参数，将核心数据（订单信息、顾客手机号）组织好文字，传递给电信网关就完成了经过此短信网关发送订单短信的功能。
一旦业务发生变动，好比要更换其它短信网关发送短信，此时再根据具体的网关参数开发另外一款短信组件，而后停用以前的短信组件，安装上新的组件便可。
能够看出，从功能开发，到后期的变动维护，订单建立的核心业务代码从未暴露给组件开发人员，他们也不须要去改动核心代码，保持了原有系统的稳定性，下降了新功能开发的难度，并且基于一样规则的系统均可以安装此短信组件，直接使用，极大的下降了开发成本。

 

 

实际应用

 

 咱们以本架构在javashop电商系统中的应用案例说明：

1、订单的建立和短信发送

A. 订单核心业务

 

 

 

 

1.订单核心业务（OrderService）
负责订单的建立，这属于电商业务的核心，经过createOrder()方法建立订单。

2.订单插件桩(OrderPluginBundle)
在其pluginList属性中存储了全部响应订单业务事件的插件。

3.订单建立接口
订在订单建立成功后，会激发此事件，而实际调用的是上述pluginList中的插件。
B. 组件的组成

 

 

 

 

如上图所示，订单短信组件由如下内容：
1. 订单短信组件（OrderSmsComponent）
订单组件类，在组件被安装时会调用其install方法，完成一些安装必要的操做。

2. 订单短信插件
此类实现了订单建立事件，响应了订单完成事件（onOrderCreate）方法，当订单建立完成时，会调用此方法。

3. 组件的描述文件Component.xml
此描述文件定义了订单插件（OrderSmsPlugin）要注入到订单插件桩中，即定义了插件要对应的核心业务

C. 组件加载、启动过程

 

 

组件的加载、启动过程细节以下：
当系统启动时，组件加载模块查找全部的，并解析出插件和核心业务的关联关系，并将这种关系经过组件视图记录在内存中。
在加载过程当中，检测数据中是否有此组件的记录，若是没有则在数据中记录，此时组件的状态被标记为未安装、未启动。若是数据库中已经存在则检测其状态，若是是已启动状态，则将此组件启动。
组件启动首先将插件注入到相应的插件桩中，此时当事件被激发时，经过插件桩就能够调用到实现了此事件的全部插件了。组织好插件的关系后，将此组件在数据库中标记为已启动。

D. 事件激发及插件调用

 

 

如上图所示，描述了事件激发和插件调用的过程，具体技术实施细节以下：
在这里循环全部的订单建立事件调用之（激发事件接口），这些事件实际是被注入进来的、具体的插件实现体，好比订单短信插件，此时订单短信插件被动态调用，在此插件中完成发送短信的逻辑。

经过上述架构的实施，能够达到以下效果： 

如今短信的厂商众多，咱们分别为其实现“短信发送插件”，这对于“订单核心逻辑”代码是不须要改动的，

一方面提高了核心代码的稳定，一方面增长可对“新短信厂商”的扩展性。

 

后记

经过这种组件架构，其实在电商架构领域中还有不少模块能够采用组件式的架构，以javashop电商系统中的应用为例：

支付组件

订单的支付为核心逻辑，他来处理状态改变，记录日志等。

经过调用支付插件来完成具体的支付操做，传递的是支付金额，订单号核心标准数据。

而支付插件能够多种实现：支付宝、微信、银联等等。

这样加强了订单核心的稳定，提升了支付方式的扩展性

 

物流查询

查询动做和展现是核心，传递给插件“物流公司”，“物流单号”核心标准数据

物流查询有多种插件实现：kuaidi100，showapi，菜鸟等等。

一样加强了订单核心的稳定，提升了物流查询厂商的扩展性

 

图片存储

图片都上传和显示是核心，传递给插件图片流是核心标准数据

图片的存储有多种插件实现：如阿里oss,七牛、又拍等等。

一样加强了系统核心的稳定，提升了图片存储厂商的扩展性

 

其实还有不少逻辑能够采用这种思路，提升稳定性，提升扩展性，在这里就不一一列举

这须要对本身的系统功能进行分析抽象，抽象出核心逻辑、插件接口标准、标准数据。

易族智汇（javashop）原创文章