规则引擎总结文档.doc

规则引擎总结文档 文档说明：阅读此文档，首先仔细阅读引擎产生的背景，场景规则的抽象，然后简要看一下流程。然后忽略掉流程，从引擎产生的背景和场景规则的抽象中仔细体会类是如何设计的（类的设计思路在对象模型中类的说明部分有解释）。引擎的互备功能在此文档种没有详细的说明，也请阅读的时候忽略掉此部分功能。 Engine中最难理解的部分是引擎的对象模型，我发现我无法用书面语言来描述这个模型设计的初衷和衍化，所以我采用了一种类似于写故事的方式来阐述这个模型。这样多少看起来有些不标准，不符合一个书面文档的格式。但是文档的目的就是我们能够理解这个对象模型，至于它的格式，或许已经不重要了。希望大家能喜欢这种讲述方式。 引擎产生的背景： 小区短信的应用场景规则根据顾客要求不断的变化，每一种场景规则处理数据包的逻辑不同，同时又有相同的地方，把场景规则处理数据包相同的地方固化，场景规则的添加仅需要编写场景规则不同的逻辑，从而减少代码冗余，提高编码速度。 场景规则的抽象： 每种场景规则都有订阅和分发的两个功能。 订阅：表示每种场景规则需要的数据包，包括需要那种数据包(A or HLR)，哪几种动作，哪几个小区。 分发：也就是接收数据包并处理。 引擎功能说明： 引擎的主要功能： 引擎依次获取每个场景规则的订阅，然后把订阅合并后提交给DCAU，同时把从DCAU接收到的数据根据每个场景规则的订阅进行分发。 说明：从这个功能上看就分为订阅和下发，订阅是每分钟订阅一次，使用Timer来实现，这个Timer在流程图C的黄色部分的获取订阅部分有位置的说明。下发主要是两个线程来实现的，一个是接收，就是从DCAU接收到数据包然后分层过滤，放到SingleRuleProxy的缓存中，对应于流程图C中黄色的接受信令数据。另外一个是发送到实际的规则对象，对应于流程图C中黄色的下发信令数据。 引擎的其他功能： 引擎的管理功能，包括引擎运行的各种计数器的监控、手机号码的跟踪功能、运行时手机号码记录情况的查询功能（黑名单、是否在今天的发送记录中. est.）。 说明：这个功能在类设计说明中的11.引擎跟踪服务当中，这个服务仅仅是调用了RulesProxy的public方法。查看这个服务的接口说明，就可以看到这部分的实现，非常简单，仅仅是函数调用。 引擎的OMC监控的功能以及 OMC的对外接口。 说明：OMC对外接口功能的实现EngineMonitorWCFService的Project里面实现，仅仅是把Winform的跟踪功能封装一下，做成svc的好处是通过80端口，可以实现外网的监控访问。 互备和分流功能。 说明：分流功能是采用多号段的方式，也就是多个SingleRuleProxy对象的方式来实现的。互备功能采用的号段信条方式实现。两个引擎相互发送心跳包，心跳包里面包含了引擎的号段信息，当另一台引擎在规定时间内收不到信条包的时候，就对DCAU重新注册自己的号段，这样DCAU就能把新的数据传送至规则引擎。其实现方式是在AbstractRulesProxy中有一个RuntimeMobileSection的属性，在PairRulesProxy中重写了该属性，PairRulesProxy中RuntimeMobileSection有两部分组成，其中一个叫做preparatingMobileList，心跳模块如果收不到心跳，就会把这个preparatingMobileList里面AddRange出错的号段。当注册DCAU在一次被激发的时候，DCAU就能够往引擎发送新号段的信息了。 引擎工作流程概述图: 说明：流程图A B C 一次从整体布局到详细流程，这样看起来能够整体的把握，流程图C括号里面的说明分别是每个流程点在那里类中的实现。其中一般格式是 类名:函数名，或者是类名。 流程图A 流程图B 流程图C 引擎采用的技术点概要说明： 场景规则编译成DLL放在特定的文件夹下，Engine实用反射的方式创建场景规则的对象并通过接口与规则对象进行交互。 引擎使用Timer定时获取规则的订阅信息并且把定约信息提交给DCAU。 引擎Host一个WCF的服务来接收从DCAU传递回来的信令信息并且将该信令包放入引擎的接收缓存中。 引擎使用线程while来检测接收缓存并把每个数据包根据规则的订阅信息发送给对应的规则对象（实际上是发送给规则对象的缓存）。 引擎开启另外一个while循环把规则对象中的缓存的信令发送给实际的规则对象。 引擎的对象模型（此部分用Demo来演示来提高效果）： 类的设计说明 说明：Engine最重要的几个类 RulesProxy RuleProxy SingleProxy 这三个类代表了整个规则的处理封装。AbstractRulesProxy OneRulesPr