写点什么

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

作者:Geek_1df311
  • 2021 年 11 月 23 日
  • 本文字数:1363 字

    阅读完需:约 4 分钟

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

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

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

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

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

候选者:归根到底,就是处理的逻辑相对复杂,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,就可以按「服务编排」的流程执行代码

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



面试官:那我懂了


来源:https://www.cnblogs.com/Java3y/p/15591523.html

用户头像

Geek_1df311

关注

还未添加个人签名 2021.11.21 加入

还未添加个人简介

评论

发布
暂无评论
面试官:系统需求多变时如何设计?