来自微信官方：微信支付跨平台软件架构首次曝光

大纲

• 背景

• 线上效果指标

• 什么是软件架构

• 为什么需要软件架构

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

  1.抽象业务流程

  2.加入路由机制

  3.管理网络请求

  4.规范数据传递

• 总结

背景

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

1. iOS 和安卓实现不一致

• 容易出 Bug

• 通过沟通保证不了质量

• 扩展性差&＃xff0c;无法快速响应业务需求

• • 需求变更迭代周期长

  • 数据上报不全面

• 质量保障体系不完善

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

  • 协议管理松散

  • 缺少统一的自动化测试

• 用户体验不一致

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

  

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

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

  线上效果指标

  以 iOS 上线情况为例:

  1. Crash 率

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

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

  2. 效能提升

     
     

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

     以新需求开发为例&＃xff1a;

     7.0.4 版本需求一&＃xff1a;收银台改版

     7.0.4 版本需求二&＃xff1a;简化版本收银台

  • 跨平台实现&＃xff1a;iOS &＃43; 安卓 共计 3 人日&＃xff0c;在封板时间前完成

  • 原生实现&＃xff1a;iOS&＃xff0c; 安卓封板时间后一周才基本完成

  • 跨平台实现&＃xff1a;iOS &＃43; 安卓共计 5 人日&＃xff0c;在封板时间前完成

  • 原生实现&＃xff1a;iOS&＃xff0c; 安卓封板时间后一周才基本完成

  那么支付跨平台软件架构怎么样有效进行质量保障&＃xff0c;并且提升生产力呢&＃xff1f;这是这篇文章的主要内容。在公众号互联网架构师后台回复&＃xff1a;2T&＃xff0c;可以获取架构师视频整套系统教程。

  

  对基于 C&＃43;&＃43; 如何从零到一构建跨平台框架感兴趣的同学&＃xff0c;可以在 https://github.com/100mango/zen/blob/master/Qcon2019/%E5%9F%BA%E4%BA%8E%20C%2B%2B%20%E6%9E%84%E5%BB%BA%E5%BE%AE%E4%BF%A1%E5%AE%A2%E6%88%B7%E7%AB%AF%E8%B7%A8%E5%B9%B3%E5%8F%B0%E5%BC%80%E5%8F%91%E6%A1%86%E6%9E%B6.key 下载我在 2019 QCon 广州站的演讲 《基于 C&＃43;&＃43; 构建微信客户端跨平台开发框架》的 Keynote.

  什么是软件架构

  什么是软件架构&＃xff1f;正如 Ivar Jacobson &＃xff08;UML 之父&＃xff09;说过的一样&＃xff0c;找五个人来回答这个问题&＃xff0c;五个人可能都有各自不同的答案。

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

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

  为什么需要软件架构

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

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

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

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

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

  既然业界没有一个成熟的架构可借鉴&＃xff0c;那么是不是直接把业界通用的架构简单套用一下就好&＃xff1f;

  1. 抽象业务流程

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

  微信支付的流程多。而流程就是由一个个的界面&＃xff08;ViewController&＃xff0c;Activity&＃xff09;和相关的业务逻辑组合而成。

  上面的 MV(X) 模式忽略了一个非常重要的一点&＃xff0c;那就是业务流程&＃xff0c;界面的转场究竟由谁负责。也即 ViewController 与 ViewController 之间的关系由谁维护&＃xff0c;业务流程的逻辑写在哪里。如果还按照传统的 MVC 模式&＃xff0c;那么 ViewController 自己负责和不同的 ViewController 通讯。那么 ViewController 得不到复用&＃xff0c;更致命的是业务流程的代码非常不清晰&＃xff0c;业务流程的代码都被分散到各个 Controller 中&＃xff0c; 而一个 Controller 又可能耦合了多个业务的代码。在公众号互联网架构师后台回复&＃xff1a;2T&＃xff0c;可以获取架构师视频整套系统教程。

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

  

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

  

  和刚才基于 MVC 混乱的架构相比&＃xff1a;

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

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

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

  2. 加入路由机制

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

  1. 流程之间&＃xff0c;页面之间的流传。

     

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

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

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

  2. 特殊流程的处理

     

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

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

  首先了解一下路由机制。

  

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

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

  

  那么怎么建立这个支付领域模型的呢&＃xff1f;
  

  建模&＃xff0c;就是建立映射。领域知识 &＃43; 建模方法 &＃61; 领域建模。那么这里的领域知识&＃xff0c;就是对支付业务流程的理解。建模方法&＃xff0c;我采用了 UML 建模。最终会落地为 Proto 协议供客户端和后台一起使用。在公众号互联网架构师后台回复&＃xff1a;2T&＃xff0c;可以获取架构师视频整套系统教程。

  

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

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

  路由类型清晰的定义了要触发的行为。究竟是要开启一个 UseCase&＃xff0c;还是要打开一个界面&＃xff0c;或者 网页&＃xff0c;小程序&＃xff0c;弹窗等等。在公众号互联网架构师后台回复&＃xff1a;2T&＃xff0c;可以获取架构师视频整套系统教程。

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

  

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

  比如流程&＃xff0c;界面流转&＃xff0c;会交给 UseCase 处理。

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

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

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

  

  加入路由机制后&＃xff0c;对比 iOS&＃xff0c;安卓原来的旧架构:
  

  1. 统一了流程&＃xff0c;页面的流转。清晰&＃xff0c;易维护。

  2. 统一了特殊流程的处理&＃xff0c;减少重复工作。

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

  

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

  3. 管理网络请求

  首先看看原来 iOS 处理支付网络请求的缺陷&＃xff1a;

  

  原来支付的请求&＃xff0c;都是通过一个单例网络中心去发起请求&＃xff0c;然后收到回包后&＃xff0c;通过抛通知&＃xff0c;或者调用闭包的方式回调给业务侧。在公众号互联网架构师后台回复&＃xff1a;2T&＃xff0c;可以获取架构师视频整套系统教程。

  会存在这样的问题&＃xff1a;

  1. CGI 一对多通讯问题。

     举个之前遇到的问题。

     
     

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

  2. 1. 进入钱包页面后&＃xff0c;发起了一个 Cgi

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

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

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

  3. CGI 生命周期问题。

     

     不时会有用户反馈一下&＃xff0c;怎么没有做什么操作&＃xff0c;突然就会弹出网络报错。

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

  解决方案&＃xff1a;

  1. 将 Cgi 抽象为独立对象

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

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

     

  2. 划分职责&＃xff0c;明确生命周期

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

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

  

  对比旧架构&＃xff1a;
  

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

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

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

  4. 提供统一的缓存&＃xff0c;加密能力。

  

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

  

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

  

  4. 规范数据传递
  

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

  首先我们来看看最近现网出现过的问题&＃xff1a;

  之前 iOS 出现&＃xff0c;不少内部同事&＃xff0c;外部的用户都在反馈&＃xff1a;进行零钱页后&＃xff0c;会无故弹空白框。而支付又和金钱有关&＃xff0c;引起用户的恐慌。在公众号互联网架构师后台回复&＃xff1a;2T&＃xff0c;可以获取架构师视频整套系统教程。

  

  具体原因就是:

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

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

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

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

  这些问题五花八门&＃xff0c;看起来发生的地方&＃xff0c;场景都不一样。每次遇到这类问题的时候&＃xff0c;就只能去修修补补。在公众号互联网架构师后台回复&＃xff1a;8&＃xff0c;可以获取架构师视频整套系统教程。

  但是深究下去&＃xff0c;会发现真正的原因&＃xff0c;是软件架构上存在的问题&＃xff1a;

  

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

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

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

  2. 无序的数据流动。

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

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

  

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

  2. 传递值类型&＃xff08;Value Type&＃xff09;的数据, 后面流程修改数据时&＃xff0c;不影响前面的流程。

  3. 单向传递数据&＃xff0c;只依赖注入必要数据。

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

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

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

  2. 数据的流动变为单向&＃xff0c;数据流动变得可追溯。

  前面三步&＃xff0c;我们抽象了业务流程&＃xff0c;加入了路由机制&＃xff0c;统一管理网络请求。在公众号互联网架构师后台回复&＃xff1a;2T&＃xff0c;可以获取架构师视频整套系统教程。

  

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

  

  总结
  

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

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

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

  对基于 C&＃43;&＃43; 如何从零到一构建跨平台框架感兴趣的同学&＃xff0c;可以在 https://github.com/100mango/zen/blob/master/Qcon2019/%E5%9F%BA%E4%BA%8E%20C%2B%2B%20%E6%9E%84%E5%BB%BA%E5%BE%AE%E4%BF%A1%E5%AE%A2%E6%88%B7%E7%AB%AF%E8%B7%A8%E5%B9%B3%E5%8F%B0%E5%BC%80%E5%8F%91%E6%A1%86%E6%9E%B6.key 下载我在 2019 QCon 广州站的演讲 《基于 C&＃43;&＃43; 构建微信客户端跨平台开发框架》的 Keynote。这也是一个可以展开很多来讲的话题&＃xff0c;欢迎探讨和交流。

  猜你喜欢

  1、GitHub 标星 3.2w&＃xff01;史上最全技术人员面试手册&＃xff01;FackBoo发起和总结

  2、如何才能成为优秀的架构师&＃xff1f;

  3、从零开始搭建创业公司后台技术栈

  4、程序员一般可以从什么平台接私活&＃xff1f;

  5、37岁程序员被裁&＃xff0c;120天没找到工作&＃xff0c;无奈去小公司&＃xff0c;结果懵了...

  6、滴滴业务中台构建实践&＃xff0c;首次曝光

  7、不认命&＃xff0c;从10年流水线工人&＃xff0c;到谷歌上班的程序媛&＃xff0c;一位湖南妹子的励志故事

  8、15张图看懂瞎忙和高效的区别