对于一个互联网公司而言，业务发展的不同阶段，对“业务安全”有着不同的目标和需求。自己已经在互联网物流行业（车货匹配）走过了近2年的时间，车货匹配对“业务安全”的目标和需求可以简单概括为:
1. 从业务功能角度
- 保障核心业务安全
“货主发货、司机找货”的场景中，货主发布的货源信息，司机的期望是拉货的需求真实的，信息的内容是规范的（不含敏感词等）；而货主的期望是承接运单的司机是真实的，可靠的，有真正拉货需求的，从而保障交易。
“反机器人爬货、恶意骚扰”的场景中，系统可以识别是机器人在对平台进行浏览货源信息，并进行屏蔽、蜜罐；
“司机与货主投诉”的场景中，提供接口让用户对货源交易中的不公平、不公正情况进行投诉，并离线分析投诉的可靠性、真实性
- 保障运营活动安全
“车货匹配的业务运营活动”场景中，有过“发多少次货”送“多少”积分、拨打“某类”货源送多少“积分”等。因此，防止“薅羊毛”也是一个很重要的需求
2. 从系统架构角度
- 业务安全系统需要是独立的，可降级的（在线的生产系统部分）。核心车货匹配系统（优化排序服务、搜索服务、货源服务等）与业务安全系统有着接口调用的耦合度，因此为了保障核心系统可靠，业务安全系统需要集成到统一的RPC管理框架及应用配置管理系统中，以实现统一的熔断、限流及业务/系统开关控制
- 业务安全系统需要有汇聚“业务安全”相关的各类大数据，围绕大数据存储系统，之上构建一套集抽取、转换，分析的系统及报表系统（离线的系统），可以让数据分析师、产品经理追溯数据（下钻、上卷等）。并可以离线地训练各类机器学习模型（增加、修改模型），对每个用户的行为数据进行事后离线甄别和事中的实时甄别
- “实时的甄别用户行为” 需要一套规则引擎，以达到产品经理可以随时根据离线学习的模型及业务规则进行线上规则改进，并且系统服务不重启
- 其他的诸如与用户中心系统对接、统一配置中心系统对接，就不赘述了。
再来说说业务安全系统的架构吧
先上张架构图
系统架构
根据系统的调用场景，将系统服务分为“在线”的供核心系统实时调用的系统及“离线”的用户行为分析系统服务（其中，大数据实时计算平台和业务安全规则引擎服务完成事中的规则判定）
1. 在线部分
- 业务安全业务接口层，提供在用户发货、找货时判定用户是否属于某类嫌疑用户或者应该禁用的行为
- 业务安全惩罚中心服务，维护各类被惩罚、投诉的用户信息及惩罚配置
2. 离线部分
- 实时计算平台+业务安全指标转换与增强服务+业务安全规则匹配引擎，构成了离线的对用户行为指标实时统计及规则匹配的过程，离线（近实时的）对用户行为进行监测、惩罚
- 业务安全大数据分析平台，提供事后的用户行为数据分析，可以拓展各类模型，对用户行为进行学习分类。同时，对数据进行转换、聚合（构建用户行为数据维度的大宽表），供BI系统和指标监控系统分析读取。
这一篇简单总结一下业务安全系统在‘非主站应用’环境下的‘指标转化与增强’、‘业务安全规则引擎’两个服务在当初设计时的一些考虑。
首先，为什么需要这两个服务？
背后的逻辑是这样的，‘业务安全’系统为了能够识别用户的“非法”行为：
- 需要不断收集用户在平台上产生的各类行为数据，数据流向“实时计算平台”和“大数据存储平台”
- 基于数据，对业务安全关注的各个‘指标’/特征值 (针对的都是每个用户的‘指标’，如，‘过去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:
整个业务安全系统（工程部分）从最早的版本更新上线到目前的版本大致花了一个多月的时间，其中对设计思路、协议定义规范、脚本语言的选择等等架构决策也偶有反复，废弃了一些原有的代码，但团队最后还是都坚持了下来。整个过程走过来回头来看，留下的也都是财富。
原文发布时间为：2018-03-28
本文作者：冯鑫
