微信支付的软件架构也太特么牛逼了吧…

点击上方 “程序员小乐“关注, 星标或置顶一起成长

每天凌晨00点00分, 第一时间与你相约

每日英文

Your dream is not what you find in your sleep but what makes you not sleep. 

所谓梦想，不是你睡觉时梦到了什么，而是想到了什么令你激动得没法睡觉。

每日掏心话

一切误会缘自智商的不对等。你很清楚地指出某人的问题时，她却无法理解，不是你分析得不够彻底，而是她的经历、见识和各种观念，都不足以支撑她理解更深更高层次的东西。

链接：cnblogs.com/imstudy/p/12567241.html

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

微信支付跨平台从 iOS 7.0.4 版本起， 安卓从 7.0.7 版本起全面覆盖。

线上效果指标

以 iOS 上线情况为例:

Crash 率

上线前后 Crash 率保持平稳，没有影响微信稳定性，跨平台支付无必现 Crash，做到了用户无感知切换。

举个例子，大家可以用微信发一笔红包，拉起的收银台和支付流程就是由基于 C++ 编写的跨平台代码所驱动的。

效能提升

什么是软件架构

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

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

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

为什么需要软件架构

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

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

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

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

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

1. 抽象业务流程

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

微信支付的流程多。而流程就是由一个个的界面（ViewController，Activity）和相关的业务逻辑组合而成。

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

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

举个例子：一个普通的转账流程，可能会涉及风控拦截，实名验证， 收银台， 绑卡，支付成功页等等。如果是基于  这种架构的话，很快代码会变得难以维护。

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

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

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

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

2. 加入路由机制

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

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

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

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

首先了解一下路由机制。

那么怎么建立这个支付领域模型的呢/strong>

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

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

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

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

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

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

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

3. 管理 络请求

首先看看原来 iOS 处理支付 络请求的缺陷：

那么钱包发起的 Cgi 的回包就会覆盖收付款页面的数据。之前在 iOS 只能通过修修补补，增加场景值，增加些标记位来解决。可能某一天就会又出现新的坑。

1、进入钱包页面后，发起了一个 Cgi

2、然后进入收付款页面也发起同一个 Cgi.

3、如果收付款发起的回包先到

4、然后钱包首页的回包再到。

5、CGI 生命周期问题。

2、划分职责，明确生命周期

关于 Cgi 由谁发起，之前安卓和 iOS 都没有一个统一的做法。有些人会放到 Activity，ViewController，和 UI 代码耦合起来。

因此，在跨平台软件架构中，我们统一由业务流程 UseCase 进行发起。并且生命周期是一对一的，一个 Cgi 只会有一个 UseCase 处理， UseCase 销毁后，Cgi 也随之销毁。

第一步和第二步，我们抽象了业务流程，加入了路由机制。

4. 规范数据传递

iOS 和安卓的旧架构都存在信息传递不当和数据污染问题。这个问题最严重。iOS 和 安卓都出过不少 bug。

首先我们来看看最近现 出现过的问题：

之前 iOS 出现，不少内部同事，外部的用户都在反馈：进行零钱页后，会无故弹空白框。而支付又和金钱有关，引起用户的恐慌。

支付旧的架构采用了黑板模式，虽然方便了数据读写。但是带来的问题和收益完全不成正比：

1. 存在公共读写的数据类型。

安卓传递的数据类型是一个字典，而 iOS 则是一个 Model 对象。所有的界面，业务逻辑都共用一个数据。

2. 无序的数据流动。

数据的流动是不可追溯的，数据的修改可以发生在任意使用公共数据的地方。

那么支付跨平台软件架构，为了杜绝这样的问题。我是这么做的:

那么规范数据传递后，我们软件架构就演进为这样子。

欢迎在留言区留下你的观点，一起讨论提高。如果今天的文章让你有新的启发，欢迎转发分享给更多人。欢迎加入程序员小乐技术交流群，在后台回复“加群”或者“学习”即可。

猜你还想看

阿里、腾讯、百度、华为、京东最新面试题汇集

Spring AOP调用本类方法没有生效的问题

痛心！成都一名“程序员”跳楼身亡， 友：生活压力大！

半吊子架构师，一来就想干掉RabbitMQ …

文章知识点与官方知识档案匹配，可进一步学习相关知识Java技能树首页概览91428 人正在系统学习中