微信架构 & 支付架构(上)

微信架构 & 支付架构(上)

一. 微信和支付宝对比

  这两者现在已经占领了移动支付的90%市场,支付形式也都大抵相同,只是在实现细节上略微不同。这里之所以要专门对比,是因为有些接口的不同在后边的框架的设计中也会有所影响。主要集中在以下几个方面:

  1. 支付方式上:

    a. 支付宝多了一个声波支付

    b. 手机端H5支付方式中, 微信只支持微信内部浏览器

    c. 微信用户扫码方式中除了正常下单返回支付二维码,还提提供了回调下单模式(即扫描的二维码并不是支付二维码,而是商品二维码,微信会回调商户指定地址才真实下单)

  2. 接口安全

    a.  微信不同接口安全等级不一样,涉及付款等接口加密相对简单(MD5,SHA1),涉及到退款,发送红包等接口需要使用双向证书验证

    b.  支付宝所有接口统一使用RSA加密验证,需要公私钥验证。

  3. 接口协议

    a. 微信使用的xml协议,所有参数基本都在同一层级。

    b. 支付宝使用json协议,核心参数放在biz_content字段中。

 二. 微信和支付宝软件架构

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

iOS 和安卓实现不一致

  • 容易出 Bug
  • 通过沟通保证不了质量

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

  • 需求变更迭代周期长
  • 数据上报不全面

质量保障体系不完善

  • 缺少业务及设计知识沉淀
  • 协议管理松散
  • 缺少统一的自动化测试

用户体验不一致

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

 微信架构 & 支付架构(上)

 

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

微信支付跨平台从 iOS 7.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, 安卓封板时间后一周才基本完成

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

 微信架构 & 支付架构(上)

 

 什么是软件架构

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

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

针对微信支付的业务特点,这里对架构的定义是:架构是系统的组成部件及其之间的相互关系(通讯方式)。这更符合我们程序员日常编写业务代码时对架构的理解。也就是通俗意义上讲的 MVCMVVM 等。

为什么需要软件架构

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

而管理复杂性,最根本的手段就是职责分离。为了实现职责分离,代码重用,架构慢慢地复现出来。架构的本质是管理复杂性。关注微信公众号:Java技术栈,在后台回复:架构,可以获取我整理的 N 篇架构干货。

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

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

在移动客户端领域,业界基于 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.  契合微信支付多流程,界面跳转复杂的业务特点。

2. 加入路由机制

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

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

微信架构 & 支付架构(上)

 

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

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

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

2、特殊流程的处理

微信架构 & 支付架构(上)

 

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

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

首先了解一下路由机制。

微信架构 & 支付架构(上)

 

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

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

微信架构 & 支付架构(上)

 

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

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

微信架构 & 支付架构(上)

 

 首先,微信支付业务特点就是和网络密切相关,流程和页面往往是由 Cgi 串联起来。因此建立模型时,最外层便是网络回包。对于路由机制,这里我们只关心路由数据模型。

路由数据模型由路由类型,还有各个路由类型所需要的信息组合成。

路由类型清晰的定义了要触发的行为。究竟是要开启一个 UseCase,还是要打开一个界面,或者 网页,小程序,弹窗等等。

然后就是这些行为所需要的数据。比如打开小程序所需要的参数,弹窗所需要的参数等。

微信架构 & 支付架构(上)

 

 建立支付领域模型后,我们路由的解析就变得非常清晰了。路由解析之后,会根据路由类型,触发不同的动作。

比如流程,界面流转,会交给 UseCase 处理。

而特殊流程,比如打开小程序,打开 webview, 弹窗这些行为会统一进行处理。

我们在第一步把业务流程抽象为 UseCase。第二步则加入了路由机制。

加入路由机制后,支付跨平台的软件架构演进为这个样子。

微信架构 & 支付架构(上)

 

 加入路由机制后,对比 iOS,安卓原来的旧架构:

1.  统一了流程,页面的流转。清晰,易维护。

2.  统一了特殊流程的处理,减少重复工作。

3.  在加入路由机制的时候,结合微信支付和网络密切相关的特点进行了支付领域建模。支付后台协议重构 2.0 的核心思想也是围绕着这个路由机制展开。

微信架构 & 支付架构(上)

 

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

 

 

微信架构 & 支付架构(上)

上一篇:微信小程序开发(一)-环境准备


下一篇:如何使用spring将service层注入到servlet中去(how to use Spring to inject ur service layer into the servlet )