微信支付的软件架构太特殊了，对吧...

作者: 江杰|

背景

作为一项重要业务，微信支付在客户上面临各种问题. 核心问题是由子平台的实施引起的问题:

iOS和Android的实现不一致

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

不完整的质量保证体系

不一致的用户体验

例如，下图显示了Android和iOS尚未统一之前的收银机.

为了解决子平台实现的核心问题，并解决了以往的技术债务. 我们已经建立了一套完整的基于C ++的跨平台框架，并重构了核心付款流程.

从iOS 7.0.4版本开始的微信支付跨平台，从7.0.7版本开始的Android全面覆盖.

以iOS为例:

崩溃率

上线前后的崩溃率保持稳定，且不影响微信的稳定性. 跨平台付款不一定会崩溃，从而使用户可以在不知不觉中进行切换.

例如，您可以使用微信发送一个红色信封. 收银机和付款流程由用C ++编写的跨平台代码驱动.

性能提升

以核心支付流程代码为例，跨平台需要3512行，而iOS本机需要6328行. 代码减少了近45％.

以新需求开发为例:

7.0.4版本1: 收银机修订

7.0.4版本要求2: 简化版本的收银机

那么支付跨平台软件架构如何有效地保证质量并提高生产率？这是本文的主要内容.

什么是软件体系结构？正如UML之父Ivar Jacobson所说，找到五个人来回答这个问题，五个人可能会有不同的答案.

定义体系结构的方法有很多，从代码规范到发布过程都可以是体系结构的一部分.

根据微信支付的业务特点，这里的架构定义是: 架构是系统的组成部分，是系统的相互关系（通信方式）. 这更符合我们的程序员在编写业务代码时对体系结构的日常理解. 即流行的MVC，MVVM等.

早在1986年，人月神话的作者讨论了软件的复杂性时，他就谈到: 软件的本质复杂性存在于复杂的业务需求中.

管理复杂性的最基本方法是分工. 为了实现职责分离，代码重用，该体系结构是缓慢复制的. 体系结构的本质是管理复杂性.

没有体系结构，我们所有的代码都耦合在一起. 人类的心理模型并不擅长处理这种复杂性. 体系结构的建立与图书馆书籍分类和公司组织部门相同. 管理复杂性以实现更高的生产率.

在移动客户端领域，该行业基于C ++编写业务代码，并且没有成熟的体系结构. 即使业务逻辑是用C ++编写的，它也不涉及UI，也不涉及接口的跳转过程.

由于该行业没有成熟的体系结构可以学习，因此简单地应用该行业常用的体系结构就可以吗？

MVC，MVP，MVVM在行业中通常使用. 这些是熟悉的软件体系结构. 但是这些软件体系结构存在一个问题: 即业务流程处理不当微信支付java开发详细，并且接口转换.

微信支付流程很多. 该过程由接口（ViewController，Activity）和相关业务逻辑的组合组成.

上面的MV（X）模式忽略了非常重要的一点，即业务流程以及负责接口转换的人员. 也就是说，谁维护了ViewController和ViewController之间的关系，并编写了业务流程的逻辑.

如果您仍然遵循传统的MVC模式，则ViewController本身负责与其他ViewController通信. 这样就无法再使用ViewController. 更致命的是，业务流程的代码还不清楚. 业务流程的代码分散在每个Controller中，一个Controller可以与多个服务的代码耦合.

一个例子: 一个普通的转账过程可能涉及风险控制拦截，实名验证，收银机，卡绑定，付款成功页面等. 如果它基于MVC架构，则该代码将很快变得难以维护.

因此，为了适应微信支付过程，界面跳转比较复杂. 架构抽象的第一步是将业务流程抽象为一个单独的角色UseCase. 同时，该接口被抽象为UIPage. 大型业务流程可以分解为小型业务流程.

与刚才基于MVC的混乱体系相比:

业务流程的代码可以聚合到UseCase中，而不是分发到iOS和Android的原始ViewController和Activity.

业务流程和接口已被重用.

界面符合微信支付的多流程，跳转到复杂的业务特征.

由于流程已被抽象化，是时候更深入地思考业务流程了. 在开发支付业务流程时，开发人员无法绕过的问题是:

1. 流程和页面之间的流程.

例如，我们要转账给朋友，输入金额，确认付款，然后触发Cgi. 下一个过程是可变的. 用户可能需要使用真实姓名，用户可能想要输入被安全拦截的WebView，或者通常是拉起收银机.

本文中的术语CGI可以理解为网络请求，类似于HTTP请求.

因此，过去，当iOS和Android分别实现时，没有统一的处理机制. 要么通过网络响应包的字段来判断，要么在本地维护某种状态以决定下一步要执行的过程，依此类推. 非常麻烦且容易出错.

2. 特殊流程的处理

在支付业务流程中有一个特殊的位置，即在正常流程的中间，通常需要插入一些特殊的流程. 例如，有些地方可以跳到Webview，有些地方可以跳到小程序，有些地方可以弹出窗口通知用户风险，或者终止当前过程，等等. 我们经常需要在业务代码中重复添加此类处理.

这些问题使我认为微信支付需要一种路由机制.

首先了解路由机制.

路由机制的核心思想是将数据传递到路由，然后路由解析数据并做出响应.

结合微信支付与网络的特点密切相关. 创新地使用支付域模型作为传输数据.

那么您如何构建此付款域模型？

建模是建立映射. 领域知识+建模方法=领域建模. 那么这里的领域知识就是对支付业务流程的理解. 建模方法，我使用UML建模. 最终，它将成为客户端和后台一起使用的Proto协议.

首先，微信支付业务的特点与网络息息相关，流程和页面经常由Cgi连接. 因此，在构建模型时，最外层是网络数据包返回. 对于路由机制，这里我们只关心路由数据模型.

路由数据模型由路由类型和每种路由类型所需的信息组成.

路由类型明确定义了要触发的行为. 是否打开UseCase或界面，网页，小程序，弹出窗口等.

然后执行这些操作所需的数据. 例如，打开小程序所需的参数，弹出窗口所需的参数，等等.

建立支付域模型后，我们的路线分析变得非常清晰. 路由解析后，会根据路由类型触发不同的动作.

例如，流程和界面流将移交给UseCase.

特殊过程（例如打开小程序，打开Web视图和弹出窗口）将以统一的方式处理.

第一步，我们将业务流程抽象为UseCase. 第二步是添加路由机制.

在添加了路由机制之后，跨平台支付软件体系结构已经发展为这样.

加入路由机制后，与iOS和Android相比，原来的旧架构:

过程统一，页面流程统一. 清晰易维护.

统一处理特殊流程并减少重复工作.

加入路由机制时，结合微信支付和网络的特征对支付字段进行建模. 支付后端协议重建2.0的核心思想也围绕这种路由机制展开.

再看一次. 添加路由机制后，可以提高生产率. 以打开WebView（小程序）为例，将代码减少了近83％. 更重要的是，这里的特殊过程是在路由机制中统一处理的，不与业务代码耦合，并且是可重用的.

首先查看原始iOS在处理支付网络请求方面的缺陷:

原始付款请求是通过单例网络中心发起的，并在收到返回数据包后，通过发送通知或调用关闭消息将其回调回业务端.

会出现这样的问题:

1，CGI一对多通信问题.

以前遇到的问题的例子.

然后，由电子钱包启动的Cgi退货包裹将覆盖付款和付款页面上的数据. 以前在iOS中，只能通过修补，添加场景值和添加一些标记位来解决. 也许有一天新坑会再次出现.

1. 进入钱包页面后微信支付java开发详细，启动了Cgi

2. 然后进入付款和付款页面并启动相同的Cgi.

3. 如果以收据和付款方式发起的退货包裹最先到达

本文来自电脑杂谈，转载请注明本文网址：
http://www.pc-fly.com/a/sanxing/article-263467-1.html