微信支付软件架构，这也太厉害了
作者：JackJiang
背景
作为一个重要业务 ， 微信支付在客户端上面临着各种问题 。 其中最核心问题就是分平台实现导致的问题：
iOS和安卓实现不一致
容易出Bug
通过沟通保证不了质量
扩展性差 ， 无法快速响应业务需求
需求变更迭代周期长
数据上报不全面
质量保障体系不完善
缺少业务及设计知识沉淀
协议管理松散
缺少统一的自动化测试
用户体验不一致
比如下图就是之前安卓和iOS没有统一前的收银台 。
文章图片
为了解决分平台实现这个核心问题 ， 并解决以往的技术债务 。 我们建立起了一整套基于C++的跨平台框架 ， 并对核心支付流程进行了重构 。
微信支付跨平台从iOS7.0.4版本起 ， 安卓从7.0.7版本起全面覆盖 。
线上效果指标
以iOS上线情况为例:
Crash率
上线前后Crash率保持平稳 ， 没有影响微信稳定性 ， 跨平台支付无必现Crash ， 做到了用户无感知切换 。
举个例子 ， 大家可以用微信发一笔红包 ， 拉起的收银台和支付流程就是由基于C++编写的跨平台代码所驱动的 。
效能提升
文章图片
以核心支付流程代码为例 ， 跨平台需要3512行 ， iOS原生需要6328行 。 减少了近45%的代码 。
以新需求开发为例：
7.0.4版本需求一：收银台改版
7.0.4版本需求二：简化版本收银台
跨平台实现：iOS+安卓共计3人日 ， 在封板时间前完成
原生实现：iOS ， 安卓封板时间后一周才基本完成
跨平台实现：iOS+安卓共计5人日 ， 在封板时间前完成
原生实现：iOS ， 安卓封板时间后一周才基本完成
那么支付跨平台软件架构怎么样有效进行质量保障 ， 并且提升生产力呢？这是这篇文章的主要内容 。
文章图片
什么是软件架构
什么是软件架构？正如IvarJacobson（UML之父）说过的一样 ， 找五个人来回答这个问题 ， 五个人可能都有各自不同的答案 。
架构定义可以有很多种说法 ， 从代码规范到发布流程都可以是架构的一部分 。
针对微信支付的业务特点 ， 这里对架构的定义是：架构是系统的组成部件及其之间的相互关系（通讯方式） 。 这更符合我们程序员日常编写业务代码时对架构的理解 。 也就是通俗意义上讲的MVC ， MVVM等 。
【微信支付软件架构，这也太厉害了】为什么需要软件架构
早在1986年的时候 ， 人月神话的作者在讨论软件的复杂性时 ， 谈到：软件的本质复杂性存在于复杂的业务需求中 。
而管理复杂性 ， 最根本的手段就是职责分离 。 为了实现职责分离 ， 代码重用 ， 架构慢慢地复现出来 。 架构的本质是管理复杂性 。
没有架构 ， 我们所有的代码都耦合在一起 ， 人类的心智模型不擅长处理这种复杂性 ， 架构的设立 ， 和图书馆的图书分类 ， 公司的组织划分等 ， 本质都是一样的 。 是为了管理复杂性 ， 以取得更高的生产力 。
从零到一构建支付跨平台软件架构
在移动客户端领域 ， 业界基于C++来编写业务代码 ， 并没有成熟的架构 。 即使使用C++编写业务逻辑 ， 但都不涉及UI ， 不涉及界面的跳转流程 。
既然业界没有一个成熟的架构可借鉴 ， 那么是不是直接把业界通用的架构简单套用一下就好？
1.抽象业务流程
现在业界通用的有MVC,MVP,MVVM 。 这些大家都熟悉的软件架构 。 但是这些软件架构都存在一个问题：那就是没有处理好业务流程 ， 界面转场 。
微信支付的流程多 。 而流程就是由一个个的界面（ViewController ， Activity）和相关的业务逻辑组合而成 。
上面的MV(X)模式忽略了一个非常重要的一点 ， 那就是业务流程 ， 界面的转场究竟由谁负责 。 也即ViewController与ViewController之间的关系由谁维护 ， 业务流程的逻辑写在哪里 。
如果还按照传统的MVC模式 ， 那么ViewController自己负责和不同的ViewController通讯 。 那么ViewController得不到复用 ， 更致命的是业务流程的代码非常不清晰 ， 业务流程的代码都被分散到各个Controller中 ， 而一个Controller又可能耦合了多个业务的代码 。
举个例子：一个普通的转账流程 ， 可能会涉及风控拦截 ， 实名验证 ， 收银台 ， 绑卡 ， 支付成功页等等 。 如果是基于MVC这种架构的话 ， 很快代码会变得难以维护 。
文章图片
因此 ， 为了适应微信支付流程多 ， 界面跳转复杂的特点 。 架构抽象的第一步就是将业务流程抽象为一个独立的角色UseCase 。 同时,把界面抽象为UIPage 。 一个大的业务流程可以分解为一个个小的业务流程 。
文章图片
和刚才基于MVC混乱的架构相比：
业务流程的代码能够聚合到UseCase中 ， 而不是分散到原来iOS,安卓的各个ViewController ， Activity中 。
业务流程和界面得到了复用 。
契合微信支付多流程 ， 界面跳转复杂的业务特点 。
2.加入路由机制
既然流程得到了抽象 ， 这个时候需要针对业务流程做更深的思考 。 在开发支付业务流程时 ， 开发者不可绕过的问题有：
1、流程之间 ， 页面之间的流传 。
文章图片
比如我们要给一个朋友转账 ， 输入金额 ， 确认支付,触发Cgi后 。 下一个流程是多变的 。 有可能用户需要去实名 ， 有可能用户要进入一个安全拦截的WebView ， 或者是正常拉起收银台 。
本文中的名词CGI可以理解为一个网络请求 ， 类似HTTP请求 。
那么以往在iOS,安卓分开实现时 ， 都没有一个统一的处理机制 。 要么就是通过网络回包的某个字段来判断 ， 要么就是本地维护一些状态来决定下一步走什么流程等等 。 非常繁琐 ， 易错 。
2、特殊流程的处理
文章图片
支付业务流程还有个特殊的地方 ， 那就是在正常流程的中间 ， 往往很多时候要需要插入一些特殊流程 。 比如有些地方要跳转Webview,有些地方要跳转小程序 ， 有些地方要弹窗告知用户风险 ， 或者终止当前流程 ， 等等 。 我们经常需要在业务代码里面不断重复增加这样的处理 。
这些问题 ， 引导我想到 ， 微信支付需要一个路由机制 。
首先了解一下路由机制 。
文章图片
路由机制的核心思想 ， 就是通过向路由传递数据 ， 然后路由解析数据 ， 并响应 。
结合微信支付和网络密切相关的特点 。 创新地将支付领域模型作为传递的数据 。
文章图片
那么怎么建立这个支付领域模型的呢？
建模 ， 就是建立映射 。 领域知识+建模方法=领域建模 。 那么这里的领域知识 ， 就是对支付业务流程的理解 。 建模方法 ， 我采用了UML建模 。 最终会落地为Proto协议供客户端和后台一起使用 。
文章图片
首先 ， 微信支付业务特点就是和网络密切相关 ， 流程和页面往往是由Cgi串联起来 。 因此建立模型时 ， 最外层便是网络回包 。 对于路由机制 ， 这里我们只关心路由数据模型 。
路由数据模型由路由类型 ， 还有各个路由类型所需要的信息组合成 。
路由类型清晰的定义了要触发的行为 。 究竟是要开启一个UseCase ， 还是要打开一个界面 ， 或者网页 ， 小程序 ， 弹窗等等 。
然后就是这些行为所需要的数据 。 比如打开小程序所需要的参数 ， 弹窗所需要的参数等 。
文章图片
建立支付领域模型后 ， 我们路由的解析就变得非常清晰了 。 路由解析之后 ， 会根据路由类型 ， 触发不同的动作 。
比如流程 ， 界面流转 ， 会交给UseCase处理 。
而特殊流程 ， 比如打开小程序 ， 打开webview,弹窗这些行为会统一进行处理 。
我们在第一步把业务流程抽象为UseCase 。 第二步则加入了路由机制 。
加入路由机制后 ， 支付跨平台的软件架构演进为这个样子 。
文章图片
加入路由机制后 ， 对比iOS ， 安卓原来的旧架构:
统一了流程 ， 页面的流转 。 清晰 ， 易维护 。
统一了特殊流程的处理 ， 减少重复工作 。
在加入路由机制的时候 ， 结合微信支付和网络密切相关的特点进行了支付领域建模 。 支付后台协议重构2.0的核心思想也是围绕着这个路由机制展开 。
文章图片
再来看一下 ， 加入路由机制后 ， 对生产力的提升 。 以支付流程打开WebView,小程序为例 ， 减少将近83%的代码 。 更重要的是 ， 这里的特殊流程 ， 是在路由机制里面统一处理的 ， 没有耦合到业务代码中 ， 并且是可复用的 。
3.管理网络请求
首先看看原来iOS处理支付网络请求的缺陷：
文章图片
原来支付的请求 ， 都是通过一个单例网络中心去发起请求 ， 然后收到回包后 ， 通过抛通知 ， 或者调用闭包的方式回调给业务侧 。
会存在这样的问题：
1、CGI一对多通讯问题 。
举个之前遇到的问题 。
文章图片
那么钱包发起的Cgi的回包就会覆盖收付款页面的数据 。 之前在iOS只能通过修修补补 ， 增加场景值 ， 增加些标记位来解决 。 可能某一天就会又出现新的坑 。
1、进入钱包页面后 ， 发起了一个Cgi
2、然后进入收付款页面也发起同一个Cgi.
3、如果收付款发起的回包先到
4、然后钱包首页的回包再到 。
5、CGI生命周期问题 。
文章图片
不时会有用户反馈一下 ， 怎么没有做什么操作 ， 突然就会弹出网络报错 。
原因就是Cgi的生命周期有问题 ， 在业务结束后 ， Cgi的回包仍然得到了处理 。
解决方案：
1、将Cgi抽象为独立对象
在架构设计上来说 ， 旧架构是通过单例模式实现的集约型API ， 而我们新的架构则是通过命令模式实现的离散型API 。
也就是将Cgi封装为独立对象 。 我们把Cgi相关属性和能力内聚起来 。 开发业务时 ， 只需简单继承BaseCgi ， 设置一下参数即可 。
文章图片
2、划分职责 ， 明确生命周期
关于Cgi由谁发起 ， 之前安卓和iOS都没有一个统一的做法 。 有些人会放到Activity ， ViewController ， 和UI代码耦合起来 。
因此 ， 在跨平台软件架构中 ， 我们统一由业务流程UseCase进行发起 。 并且生命周期是一对一的 ， 一个Cgi只会有一个UseCase处理 ， UseCase销毁后 ， Cgi也随之销毁 。
文章图片
对比旧架构：
杜绝了一对多通信造成的Bug
生命周期和业务逻辑绑定 ， 不会出现业务结束 ， Cgi回来后再触发动作 。
高内聚 ， 低耦合 。 将Cgi相关的数据 ， 能力集中处理 ， 业务侧无需感知 。
提供统一的缓存 ， 加密能力 。
文章图片
第一步和第二步 ， 我们抽象了业务流程 ， 加入了路由机制 。
在第三步管理网络请求后 。 我们的软件架构演进为这样子 。
文章图片
4.规范数据传递
iOS和安卓的旧架构都存在信息传递不当和数据污染问题 。 这个问题最严重 。 iOS和安卓都出过不少bug 。
首先我们来看看最近现网出现过的问题：
之前iOS出现 ， 不少内部同事 ， 外部的用户都在反馈：进行零钱页后 ， 会无故弹空白框 。 而支付又和金钱有关 ， 引起用户的恐慌 。
文章图片
具体原因就是:
进入支付首页时 ， 后台返回了数据 ， 然后被写入到一个公共的Model.
然后进入钱包页 ， 再进入零钱页 。 这个公共model一路被传递过去 。
然后零钱页读取了公共Model的数据 ， 但是代码无法处理 ， 导致出现了这个让用户恐慌的问题 。
除此之外 ， 之前还有有很多发生在安卓 ， iOS ， 像钱包页零钱展示错误 。 付款的时候 。 银行卡失效等等问题 。
这些问题五花八门 ， 看起来发生的地方 ， 场景都不一样 。 每次遇到这类问题的时候 ， 就只能去修修补补 。
但是深究下去 ， 会发现真正的原因 ， 是软件架构上存在的问题：
文章图片
支付旧的架构采用了黑板模式 ， 虽然方便了数据读写 。 但是带来的问题和收益完全不成正比：
1.存在公共读写的数据类型 。
安卓传递的数据类型是一个字典 ， 而iOS则是一个Model对象 。 所有的界面 ， 业务逻辑都共用一个数据 。
2.无序的数据流动 。
数据的流动是不可追溯的 ， 数据的修改可以发生在任意使用公共数据的地方 。
那么支付跨平台软件架构 ， 为了杜绝这样的问题 。 我是这么做的:
文章图片
去掉公共读写的数据类型
传递值类型（ValueType）的数据,后面流程修改数据时 ， 不影响前面的流程 。
单向传递数据 ， 只依赖注入必要数据 。
如果数据修改需要通知前序流程 ， 使用代理模式通讯 。
规范数据传递后 。 对比旧架构:
从架构上根本解决了困扰微信支付已久的数据污染的问题 。
数据的流动变为单向 ， 数据流动变得可追溯 。
前面三步 ， 我们抽象了业务流程 ， 加入了路由机制 ， 统一管理网络请求 。
那么规范数据传递后 ， 我们软件架构就演进为这样子 。
文章图片
总结
软件的本质复杂性存在于复杂的业务需求中 。 而软件架构的本质就是管理复杂性 ， 因此真正的好的架构 ， 正是在复杂的业务需求中反复提炼和总结归纳而来 ， 解决了真正的业务问题 ， 不是空谈 。
软件架构除了清理历史旧架构的缺陷 ， 是我们业务开发的基石之外 。 还能够赋能业务 ， 为业务带来价值 。 在建立软件架构的基础上 ， 还围绕着软件架构建立起微信支付的跨平台自动化数据上报机制 ， 防重复支付 ， 安全横切等带来巨大业务收益的能力 。 有机会的话 ， 后面也会进一步编写相关文章和大家交流探讨 。
架构是一个不断演进的过程 ， 随着新的支付业务基于跨平台软件架构的不断编写 ， 我也会对这个架构进行持续的更新迭代 。 让这个软件架构更贴合微信支付 ， 更加健壮和完整 。
推荐阅读
- 王者荣耀：微信区跟QQ区到底谁更菜？官方道出实情！
- 支付宝、微信未必安全？手机出现这3种征兆，你或许已被黑客监听
- 英法院裁定印度首富亲弟败诉，需21天内向中资银行支付7.17亿美元
- 小鹏汽车P7正式亮相深圳 和支付宝达成战略合作
- 对感情专一的男人，微信上会有这5个表现！
- 人民网微信“报复性消费”还是“报复性存钱”？发改委回应！
- 微信增加这一功能，每个人都可以赚钱，能赚多少看本事
- 听歌要不要付费？当然要，但是能把付费歌曲放在同一款软件上吗？
- 没密码就能扫走你的钱？微信支付一定要打开这个功能，要设置好
- 微信头像，人比花娇，活出自己