注意:本文参考 《对线面试官》系统需求多变,你如何设计?
我现在有个系统会根据请求的入参,做出不同动作。但是,这块不同的动作很有可能是会发生需求变动的,这块系统你会怎么样设计?
实际的例子:现在有多个第三方渠道,系统需要对各种渠道进行订单归因。但是归因的逻辑很有可能会发生变化,不同的渠道归因的逻辑也不太一样,此时系统里的逻辑相对比较复杂。
如果让你优化,你会怎么设计?
归根到底,就是处理的逻辑相对复杂,if else的判断太多了
虽然新的需求来了,都可以添加if else进行解决
但你想要的就是,系统的可扩展性和可维护性更强
想要我这边出一个方案,来解决类似的问题
在这之前,一般上网搜如何解决 if else ,大多数都说是 策略模式
但是举的例子又没感同身受,很多时候看完就过去了
实际上,在项目里边,用策略模式还是蛮多的,可能无意间就已经用上了(毕竟面向接口编程嘛)
而我认为,策略模式不是解决if else的关键
我的项目里的做法是:责任链模式
把每个流程单独抽取成一个Process(可以理解为一个模块或节点),然后请求都会塞进Context中
比如,之前维护过一个项目,也是类似于不同的渠道走不同的逻辑
我们这边的做法是:抽取相关的逻辑到Process中,为不同的渠道分配不同的责任链
比如渠道A的责任链是:WhiteListProcess->DataAssembleProcess->ChannelAProcess->SendProcess
而渠道B的责任链是:WhiteListProcess->DataAssembleProcess->ChannelBProcess->SendProcess
在责任链基础之上,又可以在代码里内嵌「脚本」
比如在SendProcess上,内置发送消息的脚本(脚本可以选择不同的运营商进行发送消息)。有了「脚本」以后,那就可以做到对逻辑的改动不需要重启就可以生效。
有人把这一套东西叫做「规则引擎」。比如,规则引擎中比较出名的实现框架「Drools」就可以做到类似的事
把易改动的逻辑写在「脚本」上(至少我们认为,脚本和我们的应用真实逻辑是分离)
(脚本我这里指的是规则集,它可以是Drools的dsl,也可以是Groovy,也可以是aviator等等)
在我之前的公司,使用的是Groovy脚本。大致的实现逻辑就是:有专门后台对脚本进行管理,然后会把脚本写到「分布式配置中心」(实时刷新),客户端监听「分布式配置中心」所存储的脚本是否有改动
如果存在改动,则通过Groovy类加载器重新编译并加载脚本,最后放到Spring容器对外使用
我目前所负责的系统就是这样处理 多变 以及需求变更频繁的业务(责任链+规则引擎)
不过据我了解,我们的玩法业务又在「责任链」多做了些事情
「责任链」不再从代码里编写,而是下沉到平台去做「服务编排」,就是由程序员去「服务编排后台」上配置信息(配置责任链的每一个节点)
在业务系统里使用「服务编排」的客户端,请求时只要传入「服务编排」的ID,就可以按「服务编排」的流程执行代码
这样做的好处就是:业务链是在后台配置的,不用在系统业务上维护链,灵活性更高(写好的责任链节点可以随意组合)