电子商务系统之规则引擎

构建电信计费系统、保险系统、金融等交易系统之所以复杂，除了对诸如高性能、高可靠性、高可用性、高安全性、高扩展性的要求外，另外至关重要的原因是这些 领域存在大量的业务规则，这些规则千差万别，甚至是相互冲突的（瞧瞧电信资费就知道有多么复杂）。在市场驱动的情况下，系统架构和模型必须对客户、竞争对 手、合作伙伴和整个市场情况的各种变更及时响应，同时将这些变更产生的需求作为业务规则体现到系统中去。从业务的角度看，业务规则是一种原则，包含在特定 活动或范围内关于指导、操作、实践或过程的行为规范；从信息系统的角度看，业务规则是一个定义或限制业务某些方面的声明。一个业务规则包含一组条件和在此 条件下执行的操作，它们表示业务规则应用程序的一段业务逻辑。业务规则通常应该由业务分析人员和策略管理者开发和修改，但有些复杂的业务规则也可以由技术 人员使用面向对象的技术语言或脚本来定制。业务规则的理论基础是:设置一个或多个条件，当满足这些条件时会触发一个或多个操作。

1、应用场景：

• 电信计费费率模型

一次批价：根据预处理提供的标准格式话单，结合费率表、号段表、区号表等计费资料对话单进行计费。费率表中记录的信息主要有：基本计费单元、基本通 话费率、长途计费单元、长途通话费率、优惠时段起始时间、优惠时段终止时间、优惠时段费率等等。号段表记录了IMSI号、MSISDN号所对应的归属地， 以此来判定用户的归属地，进而判定出用户是否漫游、是否拨打了异地手机而应收取长途费等等。区号表记录了各个长途区号，用以从用户所拨的对方号码中提取出 长途区号供计费使用。

二次批价：在一次批价的基础上，根据用户入网所享受的各项优惠对话单进行重计费，以最终生成向用户收费的话单。用户所享受的各项优惠记录存在营业系 统的用户资料中，因此二次批价必须结合营业资料进行。二次批价使是一个耗时耗资源的过程，一般在合帐前集中完成，为了提高速度，将二次批价中需要频繁用到 的营业资料载入内存中。

• 信用卡积分规则

凭XX信用卡消费1元人民币，即可获得1分的消费积分，在汽车类商户每消费100元人民币积8分，在房地产类商户每消费100元人民币积6分。

兑奖规则：100分～300分：兑换150元礼品，300分～500分兑换300元礼品，500分以上兑换400元礼品。

2、规则引擎

规则引擎的设计目的是使得规则的创建和维护变得简单，方便和代价低。好的规则引擎应该将业务逻辑的定义从一个系统中分离出来，而不是在代码中固化。 同时规则引擎也将系统开发或者集成过程中不同角色的工作耦合程度大大降低，使得业务逻辑开发人员和具体系统开发等人员的工作可以接近并行的进行。在参考文 档中有业务规则引擎基础较为详细的描述。

3、规则引擎使用思考

基于drools+MVEL或ognl来构建核心的业务规则处理部分。

需要考虑解决的几个问题：

• 性能及压力测试。对于像企业应用问题还不大，但对于在线实时交易系统，尽管可以预先编译规则，但规则引擎是否会成为性能瓶颈。
• drools与db的结合、内存数据库（berkeleydb）的结合

Loading and managing rules dynamically from a database

• 与mule及SoA框架结合，用于做对外接口
• 规则引擎用于系统部署及内容分发

5、参考资料

http://java-source.net/open-source/rule-engines

http://www.manageability.org/blog/stuff/rule_engines/view

http://www.ibm.com/developerworks/cn/java/j-drools/index.html

http://java.ccidnet.com/art/3737/20060427/531321_1.html

http://www.onjava.com/pub/a/onjava/2005/08/03/drools.html

http://www.infoq.com/articles/Brasilian-Healthcare-System

Technorati 标签:
业务规则引擎 ,rule engine ,电子商务 ,drools