4. 风控策略引擎：规则引擎架构、策略编排、实时风控与离线风控结合
风控策略引擎，说白了就是量化平台的「交警」。
它负责拦住那些不该成交的单子，放行那些合规的交易。我见过不少团队，策略写得漂亮，但风控一塌糊涂，最后被交易所罚得怀疑人生。嗯，咱们今天就把这块硬骨头啃下来。
4.1 规则引擎架构：别把逻辑写死在代码里
我个人习惯，风控规则绝对不能硬编码。
为什么？因为业务变化太快。今天限制单笔下单量，明天要限制日内累计亏损，后天可能交易所出了新规。你总不能每次都改代码、重新部署吧？
所以，规则引擎的核心思想就是：规则与执行分离。
核心架构分层：
- 规则定义层：用 DSL（领域特定语言）或 JSON 描述规则。比如「当 order.quantity > 1000 时，拒绝」。
- 规则编译层：把文本规则编译成可执行的表达式树或字节码。
- 规则执行层：在交易流水经过时，逐条匹配规则，命中则触发动作（拒绝、告警、冻结）。
- 规则存储层：规则持久化到数据库或配置中心，支持热加载。
我在项目中遇到过最坑的事：规则引擎性能瓶颈。一开始用了解释执行的方案，结果高频交易时延迟飙到 50ms。后来换成了预编译 + 缓存，延迟降到 1ms 以内。你想想看，50ms 对于高频交易意味着什么？可能几百笔订单已经飞出去了。
4.2 策略编排：像搭积木一样组合规则
单条规则好写，难的是多条规则怎么组合。
比如：先检查用户是否在黑名单，再检查单笔金额是否超限，最后检查日内累计交易次数。这三条规则有先后顺序，而且可能互相影响。
我建议用 DAG（有向无环图） 来编排策略。每个节点是一条规则，边表示执行顺序。这样有几个好处：
- 可视化：运营同学能看懂，不用求着开发改代码。
- 可调试：哪条规则触发了，一目了然。
- 可复用：同样的规则可以出现在不同策略里。
小技巧：策略编排时，把「快速失败」的规则放在前面。比如黑名单检查，命中就直接拒绝，不用再往下执行了。这样可以节省大量计算资源。
我曾经帮一个客户优化风控策略，他们把所有规则串行执行，哪怕第一条就拒绝了，后面几十条规则还在跑。改成 DAG + 短路执行后，CPU 使用率直接降了 70%。
4.3 实时风控与离线风控结合
这里有个常见的误区：以为实时风控能搞定一切。
其实不是。实时风控要求毫秒级响应，所以规则必须简单、计算量小。但有些风控场景，比如「过去 7 天该用户的胜率是否异常」，这种计算量大的分析，放在实时链路里会拖垮系统。
我的做法是：实时风控做「快判断」，离线风控做「深分析」。
| 维度 | 实时风控 | 离线风控 |
|---|---|---|
| 响应时间 | < 10ms | 分钟级/小时级 |
| 规则复杂度 | 简单（阈值、黑白名单） | 复杂（统计模型、机器学习） |
| 数据范围 | 当前订单 + 缓存 | 全量历史数据 |
| 典型场景 | 单笔超限、重复下单 | 关联账户分析、策略回测异常 |
举个例子：实时风控发现用户 A 在 1 秒内下了 100 笔订单，直接拒绝。但离线风控跑完后发现，这 100 笔订单的对手方全是同一个账户，而且那个账户在 3 个月前被标记过异常。这时候离线风控会生成一个「关联账户风险报告」，更新到实时风控的黑名单里。
说白了，实时风控是「抓现行」，离线风控是「挖老底」。两者配合，才能做到滴水不漏。
4.4 核心流程：一张图看懂
下面这张图，是我在项目中实际使用的风控策略引擎流程。你可以看到实时和离线两条链路如何协同工作。
注意：离线风控的反馈回路是关键。很多团队只做了实时风控，结果发现异常账户能连续作案好几天。离线分析一定要能自动更新实时规则，形成闭环。
4.5 避坑指南
最后，分享几个我踩过的坑：
- 规则数量失控：我曾经见过一个系统，规则堆了 2000 多条，每次新增规则都要排查半天。建议定期清理无效规则，每条规则都要有负责人和有效期。
- 实时风控的「误杀」：阈值设得太严，正常交易也被拦了。我建议实时风控先走「告警模式」，观察一段时间再决定是否开启「拒绝模式」。
- 离线风控的「滞后」：离线分析跑完，黄花菜都凉了。要控制离线任务的调度频率，至少每 5 分钟跑一次增量分析。
嗯，风控策略引擎这块，说白了就是「规则 + 流程 + 反馈」。把这三件事做好，你的量化平台就能在合规的前提下，跑得又快又稳。
公众号:蓝海资料掘金营，微信deep3321