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

2021年11月24日 阅读数:13
这篇文章主要向大家介绍面试官:系统需求多变时如何设计?,主要内容包括基础应用、实用技巧、原理机制等方面,希望对大家有所帮助。

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

面试官我如今有个系统会根据请求的入参,作出不一样动做。可是,这块不一样的动做颇有多是会发生需求变更的,这块系统你会怎么样设计?面试

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

面试官若是让你优化,你会怎么设计?segmentfault

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

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

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

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

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

候选者:对吧?设计

面试官:嗯…

候选者:在这以前,通常上网搜如何解决 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,就能够按「服务编排」的流程执行代码

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

面试官:那我懂了

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

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

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

原创不易!!求三连!!