标签：图片 技术债务 价值 c++编写 过程 角色 金钱 软件架构 作者
点点这个链接免费获取：本人免费整理了Java高级资料，涵盖了Java、Redis、MongoDB、MySQL、Zookeeper、Spring Cloud、Dubbo高并发分布式等教程，一共30G，需要自己领取。
传送门：https://mp.weixin.qq.com/s/osB-BOl6W-ZLTSttTkqMPQ
作为一个重要业务，微信支付在客户端上面临着各种问题。其中最核心问题就是分平台实现导致的问题：
为了解决分平台实现这个核心问题，并解决以往的技术债务。我们建立起了一整套基于 C++ 的跨平台框架，并对核心支付流程进行了重构。
微信支付跨平台从 iOS 7.0.4 版本起， 安卓从 7.0.7 版本起全面覆盖。
以 iOS 上线情况为例:
那么支付跨平台软件架构怎么样有效进行质量保障，并且提升生产力呢？这是这篇文章的主要内容。
什么是软件架构？正如 Ivar Jacobson （UML 之父）说过的一样，找五个人来回答这个问题，五个人可能都有各自不同的答案。
架构定义可以有很多种说法，从代码规范到发布流程都可以是架构的一部分。
针对微信支付的业务特点，这里对架构的定义是：架构是系统的组成部件及其之间的相互关系（通讯方式）。这更符合我们程序员日常编写业务代码时对架构的理解。也就是通俗意义上讲的 MVC，MVVM 等。
早在 1986 年的时候，人月神话的作者在讨论软件的复杂性时，谈到：软件的本质复杂性存在于复杂的业务需求中。
而管理复杂性，最根本的手段就是职责分离。为了实现职责分离，代码重用，架构慢慢地复现出来。架构的本质是管理复杂性。
没有架构，我们所有的代码都耦合在一起，人类的心智模型不擅长处理这种复杂性，架构的设立，和图书馆的图书分类，公司的组织划分等，本质都是一样的。是为了管理复杂性，以取得更高的生产力。
在移动客户端领域，业界基于 C++ 来编写业务代码，并没有成熟的架构。即使使用 C++ 编写业务逻辑，但都不涉及 UI，不涉及界面的跳转流程。
既然业界没有一个成熟的架构可借鉴，那么是不是直接把业界通用的架构简单套用一下就好？
现在业界通用的有 MVC , MVP, MVVM 。这些大家都熟悉的软件架构。但是这些软件架构都存在一个问题： 那就是没有处理好业务流程， 界面转场。
微信支付的流程多。而流程就是由一个个的界面（ViewController，Activity）和相关的业务逻辑组合而成。
上面的 MV(X) 模式忽略了一个非常重要的一点，那就是业务流程，界面的转场究竟由谁负责。也即 ViewController 与 ViewController 之间的关系由谁维护，业务流程的逻辑写在哪里。如果还按照传统的 MVC 模式，那么 ViewController 自己负责和不同的 ViewController 通讯。那么 ViewController 得不到复用，更致命的是业务流程的代码非常不清晰，业务流程的代码都被分散到各个 Controller 中， 而一个 Controller 又可能耦合了多个业务的代码。
举个例子：一个普通的转账流程，可能会涉及风控拦截，实名验证， 收银台， 绑卡，支付成功页等等。如果是基于 MVC 这种架构的话，很快代码会变得难以维护。
因此，为了适应微信支付流程多，界面跳转复杂的特点。架构抽象的第一步就是将业务流程抽象为一个独立的角色 UseCase。同时, 把界面抽象为 UIPage。 一个大的业务流程可以分解为一个个小的业务流程。
和刚才基于 MVC 混乱的架构相比：
既然流程得到了抽象，这个时候需要针对业务流程做更深的思考。在开发支付业务流程时，开发者不可绕过的问题有：
这些问题，引导我想到，微信支付需要一个路由机制。
首先了解一下路由机制。
路由机制的核心思想，就是通过向路由传递数据，然后路由解析数据，并响应。
结合微信支付和网络密切相关的特点。创新地将支付领域模型作为传递的数据。
那么怎么建立这个支付领域模型的呢？
建模，就是建立映射。领域知识 + 建模方法 = 领域建模。那么这里的领域知识，就是对支付业务流程的理解。建模方法，我采用了 UML 建模。最终会落地为 Proto 协议供客户端和后台一起使用。
首先，微信支付业务特点就是和网络密切相关，流程和页面往往是由 Cgi 串联起来。因此建立模型时，最外层便是网络回包。对于路由机制，这里我们只关心路由数据模型。
路由数据模型由 路由类型，还有各个路由类型所需要的信息组合成。
路由类型清晰的定义了要触发的行为。究竟是要开启一个 UseCase，还是要打开一个界面，或者 网页，小程序，弹窗等等。
然后就是这些行为所需要的数据。比如打开小程序所需要的参数，弹窗所需要的参数等。
建立支付领域模型后，我们路由的解析就变得非常清晰了。路由解析之后，会根据路由类型，触发不同的动作。
比如流程，界面流转，会交给 UseCase 处理。
而特殊流程，比如打开小程序，打开 webview, 弹窗这些行为会统一进行处理。
我们在第一步把业务流程抽象为 UseCase。第二步则加入了路由机制。
加入路由机制后，支付跨平台的软件架构演进为这个样子。
加入路由机制后，对比 iOS，安卓原来的旧架构:
再来看一下，加入路由机制后，对生产力的提升。以支付流程打开 WebView, 小程序为例，减少将近 83% 的代码。更重要的是，这里的特殊流程，是在路由机制里面统一处理的，没有耦合到业务代码中，并且是可复用的。
首先看看原来 iOS 处理支付网络请求的缺陷：
原来支付的请求，都是通过一个单例网络中心去发起请求，然后收到回包后，通过抛通知，或者调用闭包的方式回调给业务侧。
会存在这样的问题：
解决方案：
对比旧架构：
第一步和第二步，我们抽象了业务流程，加入了路由机制。
在第三步管理网络请求后。我们的软件架构演进为这样子。
iOS 和安卓的旧架构都存在信息传递不当和数据污染问题。这个问题最严重。iOS 和 安卓都出过不少 bug。
首先我们来看看最近现网出现过的问题：
之前 iOS 出现，不少内部同事，外部的用户都在反馈：进行零钱页后，会无故弹空白框。而支付又和金钱有关，引起用户的恐慌。
具体原因就是:
除此之外，之前还有有很多发生在安卓，iOS ，像钱包页零钱展示错误。付款的时候。银行卡失效等等问题。
这些问题五花八门，看起来发生的地方，场景都不一样。每次遇到这类问题的时候，就只能去修修补补。
但是深究下去，会发现真正的原因，是软件架构上存在的问题：
支付旧的架构采用了黑板模式，虽然方便了数据读写。但是带来的问题和收益完全不成正比：
那么支付跨平台软件架构，为了杜绝这样的问题。我是这么做的:
规范数据传递后。对比旧架构:
前面三步，我们抽象了业务流程，加入了路由机制，统一管理网络请求。
那么规范数据传递后，我们软件架构就演进为这样子。
软件的本质复杂性存在于复杂的业务需求中。而软件架构的本质就是管理复杂性，因此真正的好的架构，正是在复杂的业务需求中反复提炼和总结归纳而来，解决了真正的业务问题，不是空谈。
软件架构除了清理历史旧架构的缺陷，是我们业务开发的基石之外。还能够赋能业务，为业务带来价值。在建立软件架构的基础上，还围绕着软件架构建立起微信支付的跨平台自动化数据上报机制，防重复支付，安全横切等带来巨大业务收益的能力。有机会的话，后面也会进一步编写相关文章和大家交流探讨。
架构是一个不断演进的过程，随着新的支付业务基于跨平台软件架构的不断编写， 我也会对这个架构进行持续的更新迭代。让这个软件架构更贴合微信支付，更加健壮和完整。
标签：图片 技术债务 价值 c++编写 过程 角色 金钱 软件架构 作者
原文地址：https://www.cnblogs.com/yunxi520/p/12608054.html
