微信支付的架构到底有多牛？

作者：方秋枋原标题：《基于 C++ 构建微信客户端跨平台开发框架》

来自公号：开发者技术前线

背景

作为一个重要业务，微信支付在客户端上面临着各种问题。其中最核心问题就是分平台实现导致的问题：

1. iOS 和安卓实现不一致

• 容易出 Bug

• 通过沟通保证不了质量

2. 扩展性差，无法快速响应业务需求

• 需求变更迭代周期长

• 数据上报不全面

3. 质量保障体系不完善

• 缺少业务及设计知识沉淀

• 协议管理松散

• 缺少统一的自动化测试

4. 用户体验不一致

   比如下图就是之前安卓和 iOS 没有统一前的收银台。

   

为了解决分平台实现这个核心问题，并解决以往的技术债务。我们建立起了一整套基于 C++ 的跨平台框架，并对核心支付流程进行了重构。

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

线上效果指标

以 iOS 上线情况为例:

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.

什么是软件架构？正如 Ivar Jacobson （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 混乱的架构相比：

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

2. 业务流程和界面得到了复用。

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

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

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

   

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

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

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

2. 特殊流程的处理

   探探儲值 抖音充值 在线充值

   

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

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