京东支付SDK重构设计与实现

背景

众所周知，软件开发效率、维护成本与自身复杂度成正比，而客户端软件复杂度则主要体现在业务规模上。

京东支付Android SDK从2015年启动以来，已历经五个春秋，如今发展到纯支付业务代码7.5W行的规模（不含支付团队内部基础组件库和兄弟团队生物识别、安全等近10个SDK）。为应对每年618、11.11大促考验，内置各种降级逻辑致使部分功能要准备至少两种技术实现方案，复杂度不言而喻。虽然久经沙场，然而步履愈发沉重。究其原因，无外乎技术圈这些司空见惯的槽点：

1. 业务发展太快，早期技术架构已经不能很好的适应变化，而业务需求又繁重，架构升级计划一次次被延后，最后不了了之。

2. 既然架构不能支持新业务，就只能通过各种“旁门左道”的方式破坏架构来解决问题，以至于进化成没有架构，只有各位前辈高人馈遗的祖传套路，谓之“祖宗家法不可变”。

3. 没有实际价值的业务代码一直苟延残喘的留在系统里，变成长期的维护负担。

4. 设计文档、接口文档、代码注释缺失或更新不及时，致使涉及多系统交互的代码后人往往只能因循将就，不敢轻言优化。

有鉴于此，为使京东支付SDK未来能轻快地奔跑，从容应对变化，我们决定重构。目标：实现软件复杂度增长低于业务复杂度增长的目标。

一、支付业务组成

常言道：脱离业务的架构都属于自嗨。

为实现重构目标，我们需要：

1. 先梳理清楚业务特点，做业务层抽象；

2. 找出当前软件系统痛点所在，做技术层分析；

3. 结合业务层抽象与技术层分析，设计新解决方案；
   

上图比较宏观的把SDK划分为几大组成单元，特点是：

1. 所有组成单元之间都是双向依赖，任何一个业务单元都可以作为其他业务单元的前置流程，也可以成为其他业务单元的下一步流程，很多业务单元内部还存在互相依赖。而这种循环、交叉的依赖，重构之难可想而知，修改一处影响一片。每当试图把重构拆分成多个小任务来迭代执行时就会发现，粒度实难控制，因为改着改着就涉及上百个文件了…

2. 业务变种众多，举个例子，仅短信验证一个功能就有内单、外单、支付验证、风控加验、白条开通、证书安装、全屏页、半屏页、特殊业务等诸多变种，这些变种彼此组合才能完成一个短信验证操作，如“内单+风控加验+半屏”这几个组合就是一种常见的短信验证流程，而“外单+风控加验+全屏”又是另一种组合，依此类推。

3. 异常流程繁杂，为了尽可能使用户完成支付，必须识别并区别处理各种失败情况。如：忘记密码的要引导用户找回密码、余额不足的要引导用户更换支付方式等等。异常流程往往伴随着多次支付流程重试行为，也就是说已经执行过的流程，部分数据要保留，部分数据要替换，因此，确保模块重新执行时入参和出参的精准性也是一大难题。

二、经典架构模式能否解决问题？

京东支付SDK一直以来使用的是MVP模式，它的优势在于分离UI与业务逻辑，即关注单个页面及相关数据、业务代码如何构建。其核心聚焦于“点”上。而对支付业务而言，任何一个单一页面都算不上复杂，它的复杂性体现在如何把这些简单的页面（点）串联起来组成一个可执行的业务链（线）。同理，MVC、MVVM等经典模式同样也无法解决由点到线的问题。而VIPER模式有人把它比喻为搭乐高，可以串联各个模块，它里面包含的R(Router)确实是处理模块跳转用的，这么看似乎有机会解决点到线的问题，那么可否一战呢？我们来进一步分析。

这是网上流传很广泛的一张图，View和Presenter无需多说，Router负责模块(页面)跳转，而Entity和Interactor大体上是把传统的Model职责拆开，纯数据对象作为Entity(Bean)，Interactor用来管理调度数据。但是，问题在于怎么来管理数据？我们考虑有两种可能：

1、将Interactor设计为Presenter级别数据管理器

这样的话，那么支付这种模块众多且交叉、循环耦合的业务，谁来处理模块间数据流转的准确性呢？如图所示，Interactor与Router并没有直接交互，而是通过Presenter来处理。这就使得单个模块的Presener可能需要知道其他模块所需的数据来自哪里，以及如何组装出下个模块的入参，如此一来，Presenter难免感知、耦合其他模块。当一个模块耦合了一堆其他模块之时，牵一发动全身就不难理解了。不幸的是，京东支付SDK重构前就存在这种情况，各种验证工具模块更是重灾区，因为几乎每种验证工具的Presenter中都包含了一堆业务场景的定制逻辑。举个例子：

密码验证Presenter由A、B、C业务调用时的入参、出参各不相同，下一步流程也不一样，这种情况下如果Router的数据由密码验证Presenter来提供的话，势必要耦合前后各种不同的业务逻辑。那么，如果给每种业务场景提供专属Presenter怎么样呢？支付SDK重构前也是这么做的，仅短信验证至少就有8种对接不同业务的Presenter实现，然而并不能彻底解决问题，因为每种验证方式都