项目地址：github.com/wnhyang/coo...
前言
如果对此此项目还不了解可以先看下面两篇文章
正如前文所讲，开始分支开发了，规划中main对应开源主分支（功能有限），pro对应标准付费分支，当然未来可能还会有pro-max🥳，demo对应在线体验分支，目前是基于pro增加一些限制和不一样的东西。
所以在线体验版本并不是开源版，会有些差别。
最近
在开始之前还是先回顾一下最近做的事情吧！
最近除了在main分支做优化更新外，还要在pro分支做规划中的事情，说起来是这么概括就够了，但是其实事情很多，不仅是前端后端项目的迭代优化，更重要还有除编程外的其他事情。
其中花费时间最多的是在做开放在线体验上，因为这并不是简简单单的将服务部署在公网上这么简单的事，不过回头来看好像也就是这么简单的事情😂
因为放在公网上总要考虑很多安全性上的问题，记得之前买的服务器因为配置了常用安全组，并设置了简单的密码导致服务数据全没了，收到了"比特币换数据的要挟"，不过还好那台服务器就是自己随便玩玩的，没什么重要数据。除了数据问题之外，更有甚者被黑客攻击后被作为挖矿服务器，频繁高CPU，并收到云厂商的告警通知法律法规发现挖矿脚本要本人确定，挺麻烦的。自那之后，在这方面就谨慎起来了，不管是开发测试，密码都尽可能设置的复杂一些🥲怕了怕了
表单校验完善
完善表单校验，对于普通的字段的校验相对简单，对于系统中如复合条件的校验也做了加强。
左/逻辑判断/右，递归等等。
批量发布
抽象了发布组件，新增批量发布组件
事件数据
事件数据存储在ElasticSearch中，相关代码也只写在pro分支。
这部分重点在于ES索引的设计与检索数据的实现。
如下是目前事件数据页，支持复杂多条件查询
因为决策流配置还未完成，在面对多策略结果时，如何综合所有结果还在考虑中，所以目前所有结果都是"通过"。
同样高级搜索这里做了校验
点击行即可看事件详细数据
字段-指标-策略
部署相关
上篇预热在线体验的文章也有展示
项目使用了云效的devops，采用Docker镜像部署方案，详细的如Dockerfile和docker-compose.yaml可以另开一篇文章讲。
安全
要开放在线体验势必要考虑安全问题，包含服务器、中间件、账号、接口等等。
后端项目也为一些接口增加了权限校验，在线体验一定会限制的！
在线体验
再啰嗦一下
自己写的当然最为熟悉，对于目前有哪些问题，下一步怎么做，我是有比较清晰的规划的，但还是那句话，没有那么多时间精力啊🤪
除了大方向的功能/流程/交互方式/表/接口等等，更细节的如使用什么组件，那个方法需要优化，大概什么样式都是考虑中的，这些平常都记录在我的todolist中，每完成一项就删除一项，或者迁移到产品说明书/备忘录中。
方式
关注公众号，私信或是加好友后，说明"在线体验"就好。
我会分配一个专有账号，此账号会有权限限制（这当然是必须的，主要是一些查询和新增的权限，修改、删除等等是没有），而且账号默认有效期只有7天。
如果人员过多，我会设置几个公用的账号（因为设置了同账号不允许多地登录，所以有挤掉的情况😅）。
毕竟是自费服务器，还是要限制一下。
当然这些只是此刻的规划，未来可能需要申请填写个人或公司信息、目的等等，也不一定，也有可能什么时候就关闭在线体验也不一定🙂↔️
关于反馈问题的渠道，当然私信和私聊都是可以的。
群聊的话，一直都没有，但如果开放在线体验了，想发一些公告，如："维护中不可访问"，那么群聊就很有必要了。关于这个请看下面"交流群"。
使用
关于系统如何工作的前面有很多文章了，不想在这里赘述了，未来尽量去补充详细的官方文档（产品、技术），敬请期待吧。
1、接口
每配置一个接入就有三个接口可用，/test、/sync、/async如下，test需要登录，sync适合需要决策的场景，async不会决策。
2、参数
接口参数就是下图配置的这些
在线体验中配置了已经一个策略，发送时注意必须的几个字段就行，如下
{
"appCode": "app",
"policySetCode": "appLogin",
"eventTime": "{{$date.now}}",
"transSerialNo": "{% mock 'uuid' %}",
"eventCode": "event1234"
}
平常我都是使用下面这种方式发的
curl参考，mock的数据
curl --location --request POST 'http://127.0.0.1:8081/decision/public/sync'
--header 'Content-Type: application/json'
--data-raw '{
"appCode": "app",
"policySetCode": "appLogin",
"eventTime": "2025-03-29 23:31:31",
"transTime": "2025-03-29 23:31:31",
"transAmount": 1098.52734,
"transSerialNo": "9b926aae-3379-4845-8e91-b9c5913dc118",
"payerAccount": "123456",
"payeeAccount": "654321",
"payeeName": "薛娜",
"payerName": "董军",
"payeeType": "反外合年他",
"payerType": "龙和民角",
"payeeRiskRating": "HIGH",
"payerRiskRating": "HIGH",
"payeeBankName": "ABC Bank",
"payerBankName": "XYZ Bank",
"payeeAddress": "罗平县 福建省 上海市",
"payerAddress": "改则县 广西壮族自治区 泰州市",
"payeePhoneNumber": "18104207857",
"payerPhoneNumber": "18654274834",
"payeeIDNumber": "640000200005293830",
"payerIDNumber": "630000197905127364",
"payeeIDCountryRegion": "US",
"payerIDCountryRegion": "US",
"ip": "134.172.96.72",
"lonAndLat": "4.514,134.44342",
"account": "019741048",
"deviceId": "e",
"bindDevice": "true",
"eventCode": "event1234"
}'
3、响应
响应结果自己试一下吧。
服务器日志大概如下，目前影响耗时也还好。
从决策的角度来看，这一步已经结束了，接下来就是调用方如何使用决策结果了，当然反馈机制也是需要的。
4、验证
参考前面的事件数据查看是否符合规则配置，是否按照策略运行。
交流群
交流群其实我是比较推荐qq频道的，因为几点
-
成员数量上限高
-
无论加入时间，历史消息可见
-
不仅仅是聊天，还有帖子
-
等等
交流群可作为官方通知，因为公众号是有消息限制的，所以这种交流群是最好的，另外可以听到大家的声音，有利于我们的共同成长
至于共同开发/运营，也还在考虑中。
未来
不管是开放在线体验还是交流群都是需要精力去运营的，个人精力实在有限，我也想把一天掰开来用，还想拔几根毫毛生成几个分身呢🥹但实在是没空啊！
开源版大概就是修修补补了，pro应该会成为未来主要重心。
其他文章
全局
规则引擎可以应用于哪些系统，用户画像、触达、风控、推荐、监控...
策略/规则篇
指标篇
风控系统指标计算/特征提取分析与实现01，Redis、Zset、模版方法
数据篇