前面的Baikal介绍中提到用节点将业务拆解,并使用关系节点将业务连接起来并控制业务流转。
结构解释:
1.BaseNode 所有节点的基类,存放着节点的共性
2.BaseRelation 所有关系节点的基类,children是关系节点下的所有子节点,具体的有介绍中所说的AndRelation,AnyRelation,AllRelation ,NoneRelation ,TrueRelation
3.BaseLeafFlow 叶子节点,所有过滤性条件的基类,供具体业务继承并实现其doFlow方法,返回true和false代表是否满足/是否通过
4.BaseLeafResult 叶子节点,所有结果性质的类的基类,供具体业务继承并实现其doResult方法,返回true和false代表结果是否被发放,如发放奖励等
5.BaseLeafNone 叶子节点,所有仅数据组装/数据加载等不干预流程的类的基类,供具体业务继承并实现其doNone方法,无返回值,数据的组装和加载后放入上下文中,供后续流程使用
上图为一个以往版本的解释,现已大部分优化,但原理一致
1.业务通过BaikalPack数据包进入Baikal执行,需指定要执行的baikalId/scene(场景)
2.BaikalPack组装成BaikalContext在Baikal中流转
3.依托观察者模式,将数据库/其他地方配置的完整的baikal树形结构,经过组装形成对应执行的handler,在特定scene/baikalId下触发并执行handle方法
1.各自app在项目启动时通过Mq拉取最新配置,并组装到本地缓存
2.当server发现某app下有更新,便推送更新到具体业务并更新Baikal缓存
3.server端实现可视化配置,操作树与更新树形结构配置等
1.监控与报警与落盘
当某个叶子节点报错后,可根据配置选择是否落盘异常,并记录当时baikal快照与执行到的节点信息,当错误修复/恢复后,可选择重新执行/从错误节点恢复
2.同scene多handler处理优先级
当同scene多handler情况发生时根据各个handler的优先级指定执行顺序,确保高优先级请求优先处理
3.节点根据复杂度调整与并发执行
调整:如A过滤比B过滤耗时多,且是A&&B的情况,则应调整为B&&A
并发:如A&&B&&C 是不是ABC并发执行,当有一个返回false时结束执行并返回false会不会对一些特殊场景有性能提升?
4.持续性优化,等等等等,还有很多业务场景待发掘
有更好方案/简易的小伙伴欢迎交流~~