微信架构 & 支付架构（上）
一. 微信和支付宝对比
这两者现在已经占领了移动支付的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 之父）说过的一样，找五个人来回答这个问题，五个人可能都有各自不同的答案。
架构定义可以有很多种说法，从代码规范到发布流程都可以是架构的一部分。
针对微信支付的业务特点，这里对架构的定义是：架构是系统的组成部件及其之间的相互关系（通讯方式）。这更符合我们程序员日常编写业务代码时对架构的理解。也就是通俗意义上讲的 MVC，MVVM 等。
为什么需要软件架构
早在 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% 的代码。更重要的是，这里的特殊流程，是在路由机制里面统一处理的，没有耦合到业务代码中，并且是可复用的。