面试官：我想问个问题哈，项目里比较常见的问题
面试官：我现在有个系统会根据请求的入参，做出不同动作。但是，这块不同的动作很有可能是会发生需求变动的，这块系统你会怎么样设计？
面试官：实际的例子：现在有多个第三方渠道，系统需要对各种渠道进行订单归因。但是归因的逻辑很有可能会发生变化，不同的渠道归因的逻辑也不太一样，此时系统里的逻辑相对比较复杂。
面试官：如果让你优化，你会怎么设计？
候选者：我理解你的意思了
候选者：归根到底，就是处理的逻辑相对复杂，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，就可以按「服务编排」的流程执行代码
候选者：这样做的好处就是：业务链是在后台配置的，不用在系统业务上维护链，灵活性更高（写好的责任链节点可以随意组合）
面试官：那我懂了
第一时间获取BATJTMD一线互联网大厂最新的面试资料以及内推机会关注公众号「对线面试官」
