技术栈：Java+Groovy+Lua+Springboot+Mysql+Redis+Drools+Velocity+RabbitMQ+Spring Data Jpa
一、背景此篇文章我们来片命中部分设计，在上一篇中我们确定了命中维度是交易类型，首先支付系统上送的报文中肯定有交易类型字段，或者通过某种方式可以将某字段转换出交易类型，总之我们肯定知道了此交易是何种交易类型，是代扣、是代付还是快捷等等...
二、分析设计 1.分析在router_rule_table中存储着我们的规则，也就是以交易类型为维度的规则。
我们以代扣交易为例：讲我们的设计演进，首先交易系统上送到路由系统的主要基本参数有：交易类型(deduct)、交易金额(100.00)、开户行(0801)、卡类型(E)等，假如此时我们规则表中有如上三条规则(1.2.3)，那么我们可以根据上送的报文参数-交易类型为条件
sql：select * from router_rule_table where trans_code=deduct;
那么就命中出来了规则表中第一条规则，达到了我们想要的目的了，本部分不就是要以交易类型为维度命中我们的规则吗？看似没有任何问题，但是我只想说，这种设计后期绝对能把人恶心吐了。我们接着分析，如果我们又接了一个通道A，并且也接入其代扣交易类型(规则4)，然鹅此通道并非提供给原来业务线使用，假如原来业务线是话费代扣业务线，现在提供给水电煤代缴，那么你上一个sql这么写还对吗？不对了吧，这时候怎么办，为了区分不同产品线，这时候你又机智的在表中加了个字段-product_code，又将历史数据的product_code进行编制填充，经过一波猛如虎的操作，暂时满足了需求，
sql改为：select * from router_rule_table where trans_code=deduct and product_code=001;
没过了多久，又来需求，区分移动端和pc端，规则表又要加字段场景码scene，又重复上一波操作，扩表加字段改sql，
最终sql改为：select * from router_rule_table where trans_code=deduct and product_code=001 and scene=002;
只要规则增加条件就来一波如上操作，这样的系统谁后期负责谁恶心,这种设计不仅是存在后期扩展上的问题，也仅仅是简单的=判断逻辑，可以说毫无扩展可言吧。
2.设计那么我们该如何解决如上问题呢？
首先我们要确定几个问题，第一根据交易类型维度进行规则命中是没有问题的，第二命中的条件不应该横向扩展在规则表中，如果横向扩展那么在增加命中条件时你就躲不开对表进行扩展，既然不能横向扩展，那么就纵向扩展，怎么个纵向法，如下图：
增加rule_condition表，独立表挂靠命中条件，同时设定where条件不仅仅是简单的=了，更强大的条件判断规则，如=、!=、in、!in、>、<、>=、<=等，如果基本运算满足不了还可以切入Groovy脚本进行数据计算处理，那么我们的规则存储方式变为如下：
当使用纵向扩展方式，同时使用Drools规则引擎和Velocity模板引擎结合使用来组织这些规则条件，难度等级上了不止一个层次了，但是这样的系统，运营使用起来会非常爽，简单的配置就可以满足业务需求了，运营操作页面如图，请忽略原型图的丑陋：
图一表单对应规则表router_rule_table，图二表单对应条件表rule_condition，当上送报文满足配置条件规则符以及脚本计算值即可命中此规则，当此种设计模式下，我们再来看上面的场景变更，无非就是在规则条件中新增加一条条件，product=XXX，不用需要进行表结构调整，也不需要调整代码，运营调整配置即可满足需求了。
对比模式一设计和采用模式二设计，你知道差距在哪里了吧。
三、总结具体怎么使用Drools规则引擎和Velocity模板引擎和Groovy满足如上设计，下次分享吧，图书馆不论是湿度还是温度，都适合睡觉呀。
