流程/规则引擎框架-Baikal介绍
1.产生背景
想到“通过什么->得到什么”类问题，第一个想到的恐怕就是活动类项目的开发，用户通过一系列行为，得到一系列的东西。但往往这类活动变动性较大，持续性较短，因为活动玩法的不断扩充与产品运营的脑洞不断扩大，刚开始写的一系列通用的规则往往付之一炬，久而久之，就只剩下一些相对独立的抽象出来的基本模块，然后再通过摞代码方式将模块组装起来。
由于一个新活动往往与老玩法有关又无关的特性，新的活动也必须在开发，测试等环节上耗费较大精力，所出问题也比较多，以至于慢慢的，大家基本都认为，做活动类项目，直接摞代码就行，考虑复用性只会增加开发成本，且下个活动能够全部复用上的概率不大。为了找到一个简单，易用的通用营销引擎，曾调研过一系列的规则引擎等(如Activiti，Drools，Flowable)，但大多上手较难(Baikal可能也不简单)。
本人也是深受活动类项目迫害，以至于觉得做活动完全就是一个磨性子的工作。
有迫害就有反抗，于是，Baikal历经三年多在几经周折与不断变更的情况下诞生了，Baikal项目核心框架目前已经基本开发完毕，也在实际场景中发挥了举足轻重的作用。
Baikal只是提供了一种此类问题的解决方案，并不敢说最优，只能说你可能会有所借鉴。
2.Baikal简介
eg:某商场想举办一个女神节活动，规定
1.活动期间女生用户/拥有商场会员卡的用户可参加活动
2.女性并且拥有商场会员卡的用户，可享受满100元返现50元/满50元返现20元的活动
3.能够参加活动的用户每人赠送1支鲜花
4.商场常年活动:不论是否能参加活动，消费满10000元赠送1个珍藏版商场吉祥物
现在你有:
1个只会通过身份证校验是否是女性用户的员工A
1个只会校验是否有商场会员卡的员工B(但是要报手机号等操作，校验工作比较慢)
3个只会校验消费金额的员工(一个校验100元C 一个校验50元D 一个校验10000元E)
1个只会送钱的员工F(需要被告知送多少 传递告知-上下文)
1个只会送花的员工G(需要被告知送多少 提前告知-配置)
1个只会送吉祥物的员工H(需要被告知送多少 提前告知-配置)
和若干能够了解活动规则，但除了指导用户怎么走，什么都不会的匿名员工
如果是你，要怎么安排？
其实上述所述的员工，就是对一个活动的拆解，做到单一目的的员工，如果下次出现了新活动，需要送吉祥物，直接复用那个会送吉祥物的员工即可，功能足够单一，但是要怎么拼接起来，保证活动的顺利进行呢？
先解释一下上图：
1.所有的校验员工，校验符合则返回TRUE，不符合返回FALSE
2.所有的叶子节点都是会点东西的员工，这里叫叶子节点
3.所有的拥有子节点的员工，这里叫关系节点
关系节点的解释：
1、And 所有子节点中，有一个返回FALSE 该节点也将是FALSE，全部是TRUE才是TRUE，在执行到FALSE的地方终止执行，类似于Java的&&
2、Any 所有子节点中，有一个返回TRUE 该节点也将是TRUE，全部FALSE则FALSE，在执行到true的地方终止执行，类似于Java的||，Any用于result，Or用于flow
3、All 所有子节点都会执行，有任意一个返回TRUE该节点也是TRUE，没有TRUE有一个节点是FALSE则FALSE，没有TRUE也没有FALSE则返回NONE，所有子节点执行完毕终止
4、None 所有子节点都会执行，无论子节点返回什么，自己都返回NONE，任何没有子节点的关系节点将自动返回NONE
5、True 所有子节点都会执行，无论子节点返回什么，自己都返回TRUE，任何没有子节点的关系节点将自动返回NONE
写到这里才发现写的有点复杂，例子不是很好，尴尬，哈哈哈…
图中实际上还有些操作可以简化一些，比如8号节点发放的吉祥物奖励，其实可以把7号节点做成一个前置节点，也就是7号必须通过才会执行8号，这样就不再需要3号节点的存在，简化树结构方便阅读和理解。
变化后：
黄色框中的代表前置节点，只有前置节点通过(非FALSE)才可以执行
3.Baikal能带来什么
1.业务拆解颗粒度可控
如果你现在有一个会校验10000元并且会发吉祥物的员工，那么3-7-8节点可以完全替换成这一个员工，但是显而易见的，这样的员工，下次复用的概率，也不会高，如果下次真的要复用，直接把已经形成大颗粒度的3-7-8号节点拿出去，就可以满足。
2.可扩展性/更改更容易
如果此时，突然被告知，女神节活动只有女生能参加，不再需要和商场会员卡挂钩的那一块内容，那直接和11号节点脱钩即可。
如果此时突然宣布，能够参加的女生必须是国内用户，只需要在4号节点前增加一个判断是否是国内用户的节点即可，其他节点照旧，不受任何影响。
3.配置化更新
可以通过数据库等，实现配置化更新
4.异常出现与恢复
如果此时7号节点突然异常，E员工突发身体不适，那么可以把整棵树和影响用户的信息存储起来，等到E恢复/更换员工后，在将异常数据从7号节点继续执行后续。若此时商场临时决定，给受影响用户补发优惠券作为补偿，也为特别处理提供了可能
备注
Baikal项目的设计思路已经介绍完毕，目前Baikal项目已经用于正式的生产并扛过了活动类项目严酷的考验，也在不断探讨着其他应用场景，后续会持续优化，更新相关设计及实现细节。
有更好方案/简易的小伙伴欢迎交流~~