一、定義：
擴展性：是指為了適應業務的發展和變化，需要系統在短時間內做出響應，而系統需要在設計之初充分考慮擴展性，使得可以通過配置的方式來實現業務的變化；對于實時風控系統而言，這一點尤為重要。
二、問題：
那在實時風控系統的運營過程中，可能出現的的擴展性的場景是什么呢？
場景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、紅黑樹。。。。當然，特殊的偵測場景，需要對于運算算法的深度定制化；
偵測算法擴展：和上面的幾個擴展不是一個量級的，或者不是一個層面的，個人感覺，納入在擴展性里面有點牽強，更加應該作為單獨的一件事情來考慮；
寫到這里吧，有點抽象，感謝為這些實踐付出心血的兄弟們~~~
