一、定义：
扩展性：是指为了适应业务的发展和变化，需要系统在短时间内做出响应，而系统需要在设计之初充分考虑扩展性，使得可以通过配置的方式来实现业务的变化；对于实时风控系统而言，这一点尤为重要。
二、问题：
那在实时风控系统的运营过程中，可能出现的的扩展性的场景是什么呢？
场景1：参与分析的要素需要扩展，这一类场景又可以细分为以下的N多类场景：
1、当笔要素的扩展：运营大牛磨破嘴皮，弄到了客户系统的一个关键要素{比如商品是否虚拟商品}，如何应用到实时风控中？
2、当笔要素的衍变：数据大牛踏破铁鞋，搞到一套牛逼的IP映射数据，能够精确定位交易的发生地点，如何应用到实时风控中？
3、历史交易的运算：模型大牛冥思苦想，找到一套不法分子的作案轨迹，第一次是怎么样的，上一次是怎么样的，如何应用到实时风控中？
4、滑动窗口的计算：统计大牛掐指一算，发现统计数据的明显特点，一分钟内统一设备发起20笔交易，那就是扯淡，如何应用到实时风控中？
5、海量数据的应用：数据大牛潜心研究，提出了交易个体的行为习惯，喜欢在哪里，喜欢在何时，做一些怎么样的交易，如何应用到实时风控中？
场景2：参与分析的逻辑需要扩展，这一类场景又可以细分为以下的N多类场景：
1、数学运算要扩展，加减乘除括号，属于不属于，like，sum、avg、还得带个distinct，各种数学算法；
2、侦测算法要扩展，基于规则，基于评分，基于统计算法贝叶斯，基于人工智能神经网络，怎么高大上怎么来，必须与国际接轨！
三、方案：
面对上述的这些扩展性场景，该如何来设计呢？
也许你要说，Rule Engine啊，有成熟的商业产品，也有牛逼的开源产品，分分秒就拿来用，那我们来看看，Rule Engine是个啥？
Rule Engine
应该是符合JSR_94的，实现业务规则抽象化的，内嵌在应用系统内的中间件产品，百度是这样描述的：
市场也有较多的规则引擎产品，IBM的JRules，Jboss的Drools，Fico的blaze等等，还有某风光一时的破产公司的intelliRule【此处省略上万字】。深入了解规则引擎，你会发现，规则引擎主要解决的问题是：业务逻辑的抽象，即如果怎么怎么样，那么怎么怎么样，将其抽象成业务无关性，然后以中间件的方式来实现；所以，Rule Engine具备业务扩展性，但主要体现业务规则上，与以上罗列的这些扩展性不完全匹配；
且规则引擎是一个业务无关性的通用化中间件，可以用在一切有业务规则的地方，而不是一个针对风控场景的定制化的侦测引擎，
所以，规则引擎只能解决部分问题，那我们在系统设计上该怎么做呢？
1、哪些扩展性的需求是在实时风控系统体内实现，哪些扩展性的需求是在实时风控系统体外实现？从设计上来说，是个设计范围划分，和接口设计的概念
2、将扩展性的需求归类，我们发现可以抽象成以下几类：当笔要素扩展，上下文扩展，统计量扩展，行为习惯扩展，业务规则扩展，侦测算法扩展；
当笔要素扩展：设计关键，要考虑业务无关性，要考虑结构体的扩展性，要考虑衍生要素的计算量
上下文扩展：要抽象上下文的数据结构，其实对于这块内容，做大做深了，就是一个CEP Engine【复杂事件引擎】；
统计量扩展：要抽象统计量的数据结构，考虑统计算法，考虑统计窗口等等；
行为习惯扩展：要考虑这块计算的剥离，从本质上，实时计算和大数据是一对矛盾，找到一个松耦合的方案，才能实现既能使用大数据，又不影响侦测效果；
业务规则扩展：这个简单明了，设计上参考规则引擎即可，有好多算法可学习，rete、红黑树。。。。当然，特殊的侦测场景，需要对于运算算法的深度定制化；
侦测算法扩展：和上面的几个扩展不是一个量级的，或者不是一个层面的，个人感觉，纳入在扩展性里面有点牵强，更加应该作为单独的一件事情来考虑；
写到这里吧，有点抽象，感谢为这些实践付出心血的兄弟们~~~
