一、分享主题：有赞支付的整体概况

大家好，先简单自我介绍下，我是东北人，2011年工作加入支付宝，开始做前端，后来逐步对服务端感兴趣就转了行。之后加入有赞从事支付平台建设相关工作，本次主要分享有赞支付的整体概况，可能涉及部分内容不方便展开分享与讨论，请大家见谅。

今天分享的主要内容有：

1.1 有赞公司介绍

首先简单介绍一下有赞，有赞是一个商家服务公司，我们通过产品和服务，帮助互联网时代的生意人管店、管货、管客、管钱，让生意更好做。我们致力于成为商家服务领域里最被信任的引领者，希望持续作为一个”开心”（enjoy）的组织，公司网站：https://www.youzan.com/

有赞支付是有赞众多产品中的一种，有关有赞整体产品群大致如下图所示：

1.2 发展历程

下面介绍一下有赞支付的发展历程

有赞和绝大多数互联网公司类似，都经历了系统开发语言从PHP过度JAVA这过程，从烟囱架构到SOA服务化架构。在服务化过程中需要分步骤一点一点进行，这里会被各种技术负债，遗留问题，业务压力的困扰。

我们首先建立了收单支付，账务核心系统，之后逐步丰富支付整体架构。

下面介绍一下有赞支付目前的产品架构，如下图所示：

对于图中的几个模块，我这里介绍一下，可能和其他公司的支付架构或模板稍有差异。

·       业务平台： 收单业务，卡券业务等。

·       开放平台： 开放平台主要负责对外输出/开放支付能力。对外提供/输出方式目前有：API，H5，SDK。里面包含开放网关和收银台功能。收银台中包含支付列表获取、支付决策等。

·       资产交换： 资产流水创建，资产指令编排，资产状态一致性保证，状态回调等。

·       支付工具： 包含营销类、资产类等支付工具，银行卡是一种特殊的支付工具，通过调用渠道进行处理。

·       管理平台： 商户管理、客户管理、商户交易记录、产品套餐、认证等。

·       对账： 内部对账、渠道对账等。

其他模块应该都比较类似，在此就不一一展开进行介绍了。

1.3 技术架构

下面介绍一下有赞支付的整体技术架构：

其中rds-proxy是基于cobar进行开发的数据库中间件。rpc框架使用业务较为通用的dubbo，注册中心服务发现最开始使用的是zk，现在逐步切换到etcd，Zanphp是有赞自己开发的开源的PHP框架。

Nova协议有赞自己基于开源框架二次开发的框架，解决PHP->JAVA之间的rpc通信问题。

第一个需要介绍的是统一业务上下文。先说下背景：SOA化系统职责划分明确，也会导致服务粒度较细，长久发展之后会各自发展出一套自己的业务协议，服务调用逐层转化，系统之后整体串接性较差，维护困难等。

我们经过一些归纳梳理，设计了符合有赞业务发展的一个统一业务上下文语言——”四码一号” 四码一号是一串20位的数字。

·       产品码： 定义了一个具体的产品标志。比如有赞微商城多人拼团产品，可以定义一个产品码。

·       业务模式码： 该产品下的业务模式，比如担保交易，即时到账等。 业务动作码。体现了具体的资产调度模式。比如：支付、退款、充值、提现等。

·       支付通道码： 标识一个具体的渠道api，比如：微信公众号支付、储蓄卡支付等。

·       渠道号： 标识一种支付api的多种实现方式。比如线下pos刷卡，可能接入不能的公司。每个公司的标识是渠道号。

当然随着日后的业务复杂我们也可以在此基础上进行扩展，但是这是平台一个共有的协议语言。每个平台根据自己的需求设置自己的规则与四码一号的关系即可。

我们实现了两种分布式事务模式来保障状态的最终一致性，原理类似阿里的TCC方式，采用二阶段原理。一阶段投票，二阶段提交。但是这里隐藏着一个潜在的问题——事务悬挂，下面简单介绍一下：

当第一个阶段发起之后，事务的管理者长时间没能接收到结果，变会认为交易失败，发起回滚。事务参与者接收到事务回滚请求，并且回滚成功。此时，事务的参与者接收到了第一个阶段的请求。好吧，我处理好了，等你提交。可惜没人会来提交了，因为对于事务的管理者而言该事务已经完成了。如何解决？哈哈，这里先不介绍了[呲牙]，方法比较多，后续可在后续群里进行沟通。

在调用三方进行支付的时候经常会遇到三方回调不及时，我们和三方状态同步不及时的问题，这个问题我们是这样处理的，具体我们来看看下图。

资产调度中心，在支付的过程中会把没有拿到支付状态的单据流水落到一个补偿模块中。补偿模块会5秒钟触发一次查询同步支付状态。当同步到一定次数发展用户仍然没有支付成功的情况，会对该笔流水进行降级处理，通过延时中心延时重试查询，直到交易关闭。

如何利用优先的服务器资源达到快速的任务补偿（支付同步结果要求：4个9的支付流水需要在5秒钟内同步支付状态）采用了一个分布式调度方案。

1.     首先对任务进行一次分解。比如我要补偿10分钟之内没有支付成功的单据。可能这个期间的单据数量很多，一次捞取处理比较困难。我们可以把他分成十份，每份捞取1分钟的数据，进行任务分解。每份的捞取使用消息或者rpc调用的方式进行，达到缓冲和负载均衡的效果。

2.     对于上面每个小区间捞取的任务再进一步分解执行，同理使用消息或者rpc调用方式进行负载均衡，充分利用现有的服务器资源。

今天有关有赞支付产品模块就介绍到这里了，还有一些我们还在设计开发阶段，例如水平拆分这里暂时就不介绍了，后续有机会再进行分享，最后谢谢大家的时间，也希望大家持续关注有赞。

二、Q&A

Q：支付工具：包含营销类、资产类等，银行卡是一种特殊的支付工具，通过调用渠道进行处理？这里资产怎么做为支付工具呢？

A：资产类支付工具目前主要是账户余额。

Q：有一个问题哈“资产交换”是否是常规意义上的统一支付？

A：资产交换可以理解成统一支付，这样定义更为恰当，他包含所有交易类型指令的编排和处理。

Q：余额不该是负债类吗？

A：哦，这个资产的意思不是指的复试记账中的资产与负责。泛指资金流相关。

Q：收单业务、资产交换以及渠道之间的交互逻辑方便举个例子吗？

A：交互逻辑： 1.收单->资产交换->组装支付指令->调用渠道->渠道路由->调用三方api； 2.三方回调->渠道->资产交换；3.如果状态没有回调，触发补偿：资产调度->渠道，如果是组合支付就比较复杂了。

Q：当遇到信贷类支付方式、或者资产类理财产品去做支付， 这个“资产交换” 可能就需要另外一个资产中心了，这样理解对吗？

A：可能不需要，只要在账务上区分”借记账务”和”贷记账务”就可以了。

Q：再问一个问题，支付过程中，重复支付这种异常情况如何处理？

A：重复支付进行支付撤回或者退款，重复支付问题目前看来只能尽可能的减少概率，聚合支付场景很难杜绝。

Q：只在资产交换层面上进行撤回和退款吗？

A：恩，是的

Q：有赞买的支付牌照吗？

A：这个事不归我管呢，哈哈：）

Q：现在的支付系统有做混合支付吗？比如银行卡支付100+余额100的组合支付。

A：混合支付目前还没上线，后续会支持。

Q：目前走微信支付和支付宝渠道的比重哪个大？

A：差不多呢，微信支付稍微多些。

Q：业务模式码：该产品下的业务模式，比如担保交易，即时到账等，即时到账的这种场景，有直接到资金账户的场景吗？这种对风控要求很高，有什么方法吗？

A：比较好的方法是做准实时对账了，也可以在提现上控制商户。

Q：通道码和渠道号有主从关系吗？

A：通道码和渠道号没有主从关系。

Q：渠道号不能推算出通道码，是这个意思吗？

A：渠道号不能推算出通道码，因为一个渠道号可能包含多个通道码。一个通道码也会对应多个渠道号。

Q：感谢分享，方便详细说一下事物悬挂是怎么实现的吗？

A：通过一个幂等性表可以解决，也可以通过其他方式，比如延时空回滚等。

Q：四码一号在你们微服务间传递应该再加上业务数据一起，这么理解对吗？

A：是的，和业务数据一起。

Q：资产交换是个行业术语还是？贵司特色？

A：不是行业术语，杭州公司好像用的比较多，其他不太了解，和阿里有关，哈哈。

Q：超时后发回滚的只是其中一个参与者吗？还是说全部发出回滚指令？这段我理解不清，是否可以细说一下呢？

A：不是，只要有一个失败，所有的参与者都需要回滚，这里为了简化只画了一个参与者。

Q：nodejs那部分是什么功能？网关作用？业务分发负载均衡？

A：目前只是前端展示。

Q：第一阶段的参与者，在没有收到commit或者rollback之前，会一直和数据库保持连接（connection）吗？有没有相关的资料给推荐一下。

A：不会，处理成功本地事务已经提交了。

A：搜索TCC分布式事务，事务型消息有很多资料。可以参考这篇文章。

Q：转账有四码一号吗？ 请问如何处理？

A：根据自己的业务场景来定就好了。转账也是可以有的，有些码可以复用支付的，转账某种意义上讲也是一种支付。

Q：注册中心为什么要从zk修改为etcd呢？

A：维护起来比较方便，公司有这方面的专家，掌控力比较强。编程和扩展稍微好些，另外算法好像也有一些优化（选举），感觉主要原因还是哪个掌控力更强，比如我们消息用nsq。

Q：支付过程中如果系统挂了，都做了哪些异常处理？

A：如果预支付已经完成，那就落了补偿表，系统恢复自动收敛。支付成功回调回来发送事物性消息进行入账。只要回调成功，消息就会确保被处理，如果回调过程挂了依靠补偿自动收敛。

Q：你们的事务管理器是自己研发的？性能上比补偿式事务更有优点？

A：是自己研发的，两个应用场景不同，不是替代品。补偿适用于单支付工具场景，简单实用，tcc分布式事物处理组合支付场景，依靠补偿处理有些复杂。

三、自由讨论

3.1 支付路由及资金调拨

Q1：陆金所的资金调拨如何实现的？

A1：通过银行转的，目前支持兴业银行，中信银行，浦发银行，微众银行，民生银行，恒丰银行，新网银行。

Q2：流量如何分配？

A1：订单轮循

Q3：你们接入银行出款通道，银行有提供业务对账文件么？

A1：出款是没有对账文件的

A2：有些有，有些无。回盘文件肯定是有的，但t1的对账单不一定都有

A3：出款一般走实时代付或者批量代付，一般银行第二天会出对账文件的。

Q4：哪些银行有出款业务对账文件？

A1：工农中建都有

Q5：出款银行返回结果不明确的，你们一般处理时间多长？

A1：银行都有交易查询或者对账接口吧，可以问下银行

A2：目前都是通过查询，不明确的第二天核对资金确认最终状态，交易越来越多，处理时效就越来越差了。

A3：银行是走大小额系统吧，一般15分钟也会返回结果了吧。银行出现退票是另外的处理情况。

A4：我们一般是当天会持续地发查询，一般是2的N次方秒查一次，第一次是2S查一次，第二次是４S查一次，后续再８S，１６S，以此类推，我们目前最多是查８次还是多少次我忘记了。如果这种还是无法得到明确的结果，出款类交易属于待确认的，我们会把这笔交易认为是成功的，以保证资金安全，T+1日再跟银行进行对账，根据对账结果，如果有差错，再进行差错处理。

A5：认为成功实际没出，那用户会投诉，解释 银行退票？还有这也会增加结算人员工作量，尤其没有业务对账文件的时候。

3.2 产品、运营职责

Q1：产品和营运工作的重点各是什么？ 或者工作的目标和考察的内容各是什么？

A1：产品负责生孩子，运营负责养孩子

A2：内：优化支付产品（收银台，支付后台管理等） 外：满足业务方各类支付需求

A3：小公司产品还担着项目管理的工作

A4：处在产品和用户之间的营运 一方面需要开发用户群 向用户推销产品 一方面需要发掘发现用户需求 帮助产品完善功能

A5：运营分为很多种：市场运营，活动运营，内容运营等等。有些公司运营和产品不分家。产品负责把产品做出来，其需求来源，灵感，创新等都不能脱离用户，而运营工作是离市场和用户最近的。产品要评估看新的功能是否是用户想要的，也需要通过数据运营来验证。 数据运营也就是昨天驴妈妈那位PM分享的。数据运营又分两部分：一部分是为了改进产品功能，一部分是为了调整营销活动。

Q2：市场运营用户运营互动运营内容运营这些都是一个东西吧 或者说一件事的几个步骤？

A1：侧重点不一样。市场运营：品牌、行业。用户运营：偏重用户数据，用户拜访，沟通，客服。内容运营：就是社群，有些产品有内容导向的社区，直播，公众号之类的。这些划分不是绝对的，有重合有侧重。

A2：这些东西都太大、太空，就我之前做聚合支付的情况，最好的办法就是降低费率。做P2P的情况来看，最好的办法就是送钱，蹭银行大腿。其他的运营方式都是缓慢的过程，所有的数据运营都是要在这些之后才做的，都是后话了。

A3：并不空，小公司可以从社群做起

A4：是啊，但是好多都没有章法，都是说砸钱，但这解决不了根本问题，用户基本上都是卷钱就走人了，所以，感觉还是自己的产品要自成体系，让用户切实离不开你的产品。

3.3 宝付上市

上主板，IPO暂缓了。宝付持有全国互联网支付牌照，前不久有获批跨境外币和人民币支付许可

刚刚，马云拿下中国联通！全世界沸腾

3.4 移动支付是否可以脱网

Q1：移动支付能不能做到不联网？意思就是收钱机器和付钱机器都不联网，能不能做到？

A1：至少有一个要在线吧

A2：NFC可以。移动支付分为远程和近场，近场的就是不联网方式下进行支付

A3：联通以前推过空中圈存

A4：离线钱包就可以做到，现有的公交卡不就是离线支付

A5：有圈存模式，余额直接写在卡上。

Q2：银行卡不也有个脱机账户？

A1：电子现金账户…不过体验很差，需要圈存…

Q3：不连网的支付交易，怎么做到余额记录的，怎么知道扣款是否成功的？

A1：余额就在卡上

Q4：脱机怎么保证交易事务安全风控这些 靠nfc的安全保证？

A1：对，NFC本身就是小额支付，风险不大

3.5 公交卡消费模式

Q1：求分享公交卡的工作原理

A1：公交车晚上再集中上报数据

A2：公交车上那个是脱机的

A3：公交卡其实就是一种虚拟电子钱包，就像银行卡刷卡扣费一样，只是卡片的结构不一样，银行卡属于磁条卡，公交卡属于芯片卡，就安全性而言后者优势较大。那是感应卡，卡里有个芯片，但没有电源，当卡靠近读卡器时，感应天线接受到电磁辐射，产生能量以供芯片工作（芯片功率很低的）。

因为你买IC卡时你卡上的信息已经存储到系统里了 当你乘车时刷卡机就读取信息扣除相应的金额存储在刷卡机里 然后公交公司在派人提取刷卡机里的信息。

A4：圈存时，圈存机联网，将额度写入卡芯片的电子现金账户里面，这样卡就有余额了；支付时，不需要任何联网，终端与卡片交互，扣除电子现金账户余额；终端定期（一般会在晚上，或者通过批结算等操作来触发）将脱机交易信息，联网上送到后台，直至发卡机构，这时发卡机构才晓得，这张卡的电子现金账户扣钱了…

Q2：在一辆车里有两个刷卡机，是联网的吧？

A1：一辆公交车内部的两台机器，属于串联交易

A2：好像是用RJ45端口进行串口数据交互

Q3：公交卡具体的消费流程是怎样的？

A1：读卡器开始寻卡，读到IC卡，校验卡密钥，然后写卡（不同业务类型写不同卡片区域），写卡后再次读卡确认，返回交易结果

A2：地铁卡里有写你的进站站点，读卡后，读卡器把进站站点返回到PC系统，系统计算价格后告诉读卡器，进行出站业务，扣费**元，读卡器把相关信息写到地铁卡里

A3：对于芯片其实是有两个账户的，一个是本地账户，存在卡上，另一个影子账户，存在远程，理论上这两个账户的钱是一样的。另有资金账户，消费前先将资金账户的钱转到影子账户，卡片再通过联机设备将钱写入到卡中。消费的时候，中间有安全校验，完成后，就扣钱，扣的是卡上的钱，（当然，还可以冲正），商户拿着最终的消费记录上传给发卡机构，发卡机构进行结算，将扣影子账户的钱。

地铁这块我不是特别清楚，但说联机我不太同意，联机方案风险太大，出现问题所有人都进不了站。

A4：地铁AFC系统里读卡器正常是联机的，如果出现断网，也支持脱机交易，恢复网络后上传交易和下载参数。也有更新，虽然频率不是很高，一般比如启动去联网下载一下最新的计费规则，黑名单，系统参数什么的

A5：每笔交易过程中不联后台，交易完成后马上上传交易信息即可。联机脱机其实应该说是设备的状态，交易过程独立看应该算都是脱机交易的。

A6：我理解和饭卡的原理一样。

1. 用户在商户店内选择商品或服务；

2. 用户到商户收银台结账；

3. 商户在现场脱机受理终端（POS）输入消费金融，通过近场通信技术，向移动终端／智能卡发起账户扣款请求；

4. 移动终端／智能卡收到扣款请求，进行扣款的鉴权，通过后直接在其离线钱包中扣款，并返回扣款应答给受理终端；

5. 完成支付；

6. 脱机现场受理终端定时上传交易数据，第三方支付机构每日与特约商户对账；

7. 第三方支付机构的结算部门按商户的结算周期，根据系统的结算数据，向银行发起付款请求

Q4：进地铁站的时候 可能刷卡机给我卡打了个标识 然后出站的时候刷卡机读到了这个标识 然后根据既定程序进行扣费？

A1：原理上是这样

A2：卡内估计是存储余额，进站站名，时间，密钥等信息， 到结算是，取出这些信息按照本地库的计费模型进行核算。

A3：卡内可存储的东西很多

3.6 征收的手续费设计思路

Q1：你们在设计系统的时候，要征收的各种手续费这块有没有什么设计思路啊？

A1：我们是实时分账的，再将手续费归类，分发到各个手续费子账户

A2：收费先确定收费方式:内收，外收。 再确定计费模型: 按笔，按比例，区间等。

A3：支付手续费正常的就是产品上设置内收，外收，征收方式，还有其他的处理费用

Q2：如果有多种需要征收的手续费，怎么设计会便于扩展？

A1：多种手续费模式及模型都不一样，所以应该是分开计费

A2：费用一般是和交易关联，一个产品支持多个交易，交易对计费是一对多映射关系

Q3：我现在纠结的是不想去交易订单表里面扩字段，我感觉这样每次新增一个费用就要扩展一个字段。但是不去订单表里面扩展字段我又没办法统计。我要统计的是一个订单总的各种支出，总手续费A, B,C,D这样

A1：将计费模型变成计费标准，一个标准里含多个模型，订单表中记录计费标准。扩展不应该字段扩展，扩展记录

Q4：你说的计费标准能给我解释一下不？

A1：就是多个计费方式自定义成一个组。数据用k,v方式将不同的计费方式组合。因为订单表要稳定，只有一个字段，所以这个字段应该指向一个list方式聚合对像

来源：凤凰牌老熊