宣布!哈迪斯(hades)项目开始连载!

上周透露了我会写一个新项目，现在我决定好了项目名，是时候来宣布一下啦。

给自己里个KPI吧，在Q2写完这个项目，到时候希望能拿3.75

这个新项目名为：hades(哈迪斯)，它如果成型了以后，一般会被叫做「规则引擎」

Gitee链接：https://gitee.com/zhongfucheng/hades

GitHub链接：https://github.com/ZhongFuCheng3y/hades

去年给大家聊austin的时候，吹了一个功能，但迟迟没有实现，不知道大家还有没印象。

商务又找到了便宜的短信渠道了，接入一下看看效果吧？这可是实打实省钱的啊！每次写一个类（接入短信就相当于写一个类），我都要重启发布上线吗？这不靠谱吧？

解决方案：上规则引擎将业务代码抽离，无须上下线即可实现功能。

结果，一年多过去了，我这个功能还没实现…文章一直放在历史列表里，以至于时不时就有人跑来问我这个实现了没，我都以这不是核心流程给推脱了。

我是想实现这个功能的，我以各种的关键词，都没在Git找到合适的轮子去接入，找了好久咯，结果就是一直搁置了。一般在网上搜规则引擎，很可能你会搜到Drools(学习成本有点大)，或者会搜到流程编排引擎(但是会带有一丢丢规则的味道)。

而我的目标是很明确的：借助groovy做的规则引擎是最合适的，这对Java开发相当于0学习成本。

有的人可能会好奇：你又说网上没什么现成的轮子，那你为啥会知道这玩意啊？

因为我在前司用过这种轮子，确实是很好用，很适合用规则引擎写一些改动比较多的的逻辑，之前做过的流量系统和消息推送平台都有过实际应用场景。

初用时，会觉得很惊艳！刚毕业时还特意看下公司里的规则引擎究竟是怎么实现的，为什么能做到不发布应用，新的逻辑就能实时生效。后来看xxl-job的时候，发现xxl-job的Java GULE其实上也是依赖Groovy去做的。

曾经我还把这个规则引擎的原理结合我的面试，在《对线面试官系列》中分享过。

有专门后台对脚本进行管理，然后会把脚本写到「分布式配置中心」（实时刷新），客户端监听「分布式配置中心」所存储的脚本是否有改动

如果存在改动，则通过Groovy类加载器重新编译并加载脚本，最后放到Spring容器对外使用

这次我暂定是会把数据库给砍掉，只依赖分布式配置中心，会用nacos和apollo这两种实现分别打成二方库。砍了数据库和后台管理会少了很多自定义个性化的逻辑，不过项目就会很轻量级。

我在写austin的时候，老是有人说我的项目太重了，他们只是想要一个简单的发送各种消息的jar包，我给他们的却是一个需要部署的应用。

而这一次，hades最后能给到大家用的，就是一个jar包。当你项目用的是apollo作为分布式配置中心时，那就引入apollo-starter，当你项目用的是nacos作为分布式配置中心时，那就引入nacos-starter。

通过在配置中心的后台改改点点，就能实现不重启项目代码，修改了线上的逻辑！

我预估这项目的代码量不会太大，实现的过程应该也挺快的，目前已经简单地调通了流程(nacos/example)。后面等我慢慢迭代和更新吧，有进展再跟大家汇报下。

Gitee链接：https://gitee.com/zhongfucheng/hades

GitHub链接：https://github.com/ZhongFuCheng3y/hades