当你长大了，故乡只有冬，再无春夏秋！
小学，每天都回家；初中、高中，一周一次；大学，半年1-2次；工作了，一年一次，而且每次都是在春节的冬季，相信有在北方小县城下生活过的朋友都有体会过北方萧瑟肃杀的冬季，所以这次趁着国庆，这个夏去秋来的时节去看看这段时间家里会不会有些不一样。但是，不出意外，一样的破败，可能是大城市到小县城到农村的再到农村的反差，又或是我真的变了，“清高了”！
接下来从几个角度讲一下吧！个人所见所闻的纯主观感受。
不得不说，这几年是有些变化的。
去年整个县都在改造，很多马路开膛破肚，修缮水管，如今用的是南水北调的水。
个人博客：无奈何杨（wnhyang）
个人语雀：wnhyang
共享语雀：在线知识共享
Github：wnhyang - Overview
在Sa-Token最新的v1.39.0版本的更新日志中有这么一句话
核心：
正巧最近有看一个关于鉴权的东西，顺便看一下吧！
目标：对于后端开放的api进行鉴权。
个人博客：无奈何杨（wnhyang）
个人语雀：wnhyang
共享语雀：在线知识共享
Github：wnhyang - Overview
默认你已经看过之前那篇风控系统指标计算/特征提取分析与实现01，Redis、Zset、模版方法。
其中已经介绍了如何利用redis的zset结构完成指标计算，为了方便这篇文章的介绍，还是在正式开始本篇之前回顾一下。
zset是redis中的一种数据结构，表示有序集合，正因此我们可以利用其做时间窗口来计算指标，value为事件标识，score为事件时间戳。
如下图表示次数、关联、求和类型各两条指标在时间窗口下随着时间分布，其中的黑点也就是事件，散列且线性的分布在时间窗口中。
个人博客：无奈何杨（wnhyang）
个人语雀：wnhyang
共享语雀：在线知识共享
Github：wnhyang - Overview
一天，小明在风控管理台查看事件数据时，发现一笔决策结果为“拒绝”❌的交易事件，小明点开事件详情发现其触发了一条“24小时内向不同陌生账户转账超过30w”的规则，规则设置的处置方式是“拒绝”❌。小明通过策略规则却查不到那条“24小时内向不同陌生账户转账超过30w”的规则，经确认原来是这条规则在此交易触发后一段时间内被修改了，已经不知道当时是如何配置的！？
这该怎么办？
我们要知道风控等其他系统都需要对于配置实时生效，所以使用了规则引擎，规则引擎具有实时生效优雅热刷新的特性，但也因此，如果规则设置有问题而没有回滚/溯源/复现的机制，将是很大的问题！！！
所以本质上就是要在规则引擎应用之上打造完善的版本控制，能够对规则历史进行溯源。
之前的文章风控系统建设，指标策略规则流程设计，LiteFlow隐式子流程，构造EL和Chain，提到了最终存储在es中大概有哪些数据。以下仅供参考，有部分还没做。
这里再次梳理一下：
1、基础数据，保留所有事件字段。
2、事件处理流程，也就是输入的数据经历了哪些流程和组件处理！
3、策略集结果，包括策略集、策略、规则的所有决策结果。还要加上特殊配置的策略执行流程。
4、指标数据，本次事件计算的所有指标数据。
个人博客：无奈何杨（wnhyang）
个人语雀：wnhyang
共享语雀：在线知识共享
Github：wnhyang - Overview
既然是商业软件，涉及到商业，那目的就是赚钱。
就拿IDEA举例，IDEA有多个版本，社区版功能少一些，本身使用上没有什么限制，而且省去了版权纠纷等问题；但是如果想要享受JetBrains的其他服务，那就必须要考虑商业化版本了，缺点可能就是贵一点。
像IDEA、Navicat
Premium这样的都是提供了客户端的软件服务，好像更加贴合我们对于软件的认识，然而我们日常生活中如iCloud、Windows、aliyun、google，包括视频会员、VIP本质上都一样，而且这些都可以与其用户体系打通，形成会员积分系统。
可以步入正题了，本篇文章讨论的不是用户会员体系，而是简单的许可证License。
许可证存在就是为了限制软件功能，不同的套餐对应不同的功能嘛！
如下，语雀套餐。
个人博客：无奈何杨（wnhyang）
个人语雀：wnhyang
共享语雀：在线知识共享
Github：wnhyang - Overview
https://juejin.cn/post/7005869798483558431
https://gitee.com/freshday/radar/wikis/home
在需要灵活配置规则的业务系统中，如上图这样的条件配置非常常见。
不管是在第一个参考链接（https://juejin.cn/post/7005869798483558431）里或是从自己的分析中都可以知道条件配置就是对同一逻辑单元的与或非编排。对于LiteFlow相同组件的编排有组件标签和组件参数两种解决方法。
通过组件标签实现，就是在编排LiteFlow时加上组件tag。
那么就将条件存储在数据库中，在组件运行时通过tag再到数据库中去取。
个人博客：无奈何杨（wnhyang）
个人语雀：wnhyang
共享语雀：在线知识共享
Github：wnhyang - Overview
前面有很多文章已经说了，我要利用LiteFlow做风控系统。至于进度嘛，只能尽力而为，毕竟我的惰性也很强。
下面是目前Git的提交记录，代码托管在Github和Gitee，但是是私有仓库，因为还不是开放的时候，还有很多要做的。
其中能梳理的仅是主流程的TODO都有下面这么多，更何况还有管理应用，es存储和检索设计开发还都没开始，更有前端规则/策略配置也还没做，还有在涉及画布的排版、数据的反显都还没有明确的解决方案。所以连个半成品都不算，不是开放的时候。
另外，也不知道我会不会中途放弃😝
个人博客：无奈何杨（wnhyang）
个人语雀：wnhyang
共享语雀：在线知识共享
Github：wnhyang - Overview
突然接收到XX给的任务，要将一批IP数据处理一下，将IP对应的省市区解析出来，很急！
已知我这边有一个IP解析接口，提供了IP解析到国家省市区ISP等的能力，而且支持批量查询，但问题是仅仅有接口的形式，没有管理应用将接口利用起来，要使用的恐怕也只能是发接口，而且XX提供的数据有极大可能是Excel格式。另外XX没有说明解析后的数据怎么给出来，如果是Excel最好就是将数据放在一行标记为省市区就好。这么看来只能是临时开发来完成了，经过分析此时已经有了大致的思路了。
果然！拿到的数据是xls格式，大致如下。共有几百条。
| a | b | c | ip | |
|---|---|---|---|---|
| 123 | 234 | 345 | 127.0.0.1 |
那就动手开发吧！从接受到任务到结束大概用了40分钟，这不是炫耀什么，毕竟使用AI可能会更快更好，但这毕竟是临时做的，完成的也还可以，我还挺欣慰的。
任何临时紧急的任务，第一目标都应该在时间要求内是完成它，所以总体思路就是先完成后优化。
其实做起来也很简单
1、整理原始数据，也可以叫做数据清理。
2、读IP数据
3、整合请求，发接口进行IP解析
4、解析数据补充在原数据上
5、输出
这里提供了示例数据，IP数据来源于在线ip地址随机生成器 - JSON中文网，其他数据都是随机生成，一共270条。
个人博客：无奈何杨（wnhyang）
个人语雀：wnhyang
共享语雀：在线知识共享
Github：wnhyang - Overview
交易事件就是交易，如：登录、注册、转账等，而且这些还只是大类，通常转账有手机号转账、银行卡号转账等，币种又有人民币、外币、数字人民币等，这只是从方式、币种区分，其实还有很多，而且流程是相对复杂的。
以下仅是随意的例子，不可深究。
要在转账中加入风控一定也是了解转账的整体流程的。
从风控业务的角度出发，接入风控的交易数据就可以称为交易事件🤝
虽然说是这么说，风控的接入要熟悉整个交易流程，但是为了简化，其实是可以把所有交易分为事前事中事后的。
个人博客：无奈何杨（wnhyang）
个人语雀：wnhyang
共享语雀：在线知识共享
Github：wnhyang - Overview
【相见欢】Spring MVC 源码剖析（五） —— 消息转换器 HttpMessageConverter | 芋道源码 —— 纯源码解析博客
Spring boot 中时间类型的序列化与反序列化 - 掘金
这是web开发中常见的一个错误，无法完成LocalDataTime的反序列化。
这是怎么回事？
其实这个问题在于LocalTime、LocalDate、LocalDateTime的序列化上。
这就要从SpringMVC说起了！
Spring MVC 是 Spring Framework
的核心组件之一，与其他模块（如
Spring Boot、Spring Data、Spring Security
等）一起构成了完整的 Spring 生态系统。
Spring MVC是Web开发中极其重要，其设计思想是非常值得学习的。
关于SpringMVC的学习可以参考以下文章
Category: Spring-MVC | 芋道源码 —— 纯源码解析博客
请求报文在传输中是要进行序列化和反序列化的，有大致经历了如下流程。
其中这个HttpMessageConver是这个过程中的关键，这个接口继承树如下图。
