微信支付系统架构

发布时间:2020-09-01 00:00  

技术干货,第一时间推送

背景

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

iOS 和安卓实现不一致

容易出 Bug

通过沟通保证不了质量

扩展性差,无法快速响应业务需求

需求变更迭代周期长

数据上报不全面

质量保障体系不完善

缺少业务及设计知识沉淀

协议管理松散

缺少统一的自动化测试

用户体验不一致

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

undefined

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

线上效果指标

以 iOS 上线情况为例:

跨平台实现:iOS + 安卓 共计 3 人日,在封板时间前完成

原生实现:iOS, 安卓封板时间后一周才基本完成

跨平台实现:iOS + 安卓共计 5 人日,在封板时间前完成

原生实现:iOS, 安卓封板时间后一周才基本完成

那么支付跨平台软件架构怎么样有效进行质量保障,并且提升生产力呢?这是这篇文章的主要内容。

undefined

对基于 C++ 如何从零到一构建跨平台框架感兴趣的同学,可以在https://github.com/下载。

什么是软件架构

正如 Ivar Jacobson (UML 之父)说过的一样,找五个人来回答这个问题,五个人可能都有各自不同的答案。

架构定义可以有很多种说法,从代码规范到发布流程都可以是架构的一部分。

针对微信支付的业务特点,这里对架构的定义是:架构是系统的组成部件及其之间的相互关系(通讯方式)。

这更符合我们程序员日常编写业务代码时对架构的理解。也就是通俗意义上讲的 , 等。

为什么需要软件架构

早在 1986 年的时候,人月神话的作者在讨论软件的复杂性时,谈到:软件的本质复杂性存在于复杂的业务需求中。

而管理复杂性,最根本的手段就是职责分离。为了实现职责分离,代码重用,架构慢慢地复现出来。架构的本质是管理复杂性。

没有架构,我们所有的代码都耦合在一起,人类的心智模型不擅长处理这种复杂性,架构的设立,和图书馆的图书分类,公司的组织划分等,本质都是一样的。

是为了管理复杂性,以取得更高的生产力。

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

在移动客户端领域,业界基于 来编写业务代码,并没有成熟的架构。即使使用 C++ 编写业务逻辑,但都不涉及 UI,不涉及界面的跳转流程。

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

1. 抽象业务流程

现在业界通用的有 MVC , MVP, MVVM 。这些大家都熟悉的软件架构。但是这些软件架构都存在一个问题: 那就是没有处理好业务流程, 界面转场。

上面的 MV(X) 模式忽略了一个非常重要的一点,那就是业务流程,界面的转场究竟由谁负责。也即 ViewController 与 ViewController 之间的关系由谁维护,业务流程的逻辑写在哪里。

如果还按照传统的 MVC 模式,那么 ViewController 自己负责和不同的 ViewController 通讯。那么 ViewController 得不到复用,更致命的是业务流程的代码非常不清晰,业务流程的代码都被分散到各个 Controller 中, 而一个 Controller 又可能耦合了多个业务的代码。

举个例子:一个普通的转账流程,可能会涉及风控拦截,实名验证, 收银台, 绑卡,支付成功页等等。

如果是基于 这种架构的话,很快代码会变得难以维护。

undefined

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

和刚才基于 MVC 混乱的架构相比:

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

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

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

2. 加入路由机制

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

流程之间,页面之间的流传。

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

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

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

特殊流程的处理

undefined

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

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

首先了解一下路由机制。

路由机制的核心思想,就是通过向路由传递数据,然后路由解析数据,并响应。

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

那么怎么建立这个支付领域模型的呢?

建模,就是建立映射。领域知识 + 建模方法 = 领域建模。那么这里的领域知识,就是对支付业务流程的理解。建模方法,我采用了 UML 建模。最终会落地为 Proto 协议供客户端和后台一起使用。