「Java技术架构TB」这也太厉害了,微信支付软件架构

作者:JackJiang
背景
作为一个重要业务 , 微信支付在客户端上面临着各种问题 。 其中最核心问题就是分平台实现导致的问题:
iOS和安卓实现不一致
容易出Bug
通过沟通保证不了质量
扩展性差 , 无法快速响应业务需求
需求变更迭代周期长
数据上报不全面
质量保障体系不完善
缺少业务及设计知识沉淀
协议管理松散
缺少统一的自动化测试
用户体验不一致
比如下图就是之前安卓和iOS没有统一前的收银台 。
「Java技术架构TB」这也太厉害了,微信支付软件架构
文章图片
为了解决分平台实现这个核心问题 , 并解决以往的技术债务 。 我们建立起了一整套基于C++的跨平台框架 , 并对核心支付流程进行了重构 。
微信支付跨平台从iOS7.0.4版本起 , 安卓从7.0.7版本起全面覆盖 。
线上效果指标
以iOS上线情况为例:
Crash率
上线前后Crash率保持平稳 , 没有影响微信稳定性 , 跨平台支付无必现Crash , 做到了用户无感知切换 。
举个例子 , 大家可以用微信发一笔红包 , 拉起的收银台和支付流程就是由基于C++编写的跨平台代码所驱动的 。
效能提升
「Java技术架构TB」这也太厉害了,微信支付软件架构
文章图片
以核心支付流程代码为例 , 跨平台需要3512行 , iOS原生需要6328行 。 减少了近45%的代码 。
以新需求开发为例:
7.0.4版本需求一:收银台改版
7.0.4版本需求二:简化版本收银台
跨平台实现:iOS+安卓共计3人日 , 在封板时间前完成
原生实现:iOS , 安卓封板时间后一周才基本完成
跨平台实现:iOS+安卓共计5人日 , 在封板时间前完成
原生实现:iOS , 安卓封板时间后一周才基本完成
那么支付跨平台软件架构怎么样有效进行质量保障 , 并且提升生产力呢?这是这篇文章的主要内容 。
「Java技术架构TB」这也太厉害了,微信支付软件架构
文章图片
什么是软件架构
什么是软件架构?正如IvarJacobson(UML之父)说过的一样 , 找五个人来回答这个问题 , 五个人可能都有各自不同的答案 。
架构定义可以有很多种说法 , 从代码规范到发布流程都可以是架构的一部分 。
针对微信支付的业务特点 , 这里对架构的定义是:架构是系统的组成部件及其之间的相互关系(通讯方式) 。 这更符合我们程序员日常编写业务代码时对架构的理解 。 也就是通俗意义上讲的MVC , MVVM等 。
为什么需要软件架构
早在1986年的时候 , 人月神话的作者在讨论软件的复杂性时 , 谈到:软件的本质复杂性存在于复杂的业务需求中 。
而管理复杂性 , 最根本的手段就是职责分离 。 为了实现职责分离 , 代码重用 , 架构慢慢地复现出来 。 架构的本质是管理复杂性 。
没有架构 , 我们所有的代码都耦合在一起 , 人类的心智模型不擅长处理这种复杂性 , 架构的设立 , 和图书馆的图书分类 , 公司的组织划分等 , 本质都是一样的 。 是为了管理复杂性 , 以取得更高的生产力 。
从零到一构建支付跨平台软件架构
在移动客户端领域 , 业界基于C++来编写业务代码 , 并没有成熟的架构 。 即使使用C++编写业务逻辑 , 但都不涉及UI , 不涉及界面的跳转流程 。
既然业界没有一个成熟的架构可借鉴 , 那么是不是直接把业界通用的架构简单套用一下就好?
1.抽象业务流程
现在业界通用的有MVC,MVP,MVVM 。 这些大家都熟悉的软件架构 。 但是这些软件架构都存在一个问题:那就是没有处理好业务流程 , 界面转场 。
微信支付的流程多 。 而流程就是由一个个的界面(ViewController , Activity)和相关的业务逻辑组合而成 。


推荐阅读