下载APP
关闭
渠道合作
推荐作者
02 | 原理解读：如何理解第三方支付的业务逻辑和系统组件？
2020-12-23 任杰
分布式金融架构课
进入课程
讲述：任杰
时长24:29大小22.43M
你好，我是任杰。这节课我们聊一聊如何理解支付业务逻辑和系统组件。
你有没有好奇过，第三方支付公司是怎么解决这些复杂业务问题的呢？如果你在金融行业呆过一段时间，就会发现不只是扫码支付，其他的金融业务都很复杂。那我们有没有可能复用第三方支付的这些经验，来解决其他的金融业务问题呢？
和我们解数学应用题一样，要应对第三方支付这类复杂的业务问题，我们首先要分析它里面的核心原理是什么。接下来尝试通过核心原理来推算出可能的规律。这些规律就决定了系统架构的演进规律。如果你掌握了这些分析问题的方法，碰到其他复杂的金融业务问题时就能游刃有余地解决了。
所以，接下来我们先搞懂支付涉及的核心金融原理，然后按照架构由简到难的顺序，逐步学习点券系统、支付系统和第三方支付公司的支付系统。这样你就能理解支付系统是如何遵循核心金融原理，一步一步从简单的几个组件发展到全面的系统架构了。
信息流与资金流分离
我们都知道，作为架构师，我们在做架构设计的时候，需要确保架构原理和业务原理一致。每一行都有自己独有的业务原理，支付业务也不例外。
那说到业务原理，在支付业务中最核心的概念是信息流与资金流分离。那什么是信息流和资金流呢？用一句话来概括，信息流指的是想象中钱的流转过程，资金流指的是钱的实际流转过程。
具体怎么理解呢？我给你举一个简单的例子。
假设你（用户 A）和你的朋友（用户 B）做生意。你的银行账户里有一块钱。白天的时候，你给你朋友转了一块钱。但是你并没有把钱实际转给你朋友，而是给你朋友一张字条，上面记下了你转给你朋友一块钱。同样的，你朋友过了一会儿也通过字条转回给了你一块钱。在白天你们俩就这么来回转来转去。
到了晚上你和你朋友对了一下白天所有的交易，发现你一共要转给你朋友 51 元，而你朋友一共需要转给你 50 元。
显然你们俩之间的这 50 元是可以互相抵消掉的。抵消之后，你只需要给你朋友转一块钱就行。于是你通过银行将这一块钱转给了你朋友。过程示意图如下：
我们分析一下上面这个过程。你账上的一块钱在白天的时候一直没动。这一块钱是真实的资金，你在白天的时候一直都有这一块钱的所有权。
但是在白天你和朋友通过纸条的形式将这一块钱来回转来转去，这个过程其实转移的是这一块钱的使用权。这种资金使用权的转移过程就是信息流。
只有晚上你们俩对完账，并通过银行转完账之后，这一块钱的所有权才真正属于你朋友。这种资金所有权的转移过程就是资金流。
顺便提一下，我们在前一节课介绍跨行转账时提到了清算中心和央行。这个例子中用字条转账的过程就是清算中心每天做的事情，最后通过银行转账的过程就是央行在做的事情。我在后面还会再讲一个类似的例子。
当然了，原理只是说信息流和资金流可以分离，通常这两者也是处在分离的状态。但是它们俩不一定需要分离，比如有个实时清算的概念，可以实时保证信息流和资金流一致。
现代支付系统中普遍采用了信息流和资金流分离的做法，这里的原因有很多。如果从系统架构的角度分析，我们会发现，实时清结算对软件系统的吞吐量和延时要求非常高，同时还要求所有参与的支付公司都具有实时清结算能力，任何一家达不到都不行。
这样一来，就需要整个国内和国际金融系统都重新设计系统底层的核心架构。短期来说，这么巨大的技术投资并没有相应规模的经济收益作为支撑。
所以，目前我们在支付系统架构设计中需要假设这两者是分离的。理解了这个概念，我们再来看看它会给架构设计带来哪些影响。主要有以下三点：
第一，支付环节的非银行参与者只能产生信息流，不能产生资金流。这是因为大多数金融机构并没有物理的现金，纸钞都放在了银行里。
所谓合久必分，分久必合。虽然信息流和资金流分开了，但它们俩最终还是需要同步的。同步的过程就需要再次和银行系统进行对接。这意味着支付系统需要通过网关的形式与外部支付系统进行状态同步。
第二，资金流和信息流分开之后，这两者将以不同速度在不同时间的不同主体分开流转。这意味着支付系统从本质上是一个异步处理系统，资金流和信息流的统一具有最终一致性（Eventual Consistency）。这就是为什么在扫码支付状态拉取时，银行对接是异步消息处理的。这个我们上节课也提到了，你可以仔细体会一下。
第三，资金流和信息流最终需要同步，即需要一个核算系统来确认同步过程准确无误。
好了，讲到这里，你应该理解了支付系统架构的核心原理，就是内部信息流系统与外部资金流系统的异步交互。
那怎么把这个原理转化成技术架构呢？接下来我们先来看看最简单的点券系统架构是怎样的。
点券系统
在点券系统里资金流和信息流是一致的。这是金融业务最简单的情况，也是所有相关架构的基础。
顾名思义，点券系统就是管理点券的系统。因为重点是讲解架构原理，所以在这里对点券业务和系统做一些简化。
现在我们假设只有代金券这一种点券，而且你只能使用代金券来购买产品。
具体的购买流程是这样的。首先，业务系统需要发起一笔交易订单：用户 A 用 10 元的代金券从用户 B 购买一支笔。
交易订单接下来会变成支付订单。支付订单只记录了用户账号的变动关系，不包含物品交换的关系。简单来说，交易订单包括财产交换和物品交换两种信息，支付订单只包含财产交换的信息。
这笔支付订单会发给支付系统。支付系统在收到这笔支付订单后，需要对用户 A 及用户 B 的代金券账号进行处理。
假设最开始用户 A 拥有 100 元代金券，用户 B 拥有 10 元代金券。那么在购买后，用户 A 的代金券账号需要减少 10 元的代金券，同时用户 B 的代金券账号需要增加 10 元的代金券。
好了，到目前为止，我们可以看到，支付过程至少需要 3 个系统：
1. 业务系统，负责生成交易订单和支付订单；
2. 支付网关，负责处理支付订单；
3. 账务系统，负责维护用户账户情况。
系统架构图如下：
点券支付到这里就结束了。但是作为一个完整的系统好像还缺了些什么功能。比如，在用代金券支付完成后，用户可能需要检查自己的代金券余额，以及与代金券相关的账单。所以我们还需要一个查询系统来完成相关的查询。
另外从产品体验角度看，现在的系统还有一点不足：用户 B 并不知道自己账户收到了点券。这时候及时通知用户 B 可能是一个更合适的产品设计。这时还需要一个账户变动的通知系统。通知系统通常采用异步通知的方式。
为了方便理解，我们假设所有和用户相关的系统都在业务系统内。更新之后的架构图如下所示（红色标注的是更新的节点）：
账务系统、查询系统以及消息系统处理的都是用户的点券数据。很显然，数据传输除了上图这种基于服务的实现方式外，还可以直接通过数据库。所以在实现的时候有两种不同选择，如下图所示：
支付系统
刚才我给你讲过了信息流和资金流一致的点券系统。但现实中，绝大多数支付业务场景是资金流和信息流不一致的情况。所以你必须知道，什么样的架构系统，才能处理好信息流与资金流不一致的情况。
接下来我们来看一个典型的例子——电商公司的支付系统。
电商公司一般没有第三方支付牌照，需要通过支付系统来对接第三方支付公司。支付系统负责的业务种类也非常多。我们讲讲最常用的业务，通过第三方支付完成的银行卡支付。
这个例子也和前面一样，用户 A 用 10 元钱从用户 B 那里购买一支笔。区别是这次用户 A 用银行卡付款，而不是用点券。
在推导系统架构之前，我们照例先做业务分析。银行卡是属于用户所有的资产，电商公司没有权力处理。所以银行卡这个资产只能通过第三方支付公司进行操作（其实是通过第三方公司背后的银行及卡组织）。
另外，第三方公司提供的 API 接口都是异步的。异步接口除了常见的成功和失败两种状态外，还有第三种状态，那就是不确定状态。这就意味着点券系统到支付系统的架构演进其实是从同步系统到异步系统的演进。
我们还是按照业务流程逐步分析，看看基础的 4 个系统之上，还缺了哪些功能，需要增加哪些组件。
和点券系统一样，业务系统还是照例发起一笔支付订单给支付网关：用户 A 将银行卡上的 10 元转给用户 B。不同点在于，支付网关在收到这笔支付订单后，需要判断支付系统能否独立完成资产的转移。点券这种内部资产是可以内部解决的，但是银行卡属于用户，是外部资产，支付系统不能自主解决。
所以支付网关还需要实现路由能力，将内部资产和外部资产两种操作，分发给不同的资产处理组件。因此，这里我们还需要增加内部和外部资产管理系统两个组件，如下图所示。
左边是前面介绍的点券系统的架构图，你可以对比看看：
外部资产管理系统需要对接第三方支付公司来完成银行卡转账业务。这个对接任务通过金融网关来实现。金融网关主要是实现二进制协议的对接，比如证书签名、加解密、协议传输、数据校验等。
通常金融网关会对接多家第三方支付公司或者银行。这样当一家支付公司临时连接不上时可以切换到下一家，或者当一家支付公司费率相对较优时可以临时切换。选择哪一家支付公司来对接的过程也叫作路由，通过当前情况智能选择路由的过程叫智能路由。因此，架构图上需要再增加一个金融网关服务：
需要注意的是，金融网关和第三方支付公司之间走的是异步通讯协议。前面讲过，异步通讯有额外的不确定状态。那架构上应该如何处理呢？
不确定状态的处理方法分为两步。第一步是在规定时间内重复查询支付状态，一般把这种行为叫作轮询。我们在前一节课提到的用户 App 通过轮询来获取支付状态，这是同一个道理。
规定时间内的轮询如果失败，支付过程并不一定失败，我们还有补救的机会。每天晚上电商公司会有一个与第三方机构进行对账的机会，在这个时候双方会对白天所有交互的明细进行对比，查漏补缺。
这就是异步系统对接时的架构设计原则，需要将同步系统的一次调用拆分成三个步骤：异步调用、轮询和对账。
我们在这里温习一下前面讲过的信息流与资金流的分离。在电商的场景下，电商支付系统的外部资产管理系统处理的是信息流，金融网关对接的第三方支付公司处理的是资金流。信息流和资金流分离之后，两者的状态就不再一致。
所以从信息流系统角度来看，资金流系统会存在不确定的状态，这就是为什么除了成功和失败以外，会出现第三种状态的原因。信息流和资金流虽然分开了，最终它们还是需要同步，因此需要通过轮询和对账这两种方式来实现同步。
这就是由支付业务原理所推导出的系统架构设计原理。
最后我们还需要把剩下的一些关键组件补充完整。你会发现上面的架构图无法保存信息流的相关信息，所以也无法处理和资金流的同步。
信息流是通过记账方式来保存的，因此我们还要加回账务系统。这个账务系统和点券系统的账务系统功能类似，但是覆盖面不同。更新后的架构图如下：
其实到这里还没有结束。我们在前面提到过如果轮询失败，需要在晚上与第三方支付公司进行对账。这个对账的任务一般是由核算系统来完成的。除了和第三方公司进行对账之外，核算系统还需要核对账务系统与业务系统之间的一致性关系。
添加了核算系统的架构图如下：
支付系统大的架构演进到这一步，就基本上能满足电商公司常用的支付需求了。
第三方支付系统
最后我们来重点讲讲第三方支付系统。第三方支付系统和电商公司的支付系统的核心组件都差不多，主要是因为它们俩都不能管理实际资金，因此都是信息流的处理系统。
电商公司会通过支付系统将信息流交给第三方支付系统处理。第三方支付系统会将这个信息流再转交给银行处理。在做跨境交易的时候我们甚至还能看到不同国家第三方支付公司之间的彼此合作。
那相同的地方我就不复述了。这里我重点讲三点不同，分别是流量支持、资金池和清算系统。
系统的流量支持
第三方支付公司有很多家客户，有可能会面临非常大的支付流量。举个例子，比如第三方支付公司负责代发工资或者代缴水电费，一到月底就会面临非常大的流量。
除了这些可以预测的高流量外，第三方支付公司还可能会面临电商促销这种非常突然的高支付流量。所以第三方支付公司需要有能力处理这种常见的互联网应用高并发问题。
这里就是金融系统架构和互联网架构结合得非常好的地方。应对高并发场景，互联网有非常成熟的解决方案。比如我们前面提到的异步消息处理，就能削峰填谷，降低峰值流量的压力。
如果流量再高，还可以选择熔断降流等手段来进行服务降级。如果存储能力支撑不了这么高流量，还可以使用各种不同的缓存技术降低查询操作对数据库的压力，或者使用分库分表的方式来进一步降低每个数据库上面的压力。
备付金资金池
第三方支付公司在调用银行接口的时候会产生费用。我接下来给你讲讲如何利用备付金资金池减少一些交易费用，同时还能提高用户体验。
资金池是一种常见的用户资金管理手段。资金池就是将属于用户的钱都放在一个大的池子里。池子里的钱不分你我，你是将资金池看作一个整体来操作的。但是你还留着一个账本，上面记载了每个人原来在资金池里放了多少钱。这样虽然钱是混在一起，但是账面上是清楚的。
资金池有很大的资金挪用风险，因此金融业对资金池的设立有很严格的监管。一般有了支付牌照之后，第三方公司才可以建立用户的备付金资金池。备付金资金池是一种新的金融产品，因此也需要新的系统组件来支持。下面举两个简单的例子。
你在用第三方支付公司 App 的时候应该见过一种叫作余额或者钱包的东西。你可以将银行卡里的钱转到余额账户。之后就可以直接使用余额里的钱。但是第三方支付公司并不一定会将你和我的余额分开存储，很有可能是放在一个资金池里处理。
比如下图展示了一种资金池的管理方式。ABCD 四个用户在第三方支付公司都有自己的余额账户。但是这 4 个余额账户并不是实际存在的，只是 4 个虚拟账户而已。真正的钱其实还是存在第三方支付公司在银行的账号里。
第二个例子是第一个例子的升级版。我们在上一节课说过外汇市场是一个一个有层级的市场。资金池也一样，多个资金池也可以拼成一个更大的资金池。于是第三方支付公司可以在多家银行开设很多资金池账户，所有这些资金池账户的钱形成更大的资金池（监管机构正在逐步限制这种行为）。
当把资金池分散在多家银行之后，第三方支付公司就不再受制于单独某家银行。这样就可以利用不同银行的费率情况来进一步降低运营成本。
举个例子，比如跨行转账需要多家银行之间配合，还可能需要支付一定的跨行交易费用。但是如果第三方支付公司在每家银行都有资金池，就可以直接在两家银行内部完成用户资金和资金池资金之间的操作了。
利用资金池来优化跨行转账的例子也有升级版。在进行跨境贸易的时候也可以使用多个资金池来降低交易成本，但这不是主要原因。跨境转账一个不太友好的问题是时间非常久，需要好几天才能到账。这时候如果你在每家银行都有资金池账号，跨境转账问题就变成多个银行内部转账的问题了，这样就能实时到账，大幅提升用户体验。
备付金资金池要求账务系统有层级式的账户体系，并且有相应的账户和资金操作。升级版的资金池看起来是下图这个样子：
清结算能力
清结算中心处理的是多家银行之间的跨行转账。当第三方支付公司有了多个资金池之后，这些资金池之间的转账关系其实和跨行转账一样。既然是一样的，那么第三方支付公司有没有可能做一些清算公司的事情，从而进一步降低交易成本呢？
的确如此。所以成熟的第三方支付公司内部都会有一个自己的清算中心。这个清算中心把自己当作一个外人，对资金池之间的转账交易进行清结算工作。这里要注意清算中心的结算过程涉及到资金流操作，需要通过内部支付网关来操作外部资金。
这样我们就把第三方支付公司最后一个组件补完了。现在的架构图如下：
跨银行备付金和清算中心合在一起后，第三方支付机构就具备了跨行清算的能力。由于这种业务模式不容易监管，容易出现洗钱等非法行为，国家已经逐步取消了这种资金管理模式。
但是清算中心这个组件还是保留了下来。尽管不能再进行跨行清算，不过有了清算中心之后就有了清算的概念，这让一些常见的内部信息流和资金流处理的方式变得更加清晰。
这个例子告诉我们，由于监管条例在不断完善，支付业务和系统架构也要随之改变。比如你在欧洲从事第三方支付业务的时候，很有可能会碰到欧盟制定的“通用数据保护条例”，这就要求你对系统架构的信息存储做进一步的划分。因此我们在设计支付系统的时候，需要根据当时当地的监管条例合理选择架构。
总结
这节课我们一起梳理了支付业务逻辑，最终推导出 C 端支付核心组件。
C 端支付需要解决的核心问题是信息流与资金流分离。我们先分析了最简单的点券系统，这种系统信息流与资金流不分离。点券系统需要账务系统来对点券这种资产进行管理，用户需要通过支付网关来对接点券系统。
那资金流与信息流分离的系统又是啥样的呢？电商的支付系统就很有启发性。点券系统需要处理的同步消息，支付系统则需要处理异步消息。所以支付系统除了需要复用点券系统的核心组件外，还需要核算系统来保证异步消息的正确处理。
有了前面的基础，再去分析第三方支付系统的核心组件就很容易了。第三方支付在业务上需要用资金池来降低业务成本，因此在架构上需要有核心组件来对资金池进行操作，同时也需要用清算中心来简化资金池操作的优化管理。
这节课的知识点整体的结构图如下：
思考题
现在跨境电商越来越普遍了。通过跨境电商，一位中国买家可以购买一支在美国销售的铅笔，这时买家付的是人民币，但是卖家收到的却是美元。
假设支持外汇业务的第三方支付公司自己拥有大量的人民币和美元储备，可以在外汇支付过程中充当买家和买家共同的对手方，即买家的人民币支付给电商公司，随即电商公司把自己拥有的美元支付给卖家。
那么为了支持外汇业务，支付公司的架构应该怎么做调整呢？
欢迎留言和我分享你的想法，也欢迎你把这篇文章分享给你的朋友，一起交流和讨论支付系统的问题。
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
上一篇
01 | 业务初探：扫了二维码之后发生了什么？
下一篇
03 | 产品大观：不同金融业务都有哪些技术实现要点？
写留言
精选留言(17)
2020-12-24所有的商业模式都是由三种基本的“流”组成的：信息流、资金流和物流。金融系统或者说支付系统主要处理前两者，直接对应支付订单；对于物流，间接地通过交易订单体现出来。对于普通机构，比如电商，物流就是真实的商品或者服务；而对于金融机构，物流蜕变成了资金。
普通机构或者说C端的资金流动由背后的商品或服务交易做支撑；金融机构或者说B端的资金流动也是由各种交易——金融交易做支撑，进行这种交易的权利体现成各种牌照，在义务上体现为接受强制的监管，从而达成权利和义务的平衡。
下面只谈对于信息流和资金流的思考。
信息和资金本是一一对应的，但由于具有不同的特点，在流动的过程中开始分离，就像不同密度的流体，在流动的过程中形成了分层那样。
信息流和资金流，都体现成数字流。在这里的语境下：
l信息流可以体现为一笔一笔的流水，是一个增量的数据，就像顺序读写文件那样，速度比较快；“一笔”信息流天生就是不可分割的，即原子的，要不记录成功了，要不记录失败了，不可能有中间状态。
l资金流是在两个实体之间流动，造成的结果是双方账户余额的变更，本质上是对存量数据的修改。资金流动完成的前提是先修改一方的状态，再修改另外一方的状态，天生就不是原子的，需要事务系统进行保证，尤其是在系统规模十分庞大的情况下，十分容易碰触到分布式事务。
l上述两点的本质是信息流和资金流的影响范围不同，造成了资金流和信息流的分离。此外，还有外部约束也造成了二者的分离，比如处理资金业务需要特定的资质。
l既然资金流也是数字流，所以在一定的范围内，也可以转变成信息流，由信息系统进行处理。或者说一个“很长的”资金流可以在一定的前提条件下被分割成一个一个较短的资金流（这样在小系统内就可以比较容易的对应信息流），然后由某种设施将这些“子资金流”衔接起来，这个特殊的设施就是“网关”：可以是支付网关、也可以是金融网关。就像计算机网络那样，网关用来处理不同的协议转换、安全校验或者路由；金融网关也实现了二进制协议的对接，比如证书签名、加解密、协议传输、数据校验等，还有路由过程。
l根据局部性原理，范围越小，效率越高、性能越好。金融系统也不例外，把“长资金流”打散成“子资金流”后，链条上的某个节点中信息流和资金流更容易保持一致，这样提高了效率，体验自然就好了，比如资金池就可以把更多的资金流限制在自己的系统内，省去了调用网关的开销。从技术上将，就是将跨越多个节点的事务变成本地事务。同时，资金流的成本大于信息流的成本，局部性使得资金可以减少流动，只需要记一笔账就可以了，即用低成本去代替高成本。
其实系统的架构就可以按照上述的视角进行分类分析。支付架构的核心原理，是处理内部信息流与外部资金流系统的异步交互，我的理解，是在保证正确性的前提下，尽量将两者的影响范围做局部化的处理。
1、点券系统，资金流和信息流是一致的，本质上是因为涉及到的资产具有某种“同质性”，所以可以放在一个池子里，由点券系统统一操作。这样二者具有了一致性。从技术的角度看，在规模小的情况下，甚至只用一个数据库就搞定了。
2、支付系统。资金流涉及的银行卡是一种“异质资产”——它属于银行，无法将其放在自己的“势力范围”内了，所以必须调用金融网关。金融机构为了应对用户操作的峰值，用异步消息处理架构，所以网关上调用的API接口往往是异步的。如果银行做的是行内转账，它仍然是一个“点券”系统，只是点券变成了这个银行内部的资金。
此时信息流和资金流一进出现了分离，所以还需要保证它们状态的一致性（最终一致性），这就是对账，这时引进了核算系统。
3、第三方支付系统。第三方支付系统本质上就是一个大网关，这里网关从一个“组成部件”变成了独立部件，对接外部系统从手段变成了目的本身。它处理的是纯粹的信息流，但衔接的是纯粹的资金流，资金通过它从一方流动到另一方。为了提高效率、降低成本，第三方支付公司建立了资金池，尽量减少资金的流转，增加信息的流转。本地消息的流转，用本地事务就可以解决。在降低成本的同时，也提高了用户的体验。
4、跨行转账也是利用了资金池，这样资金的流转在结算结构本地就可以完成。在必要时，做一笔大的转账对备付金账户进行调整就可以了，相当于“少量大笔资金流转+大量信息流转=大量小笔资金流转”。
5、资金的流动一定会触发信息的流动，但是反过来则不一定了。信息局部流动，对外部来说就变成了一个黑盒子，对于监管是不利的。
思考题。
此时可以建成资金池。
目的是降低成本、提高效率和客户体验。那么买家用人民币支付的资金可以直接放入跨行的虚拟人民币资金池。此时相当于是买方向第三方支付机构购买了美元，这笔费用也进入资金池。再三方支付公司购买外汇时，利率可能不一样了，有一个时间窗口，可以充分利用它。
有了美元资金池以后，需要增加国际清洁算的金融网关。展开 3 13
2021-01-03这篇解读的真好，我第一次接触支付业务的时候，被这一大堆概念绕晕了，也没有好的资料来介绍（蚂蚁内部都没找到[捂脸]），花了好大劲才逐步理清。所以说既能干活又能讲课的牛人太难得了👍👍 9
2020-12-23之后能否详细讲下记账系统的记账方式和对账流程？展开作者回复: LeeR你好。记账方式涉及到账户体系和记账规则。这一块属于账务业务。我们这个系列主要介绍的是金融系统架构，所以对具体业务没有做过多的介绍。如果你有兴趣研究，可以查找相关书籍。一般可以用这些关键字来查找：会计核算模式，账务系统设计，金融企业会计。
对账的流程取决于公司的业务和对接方的情况。每家公司的情况都不一样，所以在这里很难给你一份通用的执行手册。不过对账也有一些金融原理。对账需要达到账账、账证、账表、账实“四相符”的原则。你可以按照这个思路来分析大的方面应该做哪些对账工作，然后再根据具体情况具体分析。 1 6
2020-12-23支付宝的余额宝，微信的钱包类似点券的系统，处理简单快捷， 支付机构给的电商提供支付系统，内部通过金融网关连接银行（国内网联，银联）实现资金划转。支持外汇业务的话， 增加境外支付网关，接入支持境外收单机构，卡组。境外业务金融网关，连接境外发卡行；清算服务，对接汇率查询机构，新增处理外汇业务相关业务。展开 3
2020-12-25另外，第三方公司提供的 API 接口都是异步的。
老师，我觉得这点说的太绝对了。
我对接下来，一般来说收单支付，银行卡类接口都是同步返回支付结果。 像网银，支付宝/微信支付这类网需要使用app/网页跳转支付方式，这类都是异步。
出金类接口，那都是异步的展开作者回复: 楼下小黑哥你好。谢谢你的补充。我们有几百家支付机构和几十家国有和股份制商业银行，在短短的这节课里无法对所有情况做详细的阐述。所以在这节课的开头我们提到过会对业务和系统做一些简化，重点是能理解核心的原理。
如果你觉得后面一系列内容有任何不妥之处，也请尽量指出。三人行必有我师，希望能和大家多多交流，共同学习进步。 2
2020-12-24老师，外汇汇率是实时变动的，那跨境结算时付款金额也是实时计算的吗？作者回复: 夜猫你好。在交易订单生成之前外汇汇率是一直实时变动的。但是当你点击“购买”之后，就会生成交易订单。交易订单里会锁定汇率。
不过你不用担心。你会发现如果交易订单一段时间之内没有支付的话是会自动取消的。所以支付公司只需要承担这一小段时间内的外汇波动风险。一般支付公司在给你提供汇率的时候都会把这一些波动成本考虑在内，所以不用担心支付公司会有所损失。 1
2020-12-23热点账户怎么解决呢展开作者回复: 这位同学你好。我们分析和解决热点账户一般是遵循这些思路：
首先分析哪些账户会成为热点账户。一般来说出账账户比较少成为热点账户，入账账户在秒杀和促销等场景下容易出现。所以第一件事情是如何预测可能出现的热点账户，以及及时发现热点账户。
热点账户的问题是它会突然消耗大量硬件资源，比如CPU，IO和存储。因此解决的办法有两个：你可以把峰值情况拖长，通过将访问量变平滑来减少瞬间流量的冲击，你也可以提供大量的资源来满足瞬间需求。
将瞬间流量拖长的方法会使用消息队列。虽然账户写入操作会以非常高的速度写入消息队列，但是消息队列的处理还是按照系统正常速度。这种做法有个形象的叫法是削峰填谷。
另一个做法是提供大量的硬件资源，比如说把这个热点账户的存储和处理都迁移到全新的机器上，等峰值结束后再迁移回来。具体如何迁移取要决于你们现在的架构设计方案和实现的成熟度。选择方案有很多，网上都可以找到成熟的解决方案。
最后，我们还可以跟业务方一起，通过修改业务规则来减少系统的压力。前面提到过热点账户一般是入账账户。入账账户如果成为了热点账户，那么账户的主人很有可能知道自己正在做促销，因此可以跟用户商量出一个大家都可以接受的账户更新延迟情况。这样在峰值情况下你可以通过减少一些不必要的服务来进一步优化配置硬件资源。这个方法也叫服务降级。 2 2- 2020-12-23老师 有什么书可以推荐吗展开
作者回复: 这位同学你好。我会在这一系列结束的时候给大家推荐一些参考书目。敬请期待。
1 1 
2021-01-06感觉最终还是理解了多个资金池怎么避免跨行的手续费。
因为变成两个同行转账，只是涉及的2个资金池里的钱一个增加一个减少- 2021-01-06如果流量再高，还可以选择熔断降流等手段来进行服务降级。
老师，这里的“降流”可以理解成“限流”吗 
2020-12-31老师，一个转账系统，如果用户要先打钱到我们的公司账户获得余额，然后才能用余额转账，这样算不算是资金池呢？
我碰到过的一些小公司就是这么做的，他们解释说这和充Q币差不多，不算非法资金池。但我总觉得其中有问题，希望老师解答。展开作者回复: Jerry你好。我们是介绍技术的文章，对于业务的合规性判定不太好越俎代庖。建议你还是咨询相关的专业人士。
- 2020-12-31老师，文章里提到了两种支付系统，一种是点券，一种是第三方支付，但我前东家的支付系统有点奇葩，这该怎么划分呢？
前东家的支付系统只包含：业务系统，支付网关。业务系统负责生成交易订单；支付网关负责生成支付订单，转发给不同的第三方支付公司。至于内部资产管理、外部资产管理、金融网关之类的，则统统没有。
整个流程是这样的：业务系统，生成交易订单—>支付网关，生成支付订单—>第三方支付公司，接收支付订单—>支付网关，接收第三方支付公司的回调—>业务系统，接收支付网关的回调。
这整个过程中，业务系统、支付网关作用类似，就是发订单、接收回调确认订单状态，什么对账都没有。这种系统又算是什么呢？展开作者回复: Jerry你好。我们在这节课介绍架构的时候主要侧重点是正确性。正确性在一切正常的时候没有什么用，在出了问题之后才能体现价值。这一点和在仲裁时举证一样，谁能拿出证据，谁就更占优势。
支付系统里很多组件没有也能正常工作。但这里有一个假设是要完全相信对方，一切以对方为准。如果业务方能接受，出的问题带来的资损也能接受，那么架构就是合理的。在系统开发的初始阶段，人力和时间有限，也有可能必须做出一些架构上的简化。
所以你前东家的支付系统是一个把正确性建立在别人系统之上的系统。 
2020-12-28老师好，还是备付金的问题，备付金集中存管后，第三方支付机构已经不允许有资金池了，建议说明作者回复: glutton你好。谢谢你指出这一点。我国在过去两年时间已经完成第三方支付公司备付金集中存管从零到100%的转变。所以国内资金池已经成为历史。
对于国外来说，各个国家的市场成熟度和监管条例各有不同，因此现存的支付架构依然有技术输出的可能，尤其是在与外汇相关的跨境支付。
2020-12-26这一讲通俗易懂地讲解了支付系统的主要系统组件，获益匪浅。
比较好奇这些组件对应的官方英文翻译是什么？例如账务系统、清算中心、核算系统；网上找到些支付系统术语翻译 感觉差点意思。展开作者回复: Alpha你好。支付系统没有标准化的实现方式，所以没有通用的官方中英文翻译。一个可能的翻译是这样的：
账务系统：accounting system
清算中心：clearing center
核算系统：reconciliation center
2020-12-25对账这个步骤是每个支付系统必须有的，不仅和第三方要对账，和金融管理系统也要对账
2020-12-23支付宝就算是第三方支付公司吗？展开作者回复: 黄海峰你好。我们一般称呼获得了央行颁发的《支付业务许可证》的非银行企业叫做第三方支付公司。支付宝背后的公司支付宝（中国）网络技术有限公司，以及微信支付背后的公司财付通支付科技有限公司，都拥有央行颁发的许可证。所以支付宝是一家第三方支付公司。
如果你有兴趣，可以在这个链接查到我国所有第三方支付公司列表以及它们所涉及的支付业务范围：http://www.pbc.gov.cn/zhengwugongkai/127924/128041/2951606/1923625/1923629/index.html 2
2020-12-23能想到增加的动作为汇率计算。但这动作应该外部资产管理就已经可以处理了，或者说属于这个系统的子模块处理。展开
