接上一篇（业务安全系统浅谈（一）），这一篇简单总结一下业务安全系统在‘非主站应用’环境下的‘指标转化与增强’、‘业务安全规则引擎’两个服务在当初设计时的一些考虑。
首先，为什么需要这两个服务？
背后的逻辑是这样的，‘业务安全’系统为了能够识别用户的“非法”行为：
- 需要不断收集用户在平台上产生的各类行为数据，数据流向“实时计算平台”和“大数据存储平台”
- 基于数据，对业务安全关注的各个‘指标’/特征值 (针对的都是每个用户的‘指标’，如，‘过去30（指标可配）分钟内的货源的点击次数’，‘司机过去3个小时（指标可配）内的GPS 位移距离’，过去2个小时内（指标可配）手机的重力感应数据变化等等) 进行累计计算（’指标‘累计计算的公式，通过后台配置自动生成代码在实时计算平台上进行执行、存储结果）
- 业务安全规则的定义（用groovy或 js 等语言描述的snippet -- 我们用的js）在后台配置，配置结果是一组按‘场景’组织的可执行的rule set(规则集，其中每个rule 分为rule trigger和rule action 两个部分（其实是一些用js写的 snippet codes）及规则中所关联的各类‘指标’/特征值
例子-业务安全规则定义
- 通过实时计算平台，将用户行为数据进行过滤，并按‘场景’ 分类输出（输出成raw_event_data）。这里‘场景’（通过sceneId表征，见上图）的概念在车货匹配业务中分为，‘searchCargo’(货源搜索), 'viewCargo'（查看货源）, 'phoneCall'（拨打货源），‘发布货源’（sendCargo），‘填写货源备注’等等（也可以组合定义）。‘场景’ 的定义不仅用于分类输入给 '指标转化与增强'服务的raw_event_data， 还用于关联输入给规则引擎的事实数据（rule_fact_data）及规则的定义部分（rule set）
(铺垫了这么多，才讲到“为什么” ~~~~)
- '指标转化与增强'服务将消费MQ（kafka）中的raw_data，根据其sceneId 来匹配所定义的业务安全规则集（rule set），及rule set 关联的‘指标’定义，来“转化和增强” raw_event_data 成为rule_fact_data
例子-Raw_Event_Data 结构
例子-Rule_Fact_Data 结构
- '规则引擎'服务则接收rule_fact_data, 根据其中的sceneId 来匹配rule set 并执行每个rule 的rule trigger 部分和rule action 部分。 脚本引擎采用的是java 8 中的nashorn。 当初决定采用哪种语言（甚至开源的rule engine 框架）来描述和定义规则，着实有一个曲折决策的过程
-- 我们看了drools。但认为drools 着实有些重，虽然对于各类复杂的rule set 的组织（一个完备的规则引擎所需的“规则互斥”、“规则冲突”、“规则执行顺序”设置等能力均支持良好）及执行效率支持的非常好，但真的不太适合我们的场景。我们预想的是，随着系统的不断演进，情况可能真不是像预想的那样美好---- “提供一个各项规则配置能力灵活的后台，产品或运营同学可以信手拈来随意配置各种复杂的业务规则”，而实际上却可能更加骨感一些 ---- “提供有限的场景及指标的定义，通过后台来配置成业务安全的规则；生成规则的过程，通过预定义的规则模板来生成。个别的情况，可以提供一个text 框，让RD 来辅助写rule codes 且可以实时地更新到线上并生效”。在这种考虑之下，drools 就pass 了，而决定采用某个脚本语言来自己实现一个规则引擎
-- 至于脚本语言的选择，就没那么纠结了。当时，在其他项目里面已经有采用js 来构建规则引擎的使用经验（很简单的使用），虽然groovy 是一个很好的option （JS 和 Groovy 都‘近’ java，都比较容易集成使用），但还是放弃了（考虑时间等等成本）
再补一张图，应该就更清晰了
调用时序图
PS:
整个业务安全系统（工程部分）从最早的版本更新上线到目前的版本大致花了一个多月的时间，其中对设计思路、协议定义规范、脚本语言的选择等等架构决策也偶有反复，废弃了一些原有的代码，但团队最后还是都坚持了下来。整个过程走过来回头来看，留下的也都是财富。
感谢团队成员 - 曹雷、赵伟、陈长、王雪强、李昆鹏、牛迁迁的努力与贡献！
这里没有对系统细节的实现做过多的介绍，如果有对业务安全系统搭建感兴趣的同学，欢迎大家一起讨论并学习进步。毕竟，业务安全的topic 非常之丰富。
网友评论