面试官:系统需求多变时如何设计?

面试官:我想问个问题哈,项目里比较常见的问题

面试官我现在有个系统会根据请求的入参,做出不同动作。但是,这块不同的动作很有可能是会发生需求变动的,这块系统你会怎么样设计?

面试官实际的例子:现在有多个第三方渠道,系统需要对各种渠道进行订单归因。但是归因的逻辑很有可能会发生变化,不同的渠道归因的逻辑也不太一样,此时系统里的逻辑相对比较复杂。

面试官如果让你优化,你会怎么设计?

候选者:我理解你的意思了

候选者:归根到底,就是处理的逻辑相对复杂,if else的判断太多了

候选者:虽然新的需求来了,都可以添加if else进行解决

候选者:但你想要的就是,系统的可扩展性和可维护性更强

候选者:想要我这边出一个方案,来解决类似的问题

候选者:对吧?

面试官:嗯…

候选者:在这之前,一般上网搜如何解决 if else ,大多数都说是 策略模式

候选者:但是举的例子又没感同身受,很多时候看完就过去了

候选者:实际上,在项目里边,用策略模式还是蛮多的,可能无意间就已经用上了(毕竟面向接口编程嘛)

候选者:而我认为,策略模式不是解决if else的关键

面试官:系统需求多变时如何设计?_第1张图片

候选者:这个问题,我的项目里的做法是:责任链模式

候选者:把每个流程单独抽取成一个Process(可以理解为一个模块或节点),然后请求都会塞进Context中

候选者:比如,之前维护过一个项目,也是类似于不同的渠道走不同的逻辑

候选者:我们这边的做法是:抽取相关的逻辑到Process中,为不同的渠道分配不同的责任链

候选者:比如渠道A的责任链是:WhiteListProcess->DataAssembleProcess->ChannelAProcess->SendProcess

候选者:而渠道B的责任链是:WhiteListProcess->DataAssembleProcess->ChannelBProcess->SendProcess

面试官:系统需求多变时如何设计?_第2张图片

候选者:在责任链基础之上,又可以在代码里内嵌「脚本」

候选者:比如在SendProcess上,内置发送消息的脚本(脚本可以选择不同的运营商进行发送消息)。有了「脚本」以后,那就可以做到对逻辑的改动不需要重启就可以生效。

候选者:有人把这一套东西叫做「规则引擎」。比如,规则引擎中比较出名的实现框架「Drools」就可以做到类似的事

候选者:把易改动的逻辑写在「脚本」上(至少我们认为,脚本和我们的应用真实逻辑是分离)

候选者:(脚本我这里指的是规则集,它可以是Drools的dsl,也可以是Groovy,也可以是aviator等等)

面试官:嗯…

候选者:在我之前的公司,使用的是Groovy脚本。大致的实现逻辑就是:有专门后台对脚本进行管理,然后会把脚本写到「分布式配置中心」(实时刷新),客户端监听「分布式配置中心」所存储的脚本是否有改动

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

面试官:系统需求多变时如何设计?_第3张图片

候选者:我目前所负责的系统就是这样处理 多变 以及需求变更频繁的业务(责任链+规则引擎)

候选者:不过据我了解,我们的玩法业务又在「责任链」多做了些事情

候选者:「责任链」不再从代码里编写,而是下沉到平台去做「服务编排」,就是由程序员去「服务编排后台」上配置信息(配置责任链的每一个节点)

候选者:在业务系统里使用「服务编排」的客户端,请求时只要传入「服务编排」的ID,就可以按「服务编排」的流程执行代码

候选者:这样做的好处就是:业务链是在后台配置的,不用在系统业务上维护链,灵活性更高(写好的责任链节点可以随意组合)

面试官:系统需求多变时如何设计?_第4张图片

面试官:那我懂了

面试官:系统需求多变时如何设计?_第5张图片

欢迎关注我的微信公众号【Java3y】来聊聊Java面试,对线面试官系列持续更新中!

【对线面试官-移动端】系列 一周两篇持续更新中!

【对线面试官-电脑端】系列 一周两篇持续更新中!

原创不易!!求三连!!

你可能感兴趣的