支付渠道那些事 | 易学教程

年初开始对公司的支付系统进行微服务架构改造。之前有一系列文章介绍了改造的背景。

从这一篇开始，进入重构工作的正题了。在支付系统中，支付网关和支付渠道的对接是最核心的功能。其中支付网关是对外提供服务的接口，所有需要渠道支持的资金操作都需要通过网关分发到对应的渠道模块上。一旦定型，后续就很少，也很难调整。而支付渠道模块是接收网关的请求，调用渠道接口执行真正的资金操作。每个渠道的接口，传输方式都不尽相同，所以在这里，支付渠道模块的作用，类似设计模式中的wrapper，封装各个渠道的差异，对网关呈现统一的接口。而网关的功能是为业务提供通用接口，一些和渠道交互的公共操作，也会放置到网关中。

初始架构

早期启动的时候，对接的渠道不多，所有渠道和网关都实现在一个项目中，部署在一起。采用SSH架构，支付网关实现为一个大Apache Struts Action类，在我们重构前，这个类有2000多行代码。实现时提炼了一个支付渠道对接的抽象类，用来封装渠道的差异。最终在这个系统中对接了有30多个渠道，类规模达到2000个。随着业务发展，问题越来越多。高峰期同时有5个渠道在并行开发，还有大量的其他渠道对接问题需要修复。多个人同时修改一个项目代码导致版本控制的工作骤增。上线频发引起服务中断也让业务方很不满。诸多问题，在前面的文章中都有描述。

微服务架构

相对来说，支付渠道拆分微服务还是比较容易的，按照渠道来拆分即可。不过前几天拜读了大众点评支付渠道网关系统的实践之路的文章，才知道居然还有人按照服务来拆分。

按渠道拆分，指每个渠道单独部署在一个容器中，对支付网关提供相同的服务。
按服务拆分，是按接口来拆分，分为支付，对账，退款等子系统，每个服务单独部署，所有容器的服务都实现在一起。

表面上看起来没有区别，可是还是怀疑他们接的银行还是少，应该着看这篇文章支付渠道那些事。当然，大众点评折腾了一通后，最终也是调整为按照渠道来拆分系统。原因有：

银行的加密客户端会有各种奇葩的需求，有些可以支持linux，有些要windows系统，如何在一个容器中满足所有需求？
这样拆分后，每个渠道接口独立部署。某个渠道出问题也不会影响其他渠道。至于渠道访问量小导致资源浪费问题，可以通过虚机或者docker的资源调度来解决，谁也不会在物理机上玩微服务。
对接渠道难点在于对输入输出做加密和解密，以及组装和解析报文。同一个渠道对不同的服务的加密解密方式是一样的，报文格式也是一样的。按渠道来构建服务可以共用这样方法，减少开发投入。
从安全的角度，按渠道划分也有优势。一般渠道都要求只对接到特定ip的机器，这样每个渠道对接系统所在的机器仅开放对渠道和支付网关前置机的访问白名单即可，尽可能的缩减被暴露的风险。

这样整体软件架构如下所示：

支付网关前置

支付网关前置是对接业务系统的模块。它是所有支付功能的集成前置，将不同支付渠道提供的接口通过统一的方式呈现给业务方。支付网关前置的设计对整个支付系统的稳定性、功能、性能以及其他非功能性需求有着直接的影响。

支付网关前置应保持稳定，尽量减少系统重启等操作对业务方的影响。为此，我们在支付网关前置前端增加Nginx的LBS网关，专门用于请求转发。当服务器需要重启时，首先从LBS中摘取，重启后再挂接上。
支付网关前置的性能问题，通过各个后续尽量异步化来处理。主流程仅保留记录流水、执行风控、调用支付路由、调用支付渠道服务，其他操作都异步化处理。
接口的安全性问题，包括通道安全和防篡改机制。通道安全通过HTTPS/SSL来保证，防篡改则通过接口参数签名来处理。现在主流的签名是对接口参数按照参数名称排序后，做加密和散列，参考微信的签名规范。

交易流水和记账

每一笔交易都需要记录流水，并登记到个人和机构的分户账户上，统计和分析也需要根据交易流水来更新相关数据。而个人和机构账户总额更新、交易流水记录以及库存的处理，更是需要事务处理机制的支持。从性能角度，我们弱化了事务处理的要求，采用消息机制来异步化和交易相关的数据处理。

在支付网关前置的主流程中，仅记录交易流水，即将当前的请求保存到数据库中。
完成数据记录后，发送MQ出来，记账、统计、分析，都是接收MQ来完成数据处理。
涉及到本地资金支付，比如钱包支付，会需要分布式事务处理，扣减账号余额，记账，扣减库存等，每个操作失败，都要回滚。阿里有很不错的分享，这里不详细描述。
当交易量上来后，需要考虑交易表的分表分库的事情。分表分库有两个策略，按照流水号或者交易主体id来走。后者可以支持按用户来获取交易记录。我们用的是前者。后者可以走elastic，确保数据库专用。风控，信用和统计所需要的数据，通过MQ同步到Hbase里面。作为支付系统最有价值的数据，在存储上做到专库专用，无可厚非，毕竟存储成本还是廉价的。

风控模块

风控对支付的重要性怎么强调都不过分。有些系统在风控出问题时可以旁路风控，但是在支付系统中，风控出问题必须停止交易。整体上，风控可以分为数据采集，数据分析，实时计算，规则配置，实时拦截等模块。风控本身是个大话题，以后专门讨论。又欠一个债。但风控和交易的接口比较简单。对每一次交易，风控一般返回四个结果:拦截，增强验证，人工核实和通过。通过指交易没有问题，可以直接放行。拦截则是阻止本次交易。增强验证则是交易存疑，需要用户进一步核实身份才能继续，比如输入手机号或者身份证号，一般用于身份被盗用的场景。而人工核实则是对交易有疑问，一般用于个人恶意消费满场景。

支付路由

支付路由是一个复杂的话题。对支付系统来说，能支持的支付方式越多越好，不能由于支付方式的不支持断了财路。现实中的支付方式多得难以置信。用户随时甩出一张你听都没听说过的卡。如果一个银行卡只有几个用户在用，那针对这个卡开发个对接有点得不尝失。现在第三方支付的爆发，确实给开发支付系统省了不少事。但是公司不可能只对接一个第三方支付，如果这个渠道出问题了，或者闹矛盾了，把链接给掐了，老板还不欲哭无泪。总之，得对接多个渠道。对于交易量大的银行，还得考虑直联。支付路由的作用是定义对用户选用的银行卡或者其他支付方式，使用什么渠道来完成支付。一般来说，银行会提供两种支付途径：无跳转的快捷支付接口和带跳转的网银接口。前者在绑卡，支付的时候，不需要跳到银行页面上去处理，后者则需要在银行的网银页面上完成。显然前者对用户来说体验要好多了，用户流程不会被打断。快捷支付要求支付系统在本地保存用户的支付信息，如卡号，登记手机。系统要确保这些信息不被泄漏。风险非常好，所以大部分银行要求接入方必须经过ADSS检验才能够接入快捷支付。这种固定方式的接入有单点故障的问题，一旦某个渠道出问题，绑定的支付方式就无法使用。改进策略是为每个支付方式定义多个渠道，第一个渠道出问题即选择第二个，以此类推。当然，更进一步，可以为候选渠道定义权重，按照权重来选择支付方式。当渠道出问题，自动调整权重。路由实现上还会更复杂，对同一张银行卡，运营上会要求在不同的系统上，比如android，iOS，windows上，或者不同地区，如大陆，台湾，香港，北美等，甚至不同业务上，采用不同渠道来支付。

支付渠道

对于支付渠道，首先考虑的是接入哪些渠道。要对接的渠道按优先级有： - 第三方支付，对大部分应用来说，支付宝和微信支付都是必须的，一般来说，这两者可以占到90%以上的交易量。用户不需要绑卡，授权后直接支付就行。各种平台都支持，性能和稳定性都不错。对于一些特殊业务，比如游戏，企业支付，可以查看一些专用的第三方支付平台。

银联，这货的存在，极大方便了和银行的对接。和第三方支付主要不同在两个地方一是需要绑卡，也就是用户先把卡号，手机，身份证号提供出来。这一步会折损不少用户。绑卡后，以后的支付操作就简单了，用户只需要输入密码就行。手机客户端不需要像第三方支付那样安装SDK，都在服务器端完成。当然，这是针对快捷支付。网银支付还是挺麻烦的。银联接入也需要ADSS认证。
银行，建议先看这一篇文章，了解下对接银行的难度。那最终需要选择哪些银行？先看个统计数据。截至 2015 年底，我国银行业金融机构包括 5 家大型商业银行、12 家股份制商业银行、133 家城市商业银行、5 家民营银行、859 家农村商业银行、71 家农村合作银行、1373家农村信用社、1 家邮政储蓄银行、3 家政策性银行、 311 家村镇银行、48 家农村资金互助社。优先选择5家商业银行，他们占40%的交易量。其次是股份制银行和邮储。这就18家银行了。老板要是不满意，城商行和农商行加起来有1000多家呢。一般对接一个银行预计有3周左右的工作量，大部分银行需要专线接入，费用和带宽有关，一年也得几万费用。不同银行对接入环境有不同要求，这也是成本。另外，还有一个重大风险，就是央行在搞得网联系统，毕竟还没有出来，相关资料参考知乎上关于网联的一篇讨论。
手机支付，现在不少厂商都内置了各种支付，比如苹果的In-App支付，三星支付、华为支付等，这些支付仅针对特定的手机型号，支持NFC等，根据业务需要也可以接入。就是目前用户群不大，收益不明显。
话费支付，这一块容易被人忽略，但考虑到国内不少职场人士，话费是公司报销的，每个月多的用不完，所以这块支付还是相当有市场的。问题是，联通和移动两大运营商，不仅接口不能互通，内部各个地域也是各自为政，所以对接起来还是有点麻烦。不过话费支付领域也有类似支付宝微信的第三方支付公司，比如虹软、联动优势等公司。