北京华网天下

支付的整体技术架构及发展历程分析

2024-01-24

来源：网络整理

1.1 公司简介

首先，我们简单介绍一下公司。该公司是一家商业服务公司。通过产品和服务，帮助互联网时代的商家管理店铺、管理货物、管理客户、管理资金，从而让生意变得更好。我们致力于成为商户服务领域最值得信赖的领导者，并希望继续成为一个“快乐”的组织。公司网站：

企业支付是该公司众多产品之一。公司整体产品群大致如下图所示：

1.2 发展历史

下面介绍一下企业支付的发展历史

该公司和大多数互联网公司一样，经历了系统开发语言从PHP过渡到JAVA、从烟囱架构过渡到SOA面向服务架构的过程。服务化过程需要一步步进行，会受到各种技术债务、遗留问题、业务压力的困扰。

我们首先建立了收单、支付、记账的核心系统，然后逐步丰富了整体的支付结构。

我们先介绍一下公司支付目前的产品结构，如下图：

我这里就介绍一下图中的几个模块。它们可能与其他公司的付款结构或模板略有不同。

其他模块应该都比较类似，这里就不一一介绍了。

1.3 技术架构

以下是公司支付整体技术架构介绍：

其中rds-是基于数据库开发的中间件。 rpc框架在业务使用中比较常见。注册中心服务发现最初使用的是zk，现在正在逐步切换到etcd，这是公司自己开发的开源PHP框架。

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

首先需要介绍的是统一的业务上下文。先说一下背景：基于SOA的系统职责划分清晰，这也会带来更细的服务粒度。经过长期的发展，各自都会发展出自己的一套业务协议，服务调用也会层层转化。系统整体连通性较差，维护困难。困难等

经过一番归纳和整理，我们设计了一种符合公司业务发展的统一业务上下文语言——“四码一号” 四码一号是一串20位数字。

当然，随着未来业务变得更加复杂，我们也可以在此基础上进行扩展，但是这是平台通用的协议语言。每个平台可以根据自己的需要，制定自己的规则以及四码一号的关系。

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

第一阶段发起后，如果事务管理器长时间没有收到结果，则认为事务失败，发起回滚。事务参与者收到事务回滚请求，回滚成功。此时，交易参与者收到第一阶段请求。好的，我已经处理好了，等你提交。可惜没有人来提交，因为对于事务管理器来说，事务已经完成了。怎么解决？哈哈，这里就不介绍了[呲ya]，方法有很多，可以在后续群里交流。

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

资产调度中心在支付过程中会将未收到支付状态的单据放入补偿模块。补偿模块每5秒触发一次同步支付状态查询。当同步达到一定次数，用户仍然未能支付成功时，交易将被降级，并通过延迟中心延迟查询并重试，直至交易关闭。

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

首先分解任务。比如我想对10分钟内没有成功支付的单据进行补偿。这期间可能会有大量的文件，一次性处理起来比较困难。我们可以把它分成十个部分，从每个部分获取1分钟的数据，然后分解任务。使用消息或rpc调用来检索每个副本，以实现缓冲和负载平衡效果。

从上面每个cell得到的任务被进一步分解并执行。同样，通过消息或rpc调用进行负载均衡，充分利用现有服务器资源。

今天我们就为大家介绍一下公司的支付产品模块。还有一些我们仍处于设计和开发阶段。比如水平分割，这里暂时不介绍。有机会的话我们会分享的。最后，感谢您的百忙之中，希望您继续关注公司。

2. 问答

问：支付工具：包括营销、资产等。银行卡是一种特殊的支付工具，通过调用渠道进行处理？这里资产如何作为支付工具呢？

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

问：我有一个疑问：“资产兑换”是传统意义上的统一支付吗？

A：资产交换可以理解为统一支付。这个定义比较合适。它包括所有交易类型指令的编排和处理。

问：余额不应该归类为负债吗？

答：哦，这个资产不是指复试会计中的资产和责任。一般指资金流向相关。

问：方便举例说明收单业务、资产交换和渠道之间的交互逻辑吗？

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

问：当遇到基于信用的支付方式或者基于资产的金融产品进行支付时，这种“资产交换”可能需要另一个资产中心。它是否正确？

答：可能没有必要。只需在账户中区分“借方账户”和“贷方账户”即可。

问：还有一个问题，支付过程中出现重复支付的异常情况如何处理？

答：重复付款需要撤单或退款。目前看来，只能尽量降低重复支付的概率。聚合支付场景难以消除。

问：提现和退款只能在资产兑换层面进行吗？

答：嗯，是的

问：公司购买了支付牌照吗？

A：这事不关我的事，哈哈:)

问：目前的支付系统支持混合支付吗？例如银行卡支付100+余额100的组合进行支付。

A：混合支付尚未上线，但后续会支持。

Q：目前使用微信支付和支付宝渠道哪一种？

答：差不多吧。微信支付稍微贵一些。

Q：业务模式代码：该产品下的业务模式，如担保交易、即时支付等。在即时支付的这个场景中，是否存在直接将支付划入资金账户的场景？这就需要非常高的风险控制。有什么方法吗？

A：更好的办法是实时准确对账，还可以对商户提现进行控制。

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

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

问：无法从频道代码推算出频道号。你是这个意思吗？

答：频道号不能从频道码中推导出来，因为一个频道号可能包含多个频道码。一个频道代码也将对应多个频道号。

问：谢谢分享。您能详细解释一下如何暂停吗？

A：可以通过幂等表解决，或者其他方法，比如延迟空回滚等。

问：四码一号要与业务数据一起在微服务之间传输。它是否正确？

答：是的，连同业务数据。

问：资产交换是行业术语吗？贵公司的专业是什么？

答：这不是行业术语。微信企业似乎用得比较多。我对其他人了解不多。跟阿里巴巴有关系，哈哈。

Q：超时后是否只有其中一名参与者会回滚？或者我们都应该发出回滚指令？我不太明白这一段。你能详细说明一下吗？

A：不需要，只要出现故障，所有参与者都需要回滚。为简单起见，此处仅绘制了一名参与者。

问：那部分的作用是什么？网关功能？业务分布负载均衡？

A：目前只是前端展示。

问：第一阶段的参与者是否会保持与数据库的连接，直到收到消息（）？您有相关资料可以推荐吗？

A：没有，本地交易已经提交成功。

A：搜索TCC分布式事务。有很多关于交易消息的信息。你可以参考这篇文章。

问：转账有四位数字吗？怎么处理呢？

A：根据自己的业务场景来决定即可。还可以进行转账，并且某些代码可以重复用于付款。转账从某种意义上来说也是一种支付方式。

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

答：比较容易维护。公司拥有该领域的专家，控制力强。编程和扩展稍微好一点，算法好像还有一些优化（选举）。我觉得主要是看谁的控制力更大。例如，我们使用 nsq 进行消息传递。

Q：如果支付过程中系统挂掉，如何异常处理？

A：如果预付费已完成，则补偿表将被删除，系统将恢复自动收敛。支付成功后，发送交易回调记录交易。只要回调成功，就保证消息能够被处理。如果回调进程挂掉，会依靠补偿自动收敛。

问：你的交易管理器是你自己开发的吗？与补偿事务相比是否有性能优势？

答：是我自己开发的。两者的应用场景不同，不能替代。补偿适用于单一支付工具场景，简单实用。在tcc分布式事务处理结合支付场景中，依赖补偿处理有些复杂。

3. 自由讨论 3.1 支付路径和资金分配

Q1：陆金所的资金配置是如何实施的？

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

Q2：如何分配流量？

A1：订单轮换

Q3：您可以使用银行提款通道吗？银行是否提供业务往来文件？

A1：提款没有对账文件

A2：有的有，有的没有。退货单肯定有，但不一定是T1的声明。

A3: 付款一般是实时或批量付款。一般情况下，银行会在第二天发出对账文件。

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

A1：工人、农民和中国建筑公司都有

Q5：如果发卡行返回的结果不明确，你们通常需要多长时间处理？

A1：银行有交易查询或对账接口。你可以去银行问问。

A2：目前都是通过查询的方式进行，不明的资金次日进行核对，确认最终状态。随着交易越来越多，处理时间也越来越差。

A3：银行采用大额系统，一般15分钟内就会返回结果。如果支票在银行被退回，则另当别论。

A4：我们通常在白天连续发送查询，通常每秒发送一次2的N次方。第一次是每2S一次，第二次是每4S一次，然后是每8S、16S一次，以此类推。目前最多检查次数是8次，具体多少次我忘了。若仍无法得到明确结果且提现交易等待确认时，我们将视为交易成功，以确保资金安全。我们会在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：中国联通之前就推出过空中存款。