京东app后台多端融合架构代码重构实战

逃离我推掉我的手 2022-09-04 14:56 81阅读 0赞

# 一 简介 #

重构是一个非常常见且古老的课题，涉及重构的文章、书更是不可胜数。

但其实做程序做久了就会知道，想把一个复杂的系统做好，尤其是参与人数较多的中大型项目，靠看几本设计模式的书，去试图寻找设计模式的奥秘，其实是不够的。很多时候，看书时觉得很有道理，例子也能理解，但到实际开发时，却无从下手，不知道怎么灵活套用。

很多项目，在持续的版本迭代中，还伴随着人员的更替过程，往往为了解决眼前的需求，最常见的就是直接复制类似的逻辑，或者就是在末尾追加逻辑。同时，受限于对老版本的需求理解，很容易出现新需求覆盖老需求的参数值，无意识的更改老版本结果等。那么倘若系统的隔离性做的不好，则极易产生A功能的改动，影响BCD等一大堆功能的正确性。

以京东App的后台为例，就是一个典型的复杂系统，涉及开发人员众多，模块巨多，迭代时间很长，很多业务逻辑已无从考证，开发人员也已经换了好几轮，那么对于这样的系统，如何让开发人员做的需求、功能隔离开，互不影响，各小模块又能各自健壮、系统又具备相当的扩展性、配置化率又高（仅通过配置即可完成功能的变更），就成了一个不得不深入考虑的问题。

本篇主要是我在实际工作中，对一个复杂系统做了一些改造，并从中总结的一些经验，做的分享。

# 二 案例 #

近期京东App后台核心模块发生了较大的逻辑改动，主要原因是新增了一些接入来源，从之前的独苗京东App，到后来的京东PC站、京东极速版、老年版、小程序等等，都接入了原App后台。通过完成统一接入，避免了多个后台共存，重复开发的问题。

![04ffd60306f142e1e03093a4643e48d0.png][]

而这些不同的来源，逻辑就有较多不同。

有的来源需要执行逻辑ABC，有的来源需要执行BCD，有的只需要执行BC，并且不同的来源返回值也有所不同，这就对之前的单一来源的系统架构产生了较大的冲击，如果处理不当，则不可避免地出现大量的if-else逻辑，以及扩展上的混乱。

那么针对这种情况，以及对提高系统整体配置化率的诉求，我们对后台架构做了一次重构。本文就是对重构内容做的一个浓缩后的抽象讲解，线上实战性质，非单纯设计模式类的demo。

如下图，我尽可能简化了细节，和小模块内的逻辑，仅保留了最外层的大模块。

我们来看背景，之前只有主App客户端来源的请求，譬如refer=1，该请求到达后，需要触发"运费"、"优惠券"等数十个上游rpc调用，之后聚合各上游系统结果，返回给客户端对应结果。

现在新增的接入方，譬如"老年版"，refer=5，就删减了组件层一些复杂的促销逻辑、凑单、白条之类，结果层也有相应删改。我们该如何支撑这种可能随时增删改模块和来源的业务架构呢？

![a5d5c58d764e2916d11c7467c877dad1.png][]

# 三 原始问题点——复杂的排列组合 #

当多个层级均出现了多个变量时，这个系统的逻辑就变成了一个复杂的排列组合问题。

![962861f1a249908b7c1dcaea2263ece4.png][]

我们假如用户的入参是User对象，里面有一个字段refer表明了来源。

![fc44b884fb0c5223d914c50059c3ddfe.png][]

在重构前，代码进入主流程后，如下图，就是简单地根据refer来决定是否走哪些模块、返回哪些参数。

图中仅作为示例，实际情况，每个 fetch模块都有数千数万行代码，逻辑之复杂，各种if、else运用之嵌套，各种与或非使用之犀利，实属鲁班再世，也要夸赞几句鬼斧神工的。

![f0110938d90950620d3ad87179c6e35a.png][]

大家都能看出来的问题，就是业务模块与入参变量的强耦合，如果入参refer=1，则执行业务模块A、B、C，不执行E、F、G，且返回值包含X、Y、Z，不包含U、V、W。

这样的设计不可避免带来了极大的维护的麻烦与混乱，到处都在判断是否是它，是他还是她？

那么该如何隔离层级，解耦模块与来源、来源与返回值之间的关联呢。

# 四 简化判断，让职责单一 #

上面提到了最大的问题，我们用通俗的话来讲就是：如果是A，我就做A1、A2、A3；如果是B，我就做A2，A3，A4。

那么问题就是这个主逻辑器做了太多的事情，日后被修改的概率极大，每个逻辑变动，都会导致主逻辑器的改动。

我们主要优化的点就是将这个逻辑给去掉，让主逻辑器职责单一，每个业务单元也职责单一。将上面的逻辑变成如果是A1，则来源是A时我工作，是B时我不工作，如果是A2，则来源A、B我都工作，如果是A4，则来源A我不工作，来源B我工作。

![887e7592dfda74c0b3592caa92551035.png][]

可以看到，做的事情就是当有一堆条件判断，要决定执行N个逻辑中的M个时，调用者不应该关心调用逻辑，而应由这N个逻辑自行判断自己要不要执行。

从代码实现来看，就是调用者不关心有多少个逻辑块，也不必关心日后的增减，从而实现调用的解耦。那么代码该如何写呢？

原来的是在一个方法里，fetchStock，fetchDiscount等等，首先我们要把这些实现全部去除，并统一为对接口的遍历。

改造后的代码是这样

![75dbdcdfc185ebf8c4dcd9ff5a460fe9.png][]

代码很简单，注入一个接口的集合，并遍历这个集合，根据实现类返回的true、false决定是否要执行这个实现类的业务逻辑。

接口定义如下

![d9c69db69c48a566c0146aad3f59d20a.png][]

单个逻辑单元代码如下

![e0367583a7687acb3e74807548e722fa.png][]

以上主流程的逻辑很清晰，后续随着各模块的扩展或缩减，都不需要动主逻辑，而只需要各个子模块根据自己的情况返回是否要执行自己即可。

# 五 动态配置，避免硬编码 #

通过以上的改造，我们已经完成了模块间的隔离，当有新增、删减模块时，可以做到不影响主流程，且将代码修改、影响范围控制在一个类里。

但是需求的变化总是很频繁，仅仅做到互不影响还不满足需求，我们还需要做到能够动态的控制各个模块的启用和关闭。

譬如『如果是A，我就做A1、A2、A3；如果是B，我就做A2，A3，A4』。希望能做到随时仅通过修改配置，不改代码不重新发布而做到『如果是A，我就做A1、A2；如果是B，我就做A3，A4』，完成对模块的启停。

动态配置该如何实现呢？

其实很简单，我们只需要修改execute方法，将refer==1这种规则存放于配置中心，将execute方法里的硬编码判断变成根据配置中心的配置进行判断即可。如下图：

![105706c7928af0dacc6960b306bdead7.png][]

那么ConfigCenter就是配置中心工具类，里面提供了根据key获取value的方法。配置中心大抵如注释所描述的，在应用启动时，全量从zk、etcd等拉取配置并保存在本地内存，并开启监听，当配置中心内容有变化时，更新到本地内存里。

![38d0739dc923e60f513f328d66941280.png][]

通过观察各个模块的execute类，可以进一步发现，倘若配置中心里我们将类名作为key，模块所支持的refer集合为value时，各模块的execute方法就是完全一样的代码。那么整个方法又可以进一步抽成一个抽象类，由该抽象类来完成这个判断逻辑，如图：

![bc23b636706723f6be64c1a2aef150a4.png][]

当有了统一完成"开关"的父类后，则各个模块的逻辑单元就更加简单了，只需要关注自己的业务逻辑即可。

![d48c53acf1e442cca383e0bb3b8172ae.png][]

至此，最小业务单元职责则回归到纯粹的业务逻辑，不再参与流程控制的逻辑判断。同理，主流程也不再参与对各个子业务单元的判断和控制，只关注于对接口的遍历，各模块也不再产生相互影响。

# 六 结果层字段隔离控制 #

以上我们完成了业务逻辑单元的隔离，那么对于结果层该如果控制呢？

![fffa660623c2fad36a1cfb9607bc6042.png][]

原始代码是这样的，在主流程中对各个变量进行判断，然后设置结果的值。从原始代码可以看到，即便只有一个变量refer就已经让代码可维护性变的很差，更别提真实场景下变量可能有多个时，要维护不同变量场景下返回不同的参数该多少困难。

通过对上面业务层控制的实现，我们同样可以采用类似的方式来处理结果层。

定义一个接口如下，定义boolean型方法，让各字段决定自己要不要返回。定义key、value，用来存放字段名和value。

![53376b5db046a8f49186abd30794a38d.png][]

修改主流程如下，当需要返回时，才能待返回字段的key、value存起来。

![396a38562901b3e0f18b02d64186647c.png][]

实现类如下：

![5d6b2bfe223359afc2a06a469b6ce2ab.png][]

以上方式展示了对结果层进行精细化控制的简单方案，实际场景中，可能涉及结果层数据结构并不是单层、对key、value的判断需要额外的属性等，其实思路都是一样的。

如果要增加入参的判断，在接口的needOut里追加要参加逻辑判断的入参即可。如果返回的结构不是单层的key-value，则在复合结构的实现类里再嵌套一层新定义的接口的遍历也可。

# 七 长逻辑相关处理 #

长逻辑这种最常见，也是最好处理的。我们经常在写一处逻辑时，刚开始很简单，几行就解决了，后来随着业务越来越膨胀，这个方法也是越来越长。终于有一天，代码长到显示器装不下它了，后面的逻辑开始出现对前面的逻辑产生影响了，这个方法就开始变的有"坏味道"。

这种相信大家都不少见，尤其在老系统中，从1千到8千行的我都见过，编辑器右边的滚动条都要看不到了。当然仅仅是长倒还好说，主要的问题是相互影响，前面赋的值，后面就被覆盖了，这种问题往往还比较隐蔽，极其影响系统的健康。

![d16b0adad63a7107e21e946c01df0856.png][]

解决这种长逻辑，其实很简单，做好两件事即可，1-将方法的顺序执行变成接口遍历，2-封装。

1 如何将方法的顺序执行变成遍历呢？

![1a93dc2f814a9fa47d6bc77779a2aba3.png][]

这个其实在上面已经讲了，是类似的做法。将一大堆在同一个大方法里的小方法全部变成某个接口的实现类，从而将方法的顺序执行，变成对接口集合的遍历执行。后续增加或删减方法时，只操作对应的类即可，而不需要对这个大流程做修改。

一个单独的实现类就是这样的：

![5906b8931d4e5259c540a465be14b743.png][]

可能有人会问，我的各个方法是有先后顺序的，你用了接口集合，该怎么控制顺序呢，从上图的Order注解可以看到，这个就是控制在接口实现类的顺序的，值越小，在List里越靠前。

2 如何理解封装呢？

这个更简单，之前不是说代码长了易出现值被后面的逻辑覆盖，那么就以某个最小参数为一个类，所有对他的增删改都控制在一个类，完成对某参数、对象的封装控制。而不要散落各地去修改一个参数的值。

# 八 带中断的长逻辑处理 #

最后一个问题，如果带有流程中断的情况。如图，一个长逻辑，在某些条件被中断了，中断后后面的逻辑自然是走不到了。那么之前的对接口集合遍历方式还能用吗？

![984d2882718d61fc485b3a8a9f978fd8.png][]

自然是可以用的，不过就要稍加改造，让实现类的方法返回一个boolean值，当false时，中断这个循环流程即可，这样后面的逻辑就走不到了。

![1e65b37411d4d22abfcae3248eb802cc.png][]

如果不是要中断，而是某条件下执行自己，某条件下跳过自己，这个就往上看看文章的第4段。

# 最后 #

本文通过一些例子，描述了一些场景下对系统的改造方式，由于京东APP后台逻辑复杂，以上场景仅覆盖了部分典型场景，未全部写出改造点，当然还有一部分是特有的非典型问题，可能大部分用户碰不到的场景，也未写出。

如果有遇到类似场景，可参考文中的一些方式进行处理。如果有问题，或有建议，亦可联系作者wuweifeng10@jd.com。

[04ffd60306f142e1e03093a4643e48d0.png]: /images/20220829/8386584ef4ef4b7da7ebc931c7cc0c9f.png
[a5d5c58d764e2916d11c7467c877dad1.png]: /images/20220829/08eee03c8fed4f79a2f071be9afb5489.png
[962861f1a249908b7c1dcaea2263ece4.png]: /images/20220829/1e1cada9e5684d10a2fef032aef29bc0.png
[fc44b884fb0c5223d914c50059c3ddfe.png]: /images/20220829/0f4d3cb1d9354f3a8e34487ba8d7e024.png
[f0110938d90950620d3ad87179c6e35a.png]: /images/20220829/6740ab2e0f49450c901f71d5c3313edc.png
[887e7592dfda74c0b3592caa92551035.png]: /images/20220829/e40e90a5449e43caa1bf30235c0577a4.png
[75dbdcdfc185ebf8c4dcd9ff5a460fe9.png]: /images/20220829/081bc473988d4fb6987f03e8b7b01373.png
[d9c69db69c48a566c0146aad3f59d20a.png]: /images/20220829/6ceac8b01efc4aebafbb920ff59b77ee.png
[e0367583a7687acb3e74807548e722fa.png]: /images/20220829/7dc0970723634e6ebd780fd147269df9.png
[105706c7928af0dacc6960b306bdead7.png]: /images/20220829/3f8b430771b5413a81aef8c94feb8a3e.png
[38d0739dc923e60f513f328d66941280.png]: /images/20220829/1c9cea6d6c584e148938abb88b7becc7.png
[bc23b636706723f6be64c1a2aef150a4.png]: /images/20220829/9ca22450ba1848dd8a9b9b2e807a7df4.png
[d48c53acf1e442cca383e0bb3b8172ae.png]: /images/20220829/4211273b06e949e49f46bdd94e73dd41.png
[fffa660623c2fad36a1cfb9607bc6042.png]: /images/20220829/d2fa30decebb4c1e98460f3986d3d756.png
[53376b5db046a8f49186abd30794a38d.png]: /images/20220829/0709feeef0fa42edb32ce8e31b112013.png
[396a38562901b3e0f18b02d64186647c.png]: /images/20220829/0dff09162ae04ee6a1d86b3f090bf6e0.png
[5d6b2bfe223359afc2a06a469b6ce2ab.png]: /images/20220829/dd5e9bcbaa284f9b90c49173aa75dad2.png
[d16b0adad63a7107e21e946c01df0856.png]: /images/20220829/ff596c09eb134947a57f10f73c8f7bc1.png
[1a93dc2f814a9fa47d6bc77779a2aba3.png]: /images/20220829/ec38e473b7954ca68a972d384e43655a.png
[5906b8931d4e5259c540a465be14b743.png]: /images/20220829/34f27eabf8f74928ba07ed30a6b4dc4f.png
[984d2882718d61fc485b3a8a9f978fd8.png]: /images/20220829/85773afcb1e0431da509e78caa7343e9.png
[1e65b37411d4d22abfcae3248eb802cc.png]: /images/20220829/da1546316a3342f392f8f58a609a4e7d.png