随着互联网的发展，游戏、商贸、慈善、博彩、餐饮等各个行业都开始接触网络。 “天下熙熙攘攘都是利来的； 天下皆利往”，各种各样的网络活动直接或间接与金钱相关，传统支付无法满足人们快节奏的网络生活，电子支付应运而生，但电子支付方便快捷，同时又便于人们支付支付风险由来已久，在互联网繁荣的今天，只有新花样的增加，风力发电系统通过监测交易、路线、产品、用户，实时、准实时、定时地分析和挖掘相关数据进行交易
风力控制系统的功能需求
实时监测——对各类支付业务交易风险在事件中的监测和控制。
同步反馈——接受并处理各支付业务平台的支付交易信息请求，并将处理结果实时返回业务系统。
联动控制——针对风控系统识别出的风险信息进行系统自动化(基于人工预设战略)的交易风险处理。
迭代——交易风险特征识别方式可以通过系统自动整理、人工设置参数、外部资源共享等方式持续动态更新。
针对统计分析——风力控制系统中存在的各种信息和数据，相关人员可以结合查询和查看报告等方式，对系统的运行状况、交易风险状况、岗位绩效状况等进行监督。
风力控制系统的非功能需求
柔性——风控规则需要频繁增加和调整，如何降低风控规则增加、修改的成本是风控系统需要解决的问题之一。 另外，风力发电系统必须能够与不同的业务系统集成，为了便于集成，需要与业务系统相对独立。
性能——风力发电系统的响应时间必须小于100ms，同时可以具有很大的吞吐量。 风力发电系统在降低风险的同时，如果不影响用户的体验，就会本末倒置。
准确性——风力发电控制系统根据风力发电控制规则自动冻结交易相关资源等。 准确性过低会引起大面积投诉，损害公司信誉，对公共形象使用失去信心，给公司带来巨大损失。 因此，风力发电控制系统识别风险的准确性需要下限，同时必须注意风险识别的准确性和覆盖率相互影响两者达到可接受的平衡。
风控系统的误区
风力发电控制系统的目的是在不影响正常业务的情况下将交易风险降低到合理水平，风力发电控制系统不能消除风险，因此建设风力发电控制系统时不应盲目追求数据的准确性和一致性。
风力控制系统体系结构
风力控制系统主要由以下部分组成。 以下分别介绍风力控制实时引擎、风力控制准实时引擎、风力控制定时引擎、惩罚中心、规则中心等。
空调实时发动机
支付系统将当前交易的部分信息与风力控制实时引擎同步传递，获取当前交易的风险得分和处理建议。 风险分数总是100，分数越高风险越大。 –1意味着风力发电系统无法评估当前交易的风险，一般意味着风力发电系统未能获取当前交易的正面或负面信息。 空调实时引擎最大的挑战是性能，实时引擎必须在100ms内对支付交易进行风险评估。 否则，会影响用户体验。
风控实时引擎根据公司积累的风控数据和第三方风控数据进行风险评估。 公司的风控数据主要来自风控准实时引擎和风控定时器引擎。
风力控制实时引擎基于规则引擎Drools，目的是提高系统的灵活性和配置性。
下图是风控报告的域模型。
规则引擎的优点
风控系统的中风控制规则变动比较频繁，其他部分比较稳定，引入规则引擎可以解除系统和规则的结合，提高复杂逻辑的维护性，提高规则的可读性和理解性。
风力控制准实时发动机
交易诈骗行为具有一定的隐蔽性，并不是所有的风险都能得到实时准确的评估，有时还需要分析近期的数据来识别诈骗行为。 例如分析最近一个月的用户行为。 风控实时引擎从消息服务器获取交易数据，异步分析交易数据流，分析结果通过风控服务保存在风控数据库中，以便实时风控引擎评估交易风险。 风控实时引擎在发现异常后到风控数据生效的时间在100ms以内，可以有效防止交易风险的扩大。
风力发电控制系统初期建设时，中风控准实时引擎往往通过消息监听器消费交易消息，将中间数据存储在Redis缓存中，并对数据进行多维度分析。 由于每个指标都需要开发合适的程序，所以风力控制规则的开发成本高，在线周期长。 为了解决这一问题，提高系统的灵活性、可配置性，在风力控制系统2.0版中引入了CEP引擎Esper和规则引擎Drools。
空调实时引擎需要使用到Drools、Esper、Esper IO AMQP、Esper扩展si
on、Spring等组件，其中Esper Extension是我们对Esper的扩展，主要用来提高Esper可配置性以及丰富Esper IO功能以及弥补Esper缺陷。
下图是风控准实时引擎架构：
什么是CEP
事件驱动是一种监测、分析信息流从中得出推论的方法。CEP(Complex Event Processing)也就是复杂事件驱动，是结合多种数据源的数据对信息流进行监测、分析从推理出一些复杂的事件或模式，CEP的目的是识别出一些有意义的事件，例如：机遇、威胁，并且尽可能快的作出反应。
CEP引擎已经被一些公司开发出来，用来满足那些需要分析事件并对其作出反应的的需求，下面是一些典型的应用示例：
业务流程管理和自动化（流程监控、商业活动监控、报告异常）
金融（自动化交易、欺诈检测、风险管理）
网络以及应用监控（入侵检测、SLA监测）
传感器网络应用（读取RFID、生产线调度与控制）
CEP技术选型
下面列出一些CEP产品，大家可以根据自己的情况选用。
开源 CEP产品：
JBoss Drools Fusion
EsperTech Esper
Triceps
商业CEP产品：
EsperTech Esper Enterprise Edition
EsperTech EsperHA
IBM Operational Decision Manager (IBM ODM)
Oracle Stream Explorer platform
TIBCO BusinessEvents
TIBCO StreamBase
Esper优点
数据窗口机制完善
Esper目前支持大约30种数据窗口，深入理解窗口是应用Esper的关键，下面表格列出常用的几种：
Time Window：
Length Window：
Time Batch Window：
EPL语句的语法与SQL相似降低学习成本
事件处理语言（EPL）是SQL标准语言并做了扩展，提供了SELECT、 FROM、 WHERE、 GROUP BY、HAVING和 ORDER BY等子句。
使用方式灵活
Esper提供了丰富的API，可以独立部署也可以集成进任何应用。
支持多种获取结果方式
Esper缺点
Esper统计分析的中间数据全部是存储在内存中，不能跨服务器，只能单机部署，内存有限，存在单点故障，由于全内存操作，系统重启后中间数据就会丢失无法恢复。Esper的这些缺点风控系统都可以接受，对风控系统没有实质的影响。
风控定时引擎
某些非常隐蔽的交易欺诈通过实时或准实时风控引擎很难发现，这些风险需要通过分析用户跨月或跨年的数据才能识别。定时风控引擎主要用来定时对支付相关等数据进行深度挖掘，建立对应的风控模型，典型应用场景是用户的信用等级模型以及用户行为分析。
定时风控引擎构建在Hadoop集群上。
惩罚中心
惩罚中心负责积累风控数据并提供奖励和惩罚的相关服务，风控实时引擎、风控准实时引擎、风控定时引擎会调用惩罚中心的服务查询或保存风控数据。惩罚中心针对不同维度提供多种惩罚策略以及多种奖励策略。风控实时引擎在识别交易风险时根据规则综合考虑奖励以及惩罚相关数据以提高风险识别准确率。
下图是处罚中心域模型：
风控系统的建设往往是分阶段实施的，一般分为以下三个阶段：
第一阶段：核心任务：
搭建基础架构
网上应用接入
手机应用接入
建立起有效的监控团队和工作机制
第二阶段：提升性任务：
交易监控能力
风控模型提炼
监控团队能力和工作机制
第三阶段：后续发展：
持续优化
新应用接入
团队技能是逐步积累的，对风控系统以及风控模型的理解也需要时日，如果初始建设阶段求大求全会使建设工作增加不确定性，一旦出现技术或业务方向上的偏差会给公司带来巨大的损失。循序渐进逐步建设，在前一阶段的工作产生效益时再去进行下一阶段的工作阻力会小很多，任何时候保持团队对项目的控制力都是相当重要的，这是我们在建设风控系统的过程中的一点感悟。