35、【对线面试官】系统需求多变时，如何设计
我现在有个系统会根据请求的入参，做出不同动作。但是，这块不同的动作很有可能是会发生需求变动的，这块系统你会怎么样设计？
实际的例子：现在有多个第三方渠道，系统需要对各种渠道进行订单归因
但是归因的逻辑很有可能会发生变化，不同的渠道归因的逻辑也不太一样，此时系统里的逻辑相对比较复杂
如果让你优化一下，你会怎么设计？
问题转化
- 归根到底，就是处理的逻辑相对复杂，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等等）
在我之前的公司，使用的是Groovyl脚本
具体怎么做的
大致的实现逻辑就是：有专门后台对脚本进行管理，然后会把脚本写到「分布式配置中心」（实时刷新），客户端监听「分布式配置中心」所存储的脚本是否有改动
如果存在改动，则通过Groovy类加载器重新编译并加载脚本，最后放到Spring容器对外使用
我目前所负责的系统就是这样处理多变以及需求变更频繁的业务（责任链+规则引擎）
不过据我了解，我们的玩法业务在实现上在「责任链」多做了些事情（所谓的可配置化）
「责任链」不再从代码里编写，而是下沉到平台去做「服务编排」，就是由程序员去「服务编排后台」上配置信息（配置责任链的每一个节点）
在业务系统里使用「服务编排」的客户端，请求时只要传入「服务编排」的ID，就可以按「服务编排」的流程执行代码
这样做的好处就是：业务链是在后台配置的，不用在系统业务上维护链，灵活性更高（写好的责任链节点可以随意组合）
总结
遇到这道题之后，其实我当时答得不太行（当时只是简单说了下责任链和脚本）
于是面试题发给前同事A，让他给我出出意见，同事A给我回答的内容是：「抽象，模块化，配置化」
光看这几个词，他说得也没错，但我理解不了。让他具体点，他也不展开了
于是，我又厚着脸皮去找别的前同事B，得出的回答是：
- 「是否可以做成配置化、动态替换、插件式、不需要人去开发」
- 「规则引擎」
当我问他，什么是「规则引擎」时，反手就被教育了，问我到底这两年学了什么，这都不懂，这也太菜了。
有了"方向"以后，我花了点时间去搜了下「规则引擎」的资料，顺便入门了下「Drools」，发现这玩意不就类似于我之前在公司用的Groovy脚本平台
（当时还在纳闷想为啥那后台的名字叫做规则平台）…
于是又去简单翻了下我们的Groovy脚本平台是怎么实现这套东西的
「服务编排」这块之前在公司里因为项目的缘故，自己也没接入过，但一直听有其他的团队在用，顺便也简单看了下代码（：
后来再去找同事B时，他说现在自己公司用的是「流程引擎」，画图就ok了
其实，搞了半天，还是写if else 舒服!