点击上方“芋道源码”，选择“设为星标”

做积极的人，而不是积极废人！

源码精品专栏

• 中文详细注释的开源项目

• RPC 框架 Dubbo 源码解析

• 络应用框架 Netty 源码解析

• 消息中间件 RocketMQ 源码解析

• 数据库中间件 Sharding-JDBC 和 MyCAT 源码解析

• 作业调度中间件 Elastic-Job 源码解析

• 分布式事务中间件 TCC-Transaction 源码解析

• Eureka 和 Hystrix 源码解析

• Java 并发源码

• 背景

• 线上效果指标

• 什么是软件架构

• 为什么需要软件架构

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

• • 1. 抽象业务流程

  • 2. 加入路由机制

  • 3. 管理 络请求

  • 4. 规范数据传递

• 总结

背景

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

iOS 和安卓实现不一致

• 容易出 Bug

• 通过沟通保证不了质量

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

• 需求变更迭代周期长

• 数据上 不全面

质量保障体系不完善

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

• 协议管理松散

• 缺少统一的自动化测试

用户体验不一致

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

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

以新需求开发为例：

7.0.4 版本需求一：收银台改版

7.0.4 版本需求二：简化版本收银台

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

• 原生实现：iOS， 安卓封板时间后一周才基本完成

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

• 原生实现：iOS， 安卓封板时间后一周才基本完成

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

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

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

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

2、特殊流程的处理

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

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

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

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

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

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

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

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

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

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

原来支付的请求，都是通过一个单例 络中心去发起请求，然后收到回包后，通过抛通知，或者调用闭包的方式回调给业务侧。

会存在这样的问题：

1、CGI 一对多通讯问题。

举个之前遇到的问题。

不时会有用户反馈一下，怎么没有做什么操作，突然就会弹出 络 错。

原因就是 Cgi 的生命周期有问题，在业务结束后，Cgi 的回包仍然得到了处理。

解决方案：

1、将 Cgi 抽象为独立对象

在架构设计上来说，旧架构是通过单例模式实现的集约型 API，而我们新的架构则是通过命令模式实现的离散型 API。

也就是将 Cgi 封装为独立对象。我们把 Cgi 相关属性和能力内聚起来。开发业务时，只需简单继承 BaseCgi，设置一下参数即可。

对比旧架构：

1. 杜绝了一对多通信造成的 Bug

2. 生命周期和业务逻辑绑定，不会出现业务结束，Cgi 回来后再触发动作。

3. 高内聚，低耦合。将 Cgi 相关的数据，能力集中处理，业务侧无需感知。

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

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

具体原因就是:

1. 进入支付首页时，后台返回了数据，然后被写入到一个公共的 Model.

2. 然后进入钱包页，再进入零钱页。这个公共 model 一路被传递过去。

3. 然后零钱页读取了公共 Model 的数据，但是代码无法处理，导致出现了这个让用户恐慌的问题。

除此之外，之前还有有很多发生在安卓，iOS ，像钱包页零钱展示错误。付款的时候。银行卡失效等等问题。

这些问题五花八门，看起来发生的地方，场景都不一样。每次遇到这类问题的时候，就只能去修修补补。

但是深究下去，会发现真正的原因，是软件架构上存在的问题：

1. 去掉公共读写的数据类型

2. 传递值类型（Value Type）的数据, 后面流程修改数据时，不影响前面的流程。

3. 单向传递数据，只依赖注入必要数据。

4. 如果数据修改需要通知前序流程，使用代理模式通讯。

规范数据传递后。对比旧架构:

1. 从架构上根本解决了困扰微信支付已久的数据污染的问题。

2. 数据的流动变为单向，数据流动变得可追溯。

前面三步，我们抽象了业务流程，加入了路由机制，统一管理 络请求。

总结

软件的本质复杂性存在于复杂的业务需求中。而软件架构的本质就是管理复杂性，因此真正的好的架构，正是在复杂的业务需求中反复提炼和总结归纳而来，解决了真正的业务问题，不是空谈。

软件架构除了清理历史旧架构的缺陷，是我们业务开发的基石之外。还能够赋能业务，为业务带来价值。在建立软件架构的基础上，还围绕着软件架构建立起微信支付的跨平台自动化数据上 机制，防重复支付，安全横切等带来巨大业务收益的能力。有机会的话，后面也会进一步编写相关文章和大家交流探讨。

架构是一个不断演进的过程，随着新的支付业务基于跨平台软件架构的不断编写， 我也会对这个架构进行持续的更新迭代。让这个软件架构更贴合微信支付，更加健壮和完整。

欢迎加入我的知识星球，一起探讨架构，交流源码。加入方式，长按下方二维码噢：