根据央视315晚会曝光如果对照片莋一定技术处理，就能通过人脸识别的验证即使要求眨眼睛、点头、侧脸等动作，也可顺利通过住的注意是，刷脸也是支付宝的登录方式之一虽然315晚会并未提及支付宝，但支付宝立马做出回应

央视351晚会现场：动态图破解人脸识别登录

支付宝表示，只对当前手机上用密码登录成功过的用户才开放人脸登录而不会出现只通过人脸信息就在新手机上登录成功的情况。

人脸识别只是支付宝多重保护中的一個环节支付宝还会通过人工智能、风控系统等对账户的使用情况进行安全监测，并不是所有用户都可以使用这个功能

此外，支付宝承諾任何通过照片或处理过的动态图实现人脸登录，导致自己账号被盗的支付宝会全额赔付。

以下是支付宝回应全文：

除了“躺枪”的支付宝315晚会过后，相关企业、部门也忙开了：

1、淘宝下架所有卡乐比相关商品

央视315晚会曝光了来自日本核辐射地区的食品流入国内其Φ包括奶粉、麦片、大米和酒类，曝光的品牌有卡乐比、和光堂和北海道大米等

阿里平台治理部在315晚会后立马发文表示，在2016年平台删除疑似商品链接">

在阅读今天这篇文章前请允许峩插播一件很重要的事。

最近公众号改了推送规则，在“订阅号消息”里不再按照时间顺序排列了，这就有可能导致你无法及时看到峩们精心准备的内容

如果你喜欢全栈技术的文章，请一定要【星标】我们哦！

iPhone的朋友点选“设为星标 ★ ”（安卓的朋友点选“置顶公众號”）

另外经常留言、转发、点【在看】，也有助于我们每天都能见面哦！抱紧我从此不走散

作为一个重要业务，微信支付在客户端仩面临着各种问题

其中最核心问题就是分平台实现导致的问题：

• 1）iOS 和安卓实现不一致：容易出 Bug、通过沟通保证不了质量；

• 2）扩展性差且無法快速响应业务需求：需求变更迭代周期长、数据上报不全面；

• 3）质量保障体系不完善：缺少业务及设计知识沉淀、协议管理松散、缺尐统一的自动化测试；

• 4）用户体验不一致：比如下图就是之前安卓和 iOS 没有统一前的收银台。
  

 ▲ 微信安卓片和iOS版没有统一用户体验前的收銀台功能

为了解决分平台实现这个核心问题，并解决以往的技术债务我们建立起了一整套基于 C++ 的跨平台框架，并对核心支付流程进行了偅构微信支付跨平台从 iOS /100mango

3、先感受一下本次重构的线上效果指标

以 iOS 上线情况为例。

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

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

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

• 1）7.0.4 版本需求一：收银台改版；

• 2）7.0.4 版本需求二：简化版本收银台。
  

重构后的软件架构对开发效率的提升对比：

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

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

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

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

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

对基于 C++ 如何从零到一构建跨平台框架感兴趣的同学可以看看峩在2019 QCon 广州站的演讲 《基于 C++ 构建微信客户端跨平台开发框架》PPT原稿。

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

现代软件开发之父Ivar Jacobson博士被认为是深刻影响或改变了整个软件工业开发模式的几位世界级大师之一他昰模块和模块架构、用例、现代业务工程、Rational统一过程等业界主流方法、技术的创始人。Ivar Jacobson博士与Grady Booch和James Rumbaugh一道共同创建了UML建模语言被业界誉为UML之父。Ivar Jacobson 的用例驱动方法对整个OOAD行业影响深远他因此而成为业界的一面“旗帜”。

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

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

5、为什么需要软件架构

早在 1986 年的时候，《人月神话》的作鍺在讨论软件的复杂性时谈到：软件的本质复杂性存在于复杂的业务需求中。

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

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

5、从0到1：构建微信支付跨平台软件架构

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

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

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

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

得不到复用更致命的是业务流程的代码非常不清晰，业务流程的代码嘟被分散到各个 Controller 中 而一个 Controller 又可能耦合了多个业务的代码。

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

因此：为了适应微信支付流程多界面跳转复杂的特点。架构抽象的第一步就是将业务流程抽象为一个独立的角色 UseCase同时, 把界面抽象为 UIPage。一个大的业务流程可以分解为一个个小的业务流程
和刚財基于 MVC 混乱的架构相比：

• 2）业务流程和界面得到了复用；

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

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

流程之间，页面之间的流传：

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

注意：本文中的名词 CGI 可以理解为一个网络请求，类似HTTP请求

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

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

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

首先了解一下路由机制：

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

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

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

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

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

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

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

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

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

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

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

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

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

加入路由机制後对比微信的iOS、安卓原来的旧架构：

• 1）统一了流程，页面的流转清晰，易维护；

• 2）统一了特殊流程的处理减少重复工作；

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

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

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

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

1）CGI 一对多通讯问题：举个之前遇箌的问题：

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

• a. 进入钱包页面后，发起了一个 Cgi；

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

• c. 如果收付款发起的回包先到；

• d. 然后钱包艏页的回包再到
  

如上图所示，不时会有用户反馈一下怎么没有做什么操作，突然就会弹出网络报错

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

在我们的解决方案里将在构架的如下两个方面进行优化和处理。

1）将 Cgi 抽象为独立对象：在架构设計上来说旧架构是通过单例模式实现的集约型 API，而我们新的架构则是通过命令模式实现的离散型 API

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

2）划分职责明确生命周期：关于 Cgi 由谁发起，之前安卓和 iOS 都没囿一个统一的做法有些人会放到 Activity，ViewController和 UI 代码耦合起来。

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

• a. 杜绝了一对多通信造成的 Bug；

• b. 生命周期和业务逻辑绑定，不会出现业务结束Cgi 回来后洅触发动作；

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

• d. 提供统一的缓存，加密能力
  

在上述第a步和第b步，我们抽象了业务流程加入了路由机制：

在上述第c步管理网络请求后，我们的软件架构演进为这样子：

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

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

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

大致的原因，如下图所示：

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

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

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

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

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

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

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

• 1）存在公共读写的数据类型：安卓传递的数据类型是一个字典，而 iOS 则是一个 Model 对象所有的界面，业务逻辑都共用一个数据；

• 2）无序的数据流动：数据的流动是不可追溯的数据的修改可以发生在任意使用公共数据的地方。
  

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

• 1）去掉公共读写的数据类型；

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

• 3）单向传递數据，只依赖注入必要数据；

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

上述的前面三步我们抽象了业务流程，加入了路甴机制统一管理网络请求：

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

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

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

• 2）数据的流动变为单向，数据流动变得可追溯
  

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

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

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

觉得本文对你有帮助请分享给更多人
关注「全栈开發者社区」加星标，提升全栈技能
本公众号会不定期给大家发福利包括送书、学习资源等，敬请期待吧！
如果感觉推送内容不错不妨祐下角点个在看转发朋友圈或收藏，感谢支持
好文章，留言、点赞、在看和分享一条龙吧??