博客停更了

因为个人博客运营比不上现如今的微信公众号等等渠道，所以今后所有内容统一更新在微信公众号和语雀中。

个人语雀：wnhyang

共享语雀：在线知识共享

Github：wnhyang - Overview

项目地址：https://github.com/wnhyang/coolGuard

前言

如果对此此项目还不了解可以先看下面两篇文章

基于规则引擎的风控决策系统介绍与演示

风控系统之规则条件&操作增强，名单&标签&消息模版管理

正如前文所讲，开始分支开发了，规划中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、参数

接口参数就是下图配置的这些

在线体验中配置了已经一个策略，发送时注意必须的几个字段就行，如下

1
2
3
4
5
6
7

{  
"appCode": "app",  
"policySetCode": "appLogin",  
"eventTime": "{{$date.now}}",  
"transSerialNo": "{% mock 'uuid' %}",  
"eventCode": "event1234"  
}  

平常我都是使用下面这种方式发的

curl参考，mock的数据

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

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应该会成为未来主要重心。

其他文章

全局

规则引擎可以应用于哪些系统，用户画像、触达、风控、推荐、监控...

基于规则引擎的风控决策系统介绍与演示

风控系统之规则重复触发

LiteFlow上下文与组件设计，数据依赖梳理

交易事件的生命周期，事前事中事后风控，结果通知/回调

策略/规则篇

风控系统之普通规则条件，使用LiteFlow实现

风控系统之通用规则条件设计，算术单元/逻辑单元/函数式接口

LiteFlow决策系统的策略模式，顺序、最坏、投票、权重

指标篇

风控系统指标计算/特征提取分析与实现01，Redis、Zset、模版方法

基于LiteFlow的风控系统指标版本控制

风控系统指标版本管理，前端实现

风控系统之指标回溯，历史数据重跑

业务链指标，用户行为模式识别，埋点系统

数据篇

风控系统之数据服务，名单、标签、IP、设备、地理信息、征信等

GeoHash处理经纬度，降维，空间填充曲线

前言

1. 远程接口调用模式

   • 技术特征：基于HTTP/API实时交互，需实现三方服务接口的协议适配（如RESTful、GraphQL、gRPC），并内置重试、熔断、限流等容错机制。
   • 核心约束：
     • 依赖服务商的接口稳定性与性能上限（如QPS、TPS阈值）；
     • 受限于套餐化流量配额（如API调用次数、数据返回量）；
     • 数据实时性高，但无法脱离三方系统进行深度加工或长期存储。

2. 数据源批量同步模式

   • 技术特征：通过ETL/CDC工具（如Airbyte、Debezium）周期同步全量或增量数据至本地/私有化存储（如HDFS、数据湖），支持自定义计算引擎（如Spark、Flink）进行分布式处理。
   • 核心优势：
     • 服务自主性：可基于业务需求动态扩缩容计算与存储集群（如Kubernetes弹性调度），支撑高吞吐、低延迟场景；
     • 数据治理自由度：支持灵活定义数据清洗、脱敏、聚合等加工链路。
   • 实施挑战：
     • 需严格遵循服务商的数据安全策略（如访问权限审批、加密传输协议、存储隔离机制）；
     • 数据同步时效性受服务商同步接口开放粒度影响（如仅允许T+1全量导出）。

本篇只展开远程接口调用模式，以地理信息数据服务举例，重点分析高德和天地图。

1、供应商

这里指的就是高德和天地图，其作为供应商，同时也是数据源。

如在高德开发平台（天地图也是按应用分的），会以应用纬度再划分，同时服务是多种的。据此可以抽象供应商（供应商id、供应商名称、应用、应用密钥、合同编号、合同其他信息等等）。

2、服务

供应商对多个应用，高德和天地图是一致的，但是下面服务就不一致了，天地图所有服务密钥就是应用密钥，高德是应用下新建服务后服务密钥是独立的。

每种服务对应不同的接口和请求响应配置。

https://lbs.amap.com/api/webservice/guide/api/georegeo

http://lbs.tianditu.gov.cn/server/geocoding.html

那么可以抽象服务（服务id、供应商id、服务类型、请求方法、请求路径、请求头、参数、请求体、超时时间、重试策略），当然所有这些都可以硬编码实现，但是本篇目标是抽象通用设计方案，用于后面的灵活配置。

3、套餐与计费

套餐与服务是关联的，通常模式有每天/月/年免费额度，超量阶梯计费，包年/季/月等。

作为服务调用方，出于成本的考虑，费用当然相当关键，但是不同服务商的套餐与计费模式又不是那么容易抽象统一，从另一方面来讲灵活的服务调用（包含降级、重试策略等）只需关心接口相关的配置就好了，至于具体的费用，我比较建议不做，首先增加了复杂度，另外高德这样的三方数据服务商都会有开放平台，提供控制台用于服务的管理、流量分析、费用结算等等功能，非常丰富，作为服务使用方最好数据调用明细记录就已经不错了。

就像dify、coze的工作流编排时，重点是接口的配置，而不是数据服务商和费用的管理（当然不是说这些不重要）。

4、缓存与预警

缓存除了可以是接口的配置，如请求体配置模版外，还可以是具体的三方数据缓存，当然这个要慎重，一致性和资源问题要考虑清楚了。

其实不管是上面讲的流量治理（降级、熔断、重试、超时、限流等等）和预警都是通用型设计，是现代高可用服务必然考虑的事情。

AI设计方案

AI设计方案仅供参考

一、三方数据管理模块

1. 供应商表（supplier）新增字段

2. 供应商套餐表（supplier_plan）

二、计费管理模块

1. 计费价格配置表（price_config）扩展

2. 用户套餐订阅表（user_subscription）

三、请求与响应管理模块

1. API请求配置表（api_config）

2. 参数校验表（api_param）

四、缓存管理模块

1. 缓存配置表（cache_config）

2. 缓存记录表（cache_data）

五、监控与预警模块

1. 预警规则表（alert_rule）

2. 预警日志表（alert_log）

六、降级与熔断模块

1. 降级策略表（fallback_policy）

2. 熔断日志表（circuit_breaker_log）

七、表关系与优化

1. 核心关系
   • supplier_plan.supplier_id → supplier.supplier_id
   • api_param.config_id → api_config.config_id
   • fallback_policy.backup_api_id → api_config.config_id
2. 索引优化
   • 高频查询字段：supplier_id、api_method、triggered_at
   • 分区策略：按时间范围对日志类表（如api_request_log、alert_log）进行分区。
3. 性能扩展
   • 使用读写分离和分库分表策略，分离高频操作表（如api_request_log）和低频配置表。

八、关键流程示例

1. 计费流程
   • 用户调用API → 检查user_subscription剩余额度 → 若超出免费额度，按price_config阶梯价扣费 → 记录billing_detail并更新balance_transaction。
2. 降级流程
   • API连续失败 → 触发circuit_breaker熔断 → 查询fallback_policy → 返回default_data或调用backup_api_id备用接口。
3. 缓存流程
   • 请求到达 → 根据cache_config.key_pattern生成缓存键 → 查询cache_data → 若命中且未过期，直接返回数据；否则调用三方接口并缓存结果。

小结

为什么会有这篇文章，当然还是离不开此项目https://github.com/wnhyang/coolGuard

因为这是计划中的一部分，而且不可或缺。

参考

https://www.woshipm.com/it/5662657.html

https://www.woshipm.com/it/4269498.html

https://www.cnblogs.com/hole/p/16349359.html

https://zhuanlan.zhihu.com/p/515516955

https://zhuanlan.zhihu.com/p/461217285

https://www.tongdun.cn/product/xhbigdata

前言

包含AI辅助创作！！！

在数据驱动的商业生态中，三方数据（即企业外部第三方机构提供的数据）已成为企业突破信息孤岛、实现精准决策的关键资源。面对数据量指数级增长与合规要求的日益严苛，构建高效、安全的三方数据管理体系，不仅是技术挑战，更是企业获取竞争优势的战略选择。

一、三方数据管理的价值与挑战

1. 核心价值

   • 决策赋能：通过整合第三方市场调研、用户行为、行业趋势等数据，企业可提升决策精准度。
   • 流程优化：物流企业利用三方交通数据优化路线，降低运输成本，提升准时率。
   • 风险防控：金融机构引入第三方信用数据，下降不良贷款率，有效规避信贷风险。

2. 关键挑战

   • 数据安全与隐私：2017年Equifax数据泄露事件导致1.43亿用户信息暴露，凸显数据保护的重要性。
   • 质量参差不齐：不同来源的数据存在格式冲突、缺失值等问题，清洗成本占整体管理成本的30%-40%。
   • 法规合规：欧盟GDPR、中国《个人信息保护法》等法规对跨境传输、数据授权提出严格要求，违规罚款最高可达全球营收4%。

二、技术架构设计：模块化解决方案

1. 供应商与合作方式

• 供应商资质审核：

  • 建立供应商资质审核流程，记录供应商的营业执照、服务资质、数据来源合法性等信息，确保合作方符合法律法规要求。

• 合同管理与SLA：

  • 存储供应商合同信息（如服务范围、交付周期、赔偿条款等），并关联SLA（服务级别协议），定期评估供应商服务质量。

2. 套餐与计费

• 套餐：

  • 不同供应商通常对应着不同的套餐，如每天/月/年免费额度，超量阶梯计费，包年/季/月等

• 计费：

  • 支持免费额度（如每月1000次免费调用）、阶梯定价（超过阈值后按0.1元/次计费）、包年套餐（如10万次/年，价格8折）。

3. API请求与参数

• API权限控制：

  • 管理API的访问权限，确保只有授权用户或角色可以调用特定API。

• API版本管理：

  • 支持API版本化管理，通过路径或请求头标识API版本，确保新旧版本兼容性。

• 动态请求模版：

  • 请求方法、path、header、params、body、超时策略、重试配置等。

4. 缓存与性能优化

• 缓存预热机制：

  • 在系统启动或特定时间点，提前加载高频API的缓存数据，提升初始访问性能。

• 智能缓存策略：

  • 按API方法配置缓存键规则及TTL（如1小时），保证数据正确性的同时提高命中率，减少三方调用压力，适当降低成本。

5. 监控预警与流量治理

• 多维度阈值预警：

  • 错误预警、超时预警、套餐预警等等，通知邮件、短信、群消息。

• 降级策略：

  • 当主API不可用时，自动降级为更简单的接口或提供默认值，确保系统可用性。

• 熔断策略的动态调整：

  • 根据历史数据和实时负载情况，动态调整熔断阈值和恢复时间。

6. 数据质量管理

• 数据清洗规则管理：

  • 通过规则引擎管理数据清洗策略，支持动态添加或修改规则。

• 数据质量报告：

  • 定期生成数据质量报告，展示数据清洗结果、异常情况及改进建议。

• 数据回溯机制：

  • 支持对清洗或处理后的数据进行回溯，确保数据可追溯性。

7. 安全与合规

• 审计日志管理：

  • 记录所有敏感操作（如数据修改、权限变更）的审计日志，支持按时间范围或操作类型查询。

• 安全策略版本管理：

  • 支持安全策略的版本控制，确保变更可追溯。

• 数据脱敏：

  • 对敏感字段（如身份证号、手机号）进行脱敏处理，确保数据在传输和存储过程中的安全性。

三、未来趋势：AI与生态协同驱动升级

1. AI赋能数据治理

   • 智能清洗与标注：通过机器学习模型自动识别异常值（如订单金额超10倍标准差），标注数据质量等级。
   • 预测性分析：利用三方数据训练需求预测模型，提前6个月预判市场趋势

2. 区块链数据共享

   • 可信数据市场：通过区块链记录数据授权与使用链路，解决多方数据共享中的信任问题。
   • 溯源机制：当数据争议发生时，可追溯至原始供应商及处理节点（如某医疗数据合作项目降低纠纷率70%）。

3. 跨行业生态融合

   • 数据联盟：汽车行业联合共享用户驾驶数据，共同开发智能车险产品。
   • 标准化接口：建立行业数据交换协议，降低整合成本50%。

四、实施建议

1. 组织架构：组建数据治理委员会，包含技术、合规、业务三方负责人，定期评审数据策略。
2. 技术选型：优先采用云原生架构（如AWS Data Exchange）加速部署，利用Serverless函数减少运维负担。
3. 合规自查：每季度进行GDPR合规扫描，确保用户数据访问权与删除权落实。

三方数据管理已从单一的技术问题演变为企业数字化战略的核心。通过构建模块化技术体系、拥抱AI与区块链创新，并建立跨行业协作机制，企业不仅能有效应对安全、质量、合规挑战，更能释放数据协同价值，在数字化竞争中构建可持续优势。

参考

《风控要略：互联网业务反欺诈之路 (马传雷,孙奇,高岳)》第8章

## 一、核心概念

1. 指标定义：在风控反欺诈业务中，无论是基于专家规则还是风控模型，都需要依赖对一定时间范围数据进行回溯加工的变量，这些变量被称为指标。例如“1天内设备上登录的账户过多”这一规则，就需要回溯24小时的历史数据，计算该设备在这段时间内登录的账户个数，并与配置的阈值进行比较判断。

2. 指标类型：

   • 频度-出现次数统计：如IP最近5分钟注册次数、手机号最近1小时接收短信次数，次数过多可能对应垃圾注册、短信轰炸等风险。
   • 频度-关联个数统计：像1天内同一设备接收短信的手机号个数、7天内同一设备充值的账户个数，个数过多可能涉及群控设备、群控账号等风险。
   • 活跃天数：例如账户最近7天活跃次数、设备最近1个月活跃次数，活跃次数过少可能意味着是僵尸用户。
   • 移动距离：如设备最近1小时移动距离、设备最近24小时移动距离，移动距离过远可能存在虚假定位的风险。
   • 常用习惯：包括账户最近7天常用设备型号、账户最近30天常用登录城市，常用型号或城市不一致可能暗示账户被盗等情况。
   • 趋势计算：如账户最近1天多笔交易支付金额递增、账户最近1天先小额后大额支付，支付趋势异常可能与盗卡试探等风险相关。
   • 其他：例如账号最近5分钟密码连续错误次数，连续错误可能是账户遭受暴力破解的迹象。

3. 指标特征：

   • 时间窗口：指标计算所针对的特定时间段，如5分钟、1小时、1天等。
   • 事件：与指标相关的业务活动，如注册、登录、交易等。
   • 主属性：指标计算所围绕的主要对象，如IP、手机号、设备、账户等。
   • 副属性：辅助主属性进行指标计算的属性，如在计算设备接收短信的手机号个数时，手机号就是副属性。
   • 计算逻辑：对数据进行处理和计算的方式，如求和、去重求和、统计出现次数最多的设备型号等。

介绍

在前文免费使用满血版DeepSeek-R1的多种方案中已经对大语言模型（LLM）应用开发平台有了相关介绍了，如下：

以 Dify 为代表的生成式 AI 应用平台，具备以下显著特性，为 AI 应用开发带来了新的变革：

• 低代码 / 无代码开发：提供了极为直观的可视化界面，用户无需深入了解复杂的底层技术细节，只需通过简单的拖拽和配置操作，就能快速定义 Prompt、上下文、插件以及工作流。这一特性大大降低了开发门槛，使得非技术人员也能够参与到 AI 应用的构建和迭代过程中，加速了 AI 应用的开发进程。
• 多模型支持与灵活编排：支持 OpenAI、Claude、通义千问、讯飞星火等众多主流大语言模型，同时允许用户通过 API 集成自定义模型，充分满足了不同业务场景的多样化需求。通过模型编排（Agent Design）技术，用户可以将不同的智能体进行组合，将复杂任务进行分解并协同完成，有效突破了单一模型的能力边界。例如，在一个智能问答系统中，一个智能体负责解析用户输入的问题，另一个智能体根据问题生成回答内容，第三个智能体则对生成的回答进行优化，从而为用户提供更准确、更优质的答案。
• 模块化设计与丰富功能组件：采用了先进的模块化架构，提供了包括 RAG（检索增强生成）引擎、Agent 框架、工作流编排、模型管理等一系列丰富的功能组件，全面覆盖了从原型设计到生产部署的整个生命周期。其中，RAG 引擎支持 PDF、PPT、CSV 等多种常见文档格式的文本提取与索引，并且提供了高质量的向量检索模式和经济实惠的关键词索引模式，用户可以根据自身需求和成本预算进行选择，在保证准确性的同时，有效控制成本。
• 企业级功能与 LLMOps 支持：

• • 知识库管理：支持将企业的私有数据进行集成，通过科学合理的分段策略和清洗规则对检索效果进行优化，确保 AI 在回答问题时能够基于准确、专业的知识，为企业提供可靠的智能服务。
  • 监控与优化：提供了全面的应用性能监控、交互数据分析以及成本跟踪功能，能够根据生产过程中产生的数据，对应用进行持续的优化和改进，这完全符合 LLMOps 的核心理念，有助于企业不断提升 AI 应用的质量和效率。
  • 灵活部署：支持本地化私有部署（如 Docker）和云端托管两种方式，企业可以根据自身对数据安全和合规性的要求，选择最适合的部署方案，确保数据的安全性和业务的合规运营。

• 广泛的应用场景：涵盖了智能客服、内容生成、代码辅助、知识问答等多种常见场景，支持快速构建 MVP（最小可行产品），也可以方便地集成到企业现有的业务系统中。例如，通过 Agent 工具调用外部 API（如 Google 搜索、Stable Diffusion），能够扩展 LLM 的能力，使其能够完成如联网检索、图像生成等复杂任务，为用户提供更强大、更全面的服务。

参考

阿里TTL：https://github.com/alibaba/transmittable-thread-local

TLog：https://tlog.yomahub.com/

背景

推荐阅读：https://tlog.yomahub.com/pages/5b7bd2/，本篇文章也是看了TLog的官方文档和相关源码而产生的。

在微服务架构中，由于线程池复用、异步调用等机制的存在，传统的线程级日志标识（如ThreadLocal）会导致请求链路断裂。例如，当主线程将任务提交到线程池时，子线程无法自动继承主线程的上下文信息，使得日志中的traceId丢失。

核心组件原理

MDC机制

Log4j2的Mapped Diagnostic Context（MDC）通过ThreadLocal存储线程级上下文数据。例如，在HTTP请求进入时，通过拦截器将traceId存入MDC，日志模板中通过%X{traceId}动态替换值。

TransmittableThreadLocal（TTL）

阿里的TTL组件解决了线程池场景下的上下文传递问题。通过装饰线程池，TTL在任务提交时自动拷贝父线程的上下文到子线程，并在任务结束后清理副本，确保多级线程池调用链路完整。

日志模板配置

在log4j2.xml中配置PatternLayout，添加%X{traceId}占位符即可实现日志标识嵌入。

1

<Property name="LOG_PATTERN" value="%d{yyyy-MM-dd HH:mm:ss.SSS} [%X{traceId}] [%t] %-5level %logger{36} - %msg%n"/>

提要

前文：基于规则引擎的风控决策系统介绍与演示

再次说明，此项目还在开发中，还有很多事情要做，并不完善。回想起来，我也觉得挺不可思议的，最开始只是尝试着做，想着把后端做的差不多就行了，可做着做着，愈发确信前端是必不可少的，也因此项目发展到了现在的地步。可以从Github的commit看出来，也是最近半年比较活跃，也是这期间，学到的最多，进展比较快。

本篇文章主要围绕着规则条件与操作、名单&标签&消息模版的管理。

再强调一下，开发版本不代表最终成品。

名单&标签&消息模版

还是回顾一下之前讲的，规则就是IF(x){a}ELSE{b}，其中x为条件，a和b是动作/操作。在规划中，条件不仅仅是简单的普通类条件，还有指标、名单、正则、脚本等，最近也完善了这部分。开始之前我必须要从名单&标签&消息模版说起，方便下面的规则操作展开。

排名不分先后

一、综合型AI平台

1、DeepSeek官方：https://chat.deepseek.com/，支持网页端与 APP 端使用

2、腾讯元宝：https://yuanbao.tencent.com/chat，支持网页端与 APP 端使用

基于规则引擎的风控决策系统介绍与演示

项目介绍

项目地址：https://github.com/wnhyang/coolGuard

基于规则引擎的风控决策系统，旨在为企业提供高效、灵活且可扩展的风险控制解决方案。

核心功能

以下是终极目标，部分已经实现，部分未实现，开源版本不会包含所有功能

• 实时指标计算，同步决策，异步决策，反馈

• 普通字段与动态字段：普通字段支持字符串、整数、小数、日期、布尔值、枚举，动态字段通过普通计算计算而来，高度可配置

• 数据接入：灵活配置数据接入的入参和出参

• 指标：基于时间计算的指标，目前已有：求和、次数统计、最大值、最小值、平均值、关联次数、历史取值，未来计划加入：移动距离、移动速度、趋势、方差、标准差、业务链、连续次数（不同与次数统计，中间插入其他状态则重新统计）、公式等

• 规则：条件支持：普通条件、指标条件、名单条件、正则条件、公式/脚本条件，动作支持：添加标签、添加名单、设置字段、发送消息，可设置正式和模拟状态

• 策略：模式分为：顺序模式、最坏模式、投票模式、权重模式

• 策略集：编排策略，是规则引擎核心作用的体现

• 指标、规则、策略、策略集版本管理

• 事件中心：事件数据分析、可视化、报表

• 豁免管理：配置式豁免决策，临时通行

• 数据服务：名单、标签、IP/证件号/经纬度/手机解析

• 三方集成：将三方以配置的方式接入系统

• 流量治理：熔断、限流、降级

• 监控中心：指标/规则/策略/执行、结果、效率监控等

• 系统管理：用户管理、角色管理、权限管理、日志管理、系统配置等

• 高级实验特性：A/BTest、冠军挑战、回测、仿真、模型、图谱分析