风控系统之规则条件&操作增强，名单&标签&消息模版管理
提要
再次说明，此项目还在开发中，还有很多事情要做，并不完善。回想起来，我也觉得挺不可思议的，最开始只是尝试着做，想着把后端做的差不多就行了，可做着做着，愈发确信前端是必不可少的，也因此项目发展到了现在的地步。可以从Github的commit看出来，也是最近半年比较活跃，也是这期间，学到的最多，进展比较快。
本篇文章主要围绕着规则条件与操作、名单&标签&消息模版的管理。
再强调一下，开发版本不代表最终成品。
名单&标签&消息模版
还是回顾一下之前讲的，规则就是IF(x){a}ELSE{b}，其中x为条件，a和b是动作/操作。在规划中，条件不仅仅是简单的普通类条件，还有指标、名单、正则、脚本等，最近也完善了这部分。开始之前我必须要从名单&标签&消息模版说起，方便下面的规则操作展开。
名单
名单在规划中分为名单集和名单数据，有点像字典和字典数据的关系。
名单集顾名思义，名单数据的集合，归类名单数据用的。
名单数据，选择名单集，输入数据，并标记来源。
名单集可以用在规则条件判断上，也可用在命中或未命中规则操作上，往下看就知道了。
标签
需要注意标签是事件纬度的标签，不是用户纬度的，不同于用户画像，当然也可以这么做。
标签可以手动为事件添加，也可以通过规则添加（作为规则操作）。
消息模版
消息模版就是如短信、邮件、webhook等消息的模版，比较常见的场景就是非常用设备/IP登录预警等等，甚至可以是主动的触达推送，新活动等等。
比较不同的是这里使用Mentions组件方便对于字段的引用。
指标字段类型限制
这个是标题里没有提及的，指标配置中字段类型的限制增强。
在之前已经讲过了，但是一直没时间做，这次终于完善了，简单来讲就是不同指标对于计算字段要求是不同的，如通常的聚类指标（求和、最大值、最小值、平均等）指标计算字段只能是整数和小数，新增不同的指标的话还会有些不同。
同时指标的返回类型也不都是整数和小数，还有历史取值等指标返回值是配置时确定好的。
规则条件&操作
终于到正题了，前面说的那些都是要在这里再次被提到的。正如标题所说，这次主要是增强条件和操作。
条件
1、条件右变量类型同左变量类型
如下，当左变量选择日期字段，常量都是无所谓的，输入的（未来要不要根据类型变化数据录入组件？还不确定），但是如果是变量，那么右变量只能是左变量同类型的。
2、丰富的条件类型，指标条件、名单条件、正则条件、脚本条件
如下，条件组件增强，支持各种条件类型，这里分别添加了指标条件、名单条件、正则条件、脚本条件，他们是不同的。
普通条件，之前使用的都是此类型，不过多介绍了。
指标条件，只能选择已上线的指标，其他使用和普通字段一致，包括左变量右变量类型一致限制。
名单条件，名单条件左变量不变，主要还是字段，逻辑操作为在/不在，右变量选择名单集。
正则条件，依然左变量字段，逻辑操作如下，右变量是自定义的正则表达式。
脚本条件，只有一个输入框，这个还待完善，有点想做成QLExpress的表达式形式。
小结一下，虽然看上去只是变化了这么一点，但是其实是对条件数据结构和条件组件的抽象与实现，不仅仅是后端，还有前端很多都是抽象的组件和可复用的函数等等，是一种工程化的体现。
简单一说，条件组件可以设置组合的深度，如上都是配置的两层，理论上可以配置任意层，不过这没必要，还有就是条件组件只有一套，所以规则和指标用的是一套，但是指标不会有这些复杂的丰富条件，这也是需要组件抽象设计的。
操作
如果有看之前的介绍文章，其实可以看出规则条件多了一块内容，如下，就是规则操作，目前包含添加标签、添加名单、发送消息、设置字段。
添加标签
添加标签就是为当前事件配置添加的标签，是个多选框。
添加名单
添加名单就是选择某的名单集和字段，最终会将字段数据作为名单集数据添加，同时来源设置为规则。
发送消息
发送消息就更容易理解了，预警、推送都可以，不过目前设计的还有些问题，消息目标是谁呢？本次手机号？邮箱？还是其他？还待完善。
设置字段
设置字段也是待完善，尤其是使用场景，是用做流程编排中，还是其他的什么？
当然作为简单的临时变量使用也是可以的。
小结
以上这些都是简单的介绍，这些在LiteFlow的设计中都是组件，可以任意定制化。
另外如果细想其实是有问题的，已知之前的设计规则的集合是策略，如果是多条规则命中，这些操作是如何之行的，全部都执行，还是以最终的一个为结果执行？不能同时发送几条奇怪的消息吧？标签和名单倒是可以一起做。
其他文章推荐
目前还比较零散，未来有时间会系统整理一下。
全局
规则引擎可以应用于哪些系统，用户画像、触达、风控、推荐、监控...
策略/规则篇
指标篇
风控系统指标计算/特征提取分析与实现01，Redis、Zset、模版方法
数据篇