规则引擎
框架
–by struct
1、框架概述
a)
CTU
系统分为
3
部分:
1
、事件注册器。
2
、事件分析引擎。
3
、风险处理系统。
b)
事件注册器:收集服务器信息、事件触发人员信息、以及事件相关的数据,将这些数据组合成一个
Event
。事件注册器负责将
Event
派送到事件分析引擎进行处理。
c)
事件分析引擎:采用
Drools3.0.*
版本作为规则引擎的核心。通过
bread
模块的支持,采用
Lucene
做
event
数据源。实现大数据量查询相关的
Event
。
d)
风险处理系统:通过定义风险模型(风险等级、风险描述、触发的处理动作)生成一个风险派送到风险处理系统进行相关的业务处理(目前只是在
CTU Engine
中处理,将来可以扩展一个
Interceptor
实现
ESB
架构的一个
endpoint
)。
2、
开发指南
应用服务器端
(CTU client):
a)
事件注册器
(
业务层
)
:
EventRegister.java
public interface EventRegister {
/**
*
向事件库注册一条消息
* @param event
要注册的事件
* @return boolean
是否成功
*/
public boolean register(Event event);
}
b)
事件注册器默认提供
2
种实现方式:
1
、是
JmsQueueEventRegister
:采用
Jms
直接连接方式,该类是采用短连接方式(每发送一条消息都会创建连接),因此最好能够配合
Jms JCA
,让容器管理物理连接(关于
JMS JCA
的技术以及实现在下面将会解释)。
2
、
EventRouterRegister
(
commandDispatcher router list
),采用路由方式,可以由多个
commandDispatcher
组合而成。
c)
提供发送失败存储的
EventRegisterWrapper
,该包装负责调用
EventRegister
进行发送,发送失败以后进行对象存储,直到重发成功。
后端的分析引擎技术方面
(CTU Engine)
:
a)
分析引擎,
1、
下面是分析引擎的总体预览图
2
、
Drools
:规则引擎核心开发包。
3
、
FileObjectProvider
:由多个
FileManager
负责管理文件。负责配置文件管理跟规则文件管理
默认实现有:
DefaultFileManager
:普通的文件系统
ResourceLoaderFileManager
:由
ResourceLoaderService
提供支持
3、
BeanObjectProvider
:由多种
BeanObjectFactory
以各种方式来生产
bean
。负责创建
Bean
跟
bean
生命周期的管理。
这些
Bean
可以标识为
singleton
、
LifecycleAble
(如果为非
singleton
,则在引擎一次分析完成作为一次生命周期,如果是
singleton
则在配置重载的时候作为一次生命周期)
/**
* bean
工厂
*/
public interface BeanObjectFactory {
/**
* Build a generic Java object of the given type.
*
* @param clazz the type of Object to build
*/
public abstract Object buildBean(Class clazz) throws Exception;
/**
* Build a generic Java object of the given type.
*
* @param className the type of Object to build
*/
public abstract Object buildBean(String className) throws Exception;
}
默认实现:
GenericBeanObjectFactory
普通的,根据
Class
直接实例化
SpringBeanObjectFactory
,由
BeanFactoryService
提供支持。
4、
ReloadManager
:负责重载可重载的
item
,只要类实现
Reloadable,
并且受
ReloadManager
管理,则
reloadManager
负责定期检查每个
Reloadable
是否需要
reload
。如果
item
需要
reload
,则
reloadManager
将调用
reload
方法重载配置等
...….
默认实现:
DefaultReloadManager
目前
Reloadable
实现类:
²
ConfigurationManager
:
负责
engine
配置管理
²
RuleFiredAgendaEventListener
:负责将触发的规则描述
bean
放入
ThreadLocalContext
中,为生成
risk
风险模块提供数据,该类采用
XStream
来解析
RuleDescription
的描述文件。
5、
Engine Service
配置
a)
可以模仿
src/conf.test/services.xml
的配置
b)
BeanFactoryService
的实现类
com.alibaba.ctu.engine.DefaultAutowireBeanFactoryService
c)
需要配置
2
个
ServiceBean
:
autowireBeanFactoryService
指向
BeanFactoryService
resourceLoaderService
指向
ResourceLoaderService
6、
Engine
的
Configuration
配置:
1、
Xml
格式可以根据
cut
项目下面的
engine/
src/conf.test/Engine.dtd
2、
配置分成
Risk
(分析风险的规则引擎配置)、
Event
(分析事件的规则引擎配置)、
interceptors
(拦截器配置,供全局使用)、
include
(可包含另外一个配置)
3、
Risk
、
Event
的配置解释:
a)
每种
DomainObject
都有各自的
domainName
。每个
domainName
都会找到配置文件中的
(event/name
、
risk/name)
相匹配的配置作为规则引擎的配置。
b)
他们都可以
extends
另外的类型一直的配置(主要是规则文件跟
pulltool
合并)。
c)
interceptor-stack
:
他们有各自的拦截堆栈,该堆栈在规则引擎执行前后执行。在这儿可以对规则引擎的
WorkingMemory
、以及一些数据进行处理。
d)
Pulltool
:将作为规则引擎的
GlobalTool
来使用。
该
对象由
BeanObjectProvider
负责产生。支持
singleton
、
LifecycleAble
。
e)
WorkingMemory
配置:他们是构造
Drools
的
WorkingMemory
的主要配置。使用该领域需要对
drools
有一定的了解。
4、
interceptors
配置
解释
a)
Interceptor
拦截在分析引擎分析前后。可对
WorkingMemory
进行操作。该
对象由
BeanObjectProvider
负责产生。支持
singleton
、
LifecycleAble
。
b)
为
Risk
、
Event
提供拦截器堆栈
(interceptor-stack)
。
5、
include
配置解释
:提供包含另外一个配置文件。方便管理配置。不用将所有的配置写在一个文件中,可以有条件地将他们归写在一个文件下面,然后有一个总文件来
include
这些文件。