微信支付的软件架构也太特么牛逼了吧...

作者：Jack Jiang
来源：cnblogs.com/imstudy/p/12567241.html

大纲

• 背景
• 线上效果指标
• 什么是软件架构
• 为什么需要软件架构
• 从零到一构建支付跨平台软件架构
  1.抽象业务流程
  2.加入路由机制
  3.管理网络请求
  4.规范数据传递

• 总结

背景

1. iOS 和安卓实现不一致
• 容易出 Bug
• 通过沟通保证不了质量
2. 扩展性差，无法快速响应业务需求
• 需求变更迭代周期长
• 数据上报不全面
3. 质量保障体系不完善
• 缺少业务及设计知识沉淀
• 协议管理松散
• 缺少统一的自动化测试
4. 用户体验不一致
   比如下图就是之前安卓和 iOS 没有统一前的收银台。

   
   

   

微信支付跨平台从 iOS 7.0.4 版本起， 安卓从 7.0.7 版本起全面覆盖。

线上效果指标

1. Crash 率
   上线前后 Crash 率保持平稳，没有影响微信稳定性，跨平台支付无必现 Crash，做到了用户无感知切换。
   举个例子，大家可以用微信发一笔红包，拉起的收银台和支付流程就是由基于C++编写的跨平台代码所驱动的。

2. 效能提升

   
   

   以核心支付流程代码为例，跨平台需要 3512 行，iOS 原生需要 6328 行。减少了近 45% 的代码。

   以新需求开发为例：
   7.0.4 版本需求一：收银台改版
   7.0.4 版本需求二：简化版本收银台
• 跨平台实现：iOS + 安卓 共计 3 人日，在封板时间前完成
• 原生实现：iOS， 安卓封板时间后一周才基本完成
• 跨平台实现：iOS + 安卓共计 5 人日，在封板时间前完成
• 原生实现：iOS， 安卓封板时间后一周才基本完成

对基于 C++ 如何从零到一构建跨平台框架感兴趣的同学，可以在 https://github.com/100mango/zen/blob/master/Qcon2019/%E5%9F%BA%E4%BA%8E%20C%2B%2B%20%E6%9E%84%E5%BB%BA%E5%BE%AE%E4%BF%A1%E5%AE%A2%E6%88%B7%E7%AB%AF%E8%B7%A8%E5%B9%B3%E5%8F%B0%E5%BC%80%E5%8F%91%E6%A1%86%E6%9E%B6.key 下载我在 2019 QCon 广州站的演讲 《基于 C++ 构建微信客户端跨平台开发框架》的 Keynote.

什么是软件架构

为什么需要软件架构

从零到一构建支付跨平台软件架构

既然业界没有一个成熟的架构可借鉴，那么是不是直接把业界通用的架构简单套用一下就好？

1. 抽象业务流程

因此，为了适应微信支付流程多，界面跳转复杂的特点。架构抽象的第一步就是将业务流程抽象为一个独立的角色 UseCase。同时, 把界面抽象为 UIPage。 一个大的业务流程可以分解为一个个小的业务流程。

1. 业务流程的代码能够聚合到 UseCase 中，而不是分散到原来 iOS, 安卓的各个 ViewController，Activity 中。
2. 业务流程和界面得到了复用。

3. 契合微信支付多流程，界面跳转复杂的业务特点。

2. 加入路由机制

既然流程得到了抽象，这个时候需要针对业务流程做更深的思考。在开发支付业务流程时，开发者不可绕过的问题有：

1. 流程之间，页面之间的流传。

   

   比如我们要给一个朋友转账，输入金额，确认支付,触发 Cgi 后。下一个流程是多变的。有可能用户需要去实名，有可能用户要进入一个安全拦截的 WebView，或者是正常拉起收银台。

   本文中的名词 CGI 可以理解为一个网络请求，类似HTTP请求。

   那么以往在 iOS, 安卓分开实现时，都没有一个统一的处理机制。要么就是通过网络回包的某个字段来判断，要么就是本地维护一些状态来决定下一步走什么流程等等。非常繁琐，易错。

2. 特殊流程的处理

   

   支付业务流程还有个特殊的地方，那就是在正常流程的中间，往往很多时候要需要插入一些特殊流程。比如有些地方要跳转 Webview, 有些地方要跳转小程序，有些地方要弹窗告知用户风险，或者终止当前流程，等等。我们经常需要在业务代码里面不断重复增加这样的处理。

这些问题，引导我想到，微信支付需要一个路由机制。

首先了解一下路由机制。

结合微信支付和网络密切相关的特点。创新地将支付领域模型作为传递的数据。

1. 统一了流程，页面的流转。清晰，易维护。
2. 统一了特殊流程的处理，减少重复工作。
3. 在加入路由机制的时候，结合微信支付和网络密切相关的特点进行了支付领域建模。支付后台协议重构 2.0 的核心思想也是围绕着这个路由机制展开。

再来看一下，加入路由机制后，对生产力的提升。以支付流程打开 WebView, 小程序为例，减少将近 83% 的代码。更重要的是，这里的特殊流程，是在路由机制里面统一处理的，没有耦合到业务代码中，并且是可复用的。

3. 管理网络请求

1. CGI 一对多通讯问题。
   举个之前遇到的问题。

   
   

   
   

   那么钱包发起的 Cgi 的回包就会覆盖收付款页面的数据。之前在 iOS 只能通过修修补补，增加场景值，增加些标记位来解决。可能某一天就会又出现新的坑。

1. 进入钱包页面后，发起了一个 Cgi
2. 然后进入收付款页面也发起同一个 Cgi.
3. 如果收付款发起的回包先到

4. 然后钱包首页的回包再到。

2. CGI 生命周期问题。

   

   不时会有用户反馈一下，怎么没有做什么操作，突然就会弹出网络报错。
   原因就是 Cgi 的生命周期有问题，在业务结束后，Cgi 的回包仍然得到了处理。

1. 将 Cgi 抽象为独立对象
   在架构设计上来说，旧架构是通过单例模式实现的集约型 API，而我们新的架构则是通过命令模式实现的离散型 API。
   也就是将 Cgi 封装为独立对象。我们把 Cgi 相关属性和能力内聚起来。开发业务时，只需简单继承 BaseCgi，设置一下参数即可。

   
   

   

2. 划分职责，明确生命周期

   关于 Cgi 由谁发起，之前安卓和 iOS 都没有一个统一的做法。有些人会放到 Activity，ViewController，和 UI 代码耦合起来。

   因此，在跨平台软件架构中，我们统一由业务流程 UseCase 进行发起。并且生命周期是一对一的，一个 Cgi 只会有一个 UseCase 处理， UseCase 销毁后，Cgi 也随之销毁。

1. 杜绝了一对多通信造成的 Bug
2. 生命周期和业务逻辑绑定，不会出现业务结束，Cgi 回来后再触发动作。
3. 高内聚，低耦合。将 Cgi 相关的数据，能力集中处理，业务侧无需感知。

4. 提供统一的缓存，加密能力。

第一步和第二步，我们抽象了业务流程，加入了路由机制。

在第三步管理网络请求后。我们的软件架构演进为这样子。

4. 规范数据传递

之前 iOS 出现，不少内部同事，外部的用户都在反馈：进行零钱页后，会无故弹空白框。而支付又和金钱有关，引起用户的恐慌。在公众号互联网架构师后台回复：2T，可以获取架构师视频整套系统教程。

00:07

1. 进入支付首页时，后台返回了数据，然后被写入到一个公共的 Model.
2. 然后进入钱包页，再进入零钱页。这个公共 model 一路被传递过去。
3. 然后零钱页读取了公共 Model 的数据，但是代码无法处理，导致出现了这个让用户恐慌的问题。

1. 存在公共读写的数据类型。
   安卓传递的数据类型是一个字典，而 iOS 则是一个 Model 对象。所有的界面，业务逻辑都共用一个数据。
2. 无序的数据流动。
   数据的流动是不可追溯的，数据的修改可以发生在任意使用公共数据的地方。

那么支付跨平台软件架构，为了杜绝这样的问题。我是这么做的:

1. 去掉公共读写的数据类型
2. 传递值类型（Value Type）的数据, 后面流程修改数据时，不影响前面的流程。
3. 单向传递数据，只依赖注入必要数据。
4. 如果数据修改需要通知前序流程，使用代理模式通讯。

1. 从架构上根本解决了困扰微信支付已久的数据污染的问题。
2. 数据的流动变为单向，数据流动变得可追溯。

总结

看完本文有收获？请转发分享给更多人

往期资源：