886 lines
26 KiB
Markdown
886 lines
26 KiB
Markdown
- 金融牌照
|
||
- 平台跳转
|
||
- 商家-收款方
|
||
- 用户-持卡人
|
||
- 中间-卡组织
|
||
- Visa
|
||
- MasterCard
|
||
- Card Network
|
||
- 中间转发各种各样的支付请求
|
||
- 无需额外对接
|
||
- 用户有各种各样的银行卡
|
||
- 商家有作为收单方也有不同银行帐号
|
||
- 减少对接以及合规的负担
|
||
- Payment Service Plantform（PSP）
|
||
- 提供一个简单的API
|
||
- 调用API，PSP处理这些支付请求
|
||
- 收取手续费0.5%-1%
|
||
- 支付系统
|
||
- 记账+内部清算
|
||
- 用来记录支付事实
|
||
- 支付流程
|
||
- 商家发起一个支付请求
|
||
logseq.order-list-type:: number
|
||
- 调用外部PSP的API，执行支付的请求
|
||
logseq.order-list-type:: number
|
||
- PSP执行完成，记录这笔账
|
||
logseq.order-list-type:: number
|
||
- 通知对应的用户支付结果
|
||
logseq.order-list-type:: number
|
||
- 每天定时对账目进行清算
|
||
logseq.order-list-type:: number
|
||
- Function Requirement
|
||
- merchant send payment request
|
||
- client can pay
|
||
- merchant can query payment status
|
||
- NonFunction Requirement
|
||
- Sercutiy
|
||
- Reliability-handle failure
|
||
- consistency
|
||
- correctness
|
||
- scaleability-PSP API
|
||
- 
|
||
- Initiation
|
||
logseq.order-list-type:: number
|
||
- Execution
|
||
logseq.order-list-type:: number
|
||
- Recording
|
||
logseq.order-list-type:: number
|
||
- Notification
|
||
logseq.order-list-type:: number
|
||
- Clearing
|
||
logseq.order-list-type:: number
|
||
- Payment integration
|
||
- serve-to-serve/PCI审计
|
||
logseq.order-list-type:: number
|
||
- SDK，如果崩溃就会无法付款，存在供应链攻击的分享
|
||
logseq.order-list-type:: number
|
||
- 隔离用户卡号
|
||
- iframe
|
||
logseq.order-list-type:: number
|
||
- hosted redirect
|
||
logseq.order-list-type:: number
|
||
- 跳转到第三方的页面
|
||
- data model
|
||
- single center table
|
||
logseq.order-list-type:: number
|
||
- 审计要求
|
||
- 不能够修改
|
||
- three table: order+payment+ledger
|
||
logseq.order-list-type:: number
|
||
- payment {
|
||
charge_id
|
||
order_id
|
||
payment_method
|
||
PSP
|
||
status{created, start, processing, successed, failed}
|
||
amount
|
||
currency
|
||
created_at
|
||
updated_at
|
||
idem_unique_key
|
||
}
|
||
- retry
|
||
- timeout
|
||
logseq.order-list-type:: number
|
||
- exponential backoff
|
||
logseq.order-list-type:: number
|
||
- jitter(+-15%)控制请求分布更加均匀
|
||
logseq.order-list-type:: number
|
||
- DLQ(exhaust)
|
||
logseq.order-list-type:: number
|
||
- PSP调用callback URL
|
||
- 失败后，service主动轮询PSP
|
||
- 采用复式记帐
|
||
- 写入到append-only数据库
|
||
- AMAZON QLDB（Quantum Ledger Database）
|
||
- Alibaba ledgerDB
|
||
- 专门为金融优化的数据库
|
||
- 对账
|
||
- 银行发送settlement file
|
||
- Turning the database inside-out
|
||
-
|
||
- Text
|
||
- 今天我们来讲一个支付系统
|
||
这种系统你还是需要一点生活经验的
|
||
因为它不是真的让你去划账
|
||
你又没有这个金融牌照
|
||
拿什么去搞这笔钱
|
||
你有可能上网去买个衣服
|
||
还要跳转到另一个平台去付款
|
||
那比如说用户拿他的信用卡去买东西
|
||
那用户这边就是持卡人
|
||
商家里面叫做收款方
|
||
两边对应着各自有一个银行
|
||
像用户这边就是发卡行
|
||
然后对面就是收单行
|
||
中间其实还有一个叫做卡组织的东西
|
||
比如说Visa或者MasterCard
|
||
他们都是card network
|
||
然后中间会转发各种各样的支付请求
|
||
用户可能会有各种各样的银行卡
|
||
所以会对应不同的发卡行
|
||
然后商家作为收单方也会有不同的银行账号
|
||
那你要是挨个去对接呢
|
||
在工作量肯定是吓死人
|
||
合规的负担也会比较重
|
||
而且银行里面的技术更新通常会比较慢
|
||
有时候你可能看到一些上古的技术栈
|
||
所以通常我们会去找一个叫做PSP的平台
|
||
就是payment service platform
|
||
通常这个PSP平台呢
|
||
会给我们一个比较简单的API
|
||
然后我们直接去调用这个API
|
||
然后由PSP来处理这些支付请求
|
||
当然它会向我们收取一定的手续费
|
||
通常是可能是0.5%到1%这个区间
|
||
那话说回来了
|
||
如果有人能去处理这个支付
|
||
那我们还设计什么支付系统呢
|
||
实际上这个支付系统想让你设计的是一个记账
|
||
再加上内部清算的这么一个流程
|
||
也就是说它是一个用来记录支付事实的系统
|
||
那这样这个问题就会简单很多了
|
||
我们可以拆分一下用户支付的这个流程
|
||
首先就是商家里面会发起一个支付请求
|
||
然后我们应该去调用这个外部的PSP的API
|
||
去执行这个支付的请求
|
||
然后PSP执行完之后
|
||
我们应该去进行一下记录
|
||
就是说我们会把这笔账记下来
|
||
所以记下来之后不管它的成功和失败
|
||
你都应该去通知一下对应的用户
|
||
最后可能是每天对这个账目进行一下清算
|
||
其实真正的过程应该比这个要复杂一点
|
||
不过我觉得能够覆盖到这么几个步骤
|
||
应该已经差不多了
|
||
毕竟你的时间也有限
|
||
所以我先把这个放在这
|
||
我们来看一下它的功能性需求应该是什么
|
||
功能性需求其实还是比较明确的
|
||
首先商家这边
|
||
他要能发起一个支付请求
|
||
然后客户这边
|
||
要能去付费
|
||
然后商家这边应该能去查看这个订单的支付状态
|
||
非功能性需求呢
|
||
首先肯定是安全吧
|
||
这是肯定不用说的
|
||
所有和资金有关的东西
|
||
security都是第一步的
|
||
然后应该是可靠性
|
||
他要能自己去handle一些failure之类的
|
||
接下来还有一个consistency
|
||
因为肯定嘛
|
||
我们希望一笔钱只被扣款一次
|
||
然后这笔账被记下来
|
||
所以一致性很重要
|
||
另外一个比较重要的
|
||
常见的金融相关是正确性
|
||
肯定是希望你的账永远是对的
|
||
这里有一个不太确定的地方
|
||
就是说这个scalability
|
||
我们会不会去考虑
|
||
因为实际上你是在调用一个外部的API
|
||
所以那么很大程度上
|
||
你的bottleneck其实不在你自己这里
|
||
在外部
|
||
这种情况下
|
||
我建议我们就一开始不要先去考虑scalability了
|
||
后面如果有条件的话
|
||
我们再研究
|
||
搞清楚这些之后
|
||
我们就可以去画一个high level的diagram
|
||
OK
|
||
这个图还是很简单的
|
||
只不过画的比较简略
|
||
我们要来挨个展开一下
|
||
那首先第一件事就是用户要去付款
|
||
那应该做什么
|
||
首先从商家这一方来说
|
||
我的服务器上肯定要给你提供付款这么一个逻辑
|
||
那也就是说我们应该做就是支付集成
|
||
支付集成
|
||
支付集成其实还是有不少方案的
|
||
比如说最简单就是说
|
||
我可以做一个server to server
|
||
对吧
|
||
商家从用户这边去收集用户的这个卡号和他的这个CVV密码
|
||
然后后端把这个收集他的卡号和密码直接发给银行或者是卡网络
|
||
那这样其实你就相当于自己建立一个PSP了
|
||
对吧
|
||
因为你需要去取得支付机构的牌照
|
||
一般大家也不会这么去做
|
||
因为商家会接触到这些 PAN (primary account number)
|
||
这些乱七八糟的东西
|
||
那也就是说你需要通过这个PCI的审计
|
||
审计这个事情通常比较复杂
|
||
合规门槛高
|
||
而且也比较贵
|
||
除了技术的复杂度之外呢
|
||
初期的投入也很高
|
||
基本上只有大型的企业会用这种方案了
|
||
但是好处也会比较明显
|
||
就是说一旦通过了这个PCI审计
|
||
自主权就相对比较大了
|
||
不再需要去依赖第三方的支付平台
|
||
可以省下一笔第三方的通道费
|
||
自己也可以去控制一些逻辑
|
||
比如说增加一些错误处理啊
|
||
分期 分账啊 这些玩意儿
|
||
那另外一个比较简单的一点方案
|
||
就是说我引入一个支付平台的SDK
|
||
这个应该是我们比较常见一种方案
|
||
大家通常用着stripe paypal
|
||
或者说国内有微信 支付宝
|
||
其实都提供这种方案
|
||
这样一来PSP提供一个js library
|
||
商家把它呢
|
||
嵌入到自己的网站上
|
||
自己去开发一些定制的UI
|
||
付费的时候
|
||
这个SDK把用户的卡号
|
||
直接传到这个PSP去
|
||
然后会返回一个token
|
||
商家用这个token来调用PSP的API
|
||
但是本身不接触用户的卡号
|
||
这样一来就可以避免
|
||
去接触用户的账号信息
|
||
但是这样说
|
||
你的瓶颈就在这个SDK上
|
||
如果这个SDK它崩溃了
|
||
那用户就不能付款
|
||
理论上这种
|
||
JavaScript SDK是通过fetch()
|
||
然后送到PSP的domain去的
|
||
不需要经过商家的服务器
|
||
但是脚本实际上
|
||
还是跑在商家页面里
|
||
所以这里如果你用XSS注入(Cross-Site Scripting跨站脚本)
|
||
或者是MageCart植入
|
||
都可以在用户的浏览器里面
|
||
去窃取到这个输入的卡号
|
||
那也就是说
|
||
这里其实存在供应链攻击的风险
|
||
那商家这一端
|
||
就应该要保护自己的前端页面
|
||
做上一些安全策略
|
||
比如说去做一个
|
||
CSP(内容安全策略 Content Security Policy) 或者是SRI (子资源完整性 Sub-resource Integrity)这些东西
|
||
只允许去加载可信的脚本
|
||
并且你要对这个脚本
|
||
验证一下哈希值
|
||
再往后退一步的话
|
||
你可以使用一个iframe
|
||
iframe相当于一个
|
||
更加安全的Sandbox管理
|
||
隔离敏感数据
|
||
也减小了攻击面
|
||
商家只得到支付的token
|
||
那么现在的SDK
|
||
实际上都会采用混合模式
|
||
SDK直接在底层
|
||
注入一个iframe
|
||
浏览器端会使用
|
||
iframe hosted field
|
||
对商家隐藏银行卡的信息
|
||
然后使用PSP的公钥
|
||
去做CSE(客户端加密 client-side encryption)
|
||
把这个卡号加密起来
|
||
最后Post请求发到PSP去
|
||
PSP拿到这个密文之后
|
||
会进行解密
|
||
然后返回一个不可逆的token
|
||
商家还是拿这个token去做扣款
|
||
不再去接触这个卡号
|
||
但是iframe的问题在于
|
||
前端的CSS和响应式
|
||
会设到这个iframe的限制
|
||
这会对你的UI的开发
|
||
产生一定的限制
|
||
有能力企业还是会选择
|
||
基于JavaScript SDK
|
||
自己去做二次开发
|
||
这样来说自由度高一点
|
||
但是同样成本也会更加高一点
|
||
最后一种
|
||
就会进行hosted redirect
|
||
直接去走一个托管的支付页面
|
||
用户点击下单
|
||
然后一个302
|
||
跳转到PayPal或者Strape
|
||
这样的平台上去
|
||
等你用户付款完了之后
|
||
再重定向回来
|
||
这其实是最简单的对吧
|
||
PCI的负担最低
|
||
运维也最简单
|
||
一旦出了故障
|
||
就全靠PSP自己去兜底去了
|
||
同样它的自由度也是最低的
|
||
因为你的UI是人家的
|
||
品牌也是人家的
|
||
全看PSP
|
||
而且这里会多一步跳转
|
||
这代表着
|
||
这里的用户的转化率
|
||
会有些损失
|
||
总的来说呢
|
||
你的可定制化越高
|
||
成本越高
|
||
不仅仅是技术实现的成本
|
||
还会有PCI的责任
|
||
和安全管控的成本
|
||
要求又会更多一点
|
||
等你集成了支付系统之后
|
||
这里就会出现第二个问题
|
||
我们花了这么大劲 对整个支付的流程做了下隔离
|
||
那既然隔离了
|
||
商家要怎么来记录这笔交易呢
|
||
其实我们只是隔离了
|
||
商家和用户的银行卡信息
|
||
用户这边提交完付款信息之后
|
||
PSP还是会把这个token发回来
|
||
这个token也叫nonce
|
||
后续的扣款
|
||
还是要商家拿着这个nonce
|
||
去和PSP发请求的
|
||
nonce一般来说是一次性的
|
||
有的时候你会看见
|
||
商家问你
|
||
需不需要保存这个支付信息
|
||
如果你勾取了这条
|
||
商家会再请求一次
|
||
换取一个可以复用的token
|
||
这里我们简单一点
|
||
就只说这个单次的nonce
|
||
有了这些信息之后
|
||
其实你已经可以开始
|
||
去写数据库了
|
||
那么这里就会有一个问题
|
||
我这数据库要怎么存
|
||
第一个想法通常是
|
||
我能不能用一张表
|
||
存所有的信息
|
||
对吧
|
||
我每次有一笔支付请求
|
||
我就记下来
|
||
用户买了什么东西
|
||
花了多少钱
|
||
然后这个支付的状态是什么
|
||
它的卡是什么
|
||
这样每一条交易
|
||
对应着这个表里的一条记录
|
||
但这里可能会有一个问题
|
||
因为支付这个东西
|
||
它是受到合规限制的
|
||
任何和金融相关的东西
|
||
都需要经过审计
|
||
支付数据在这里
|
||
应该是不可更改的
|
||
你每次有什么操作
|
||
不能说去覆盖
|
||
之前的这个状态
|
||
所以最好来说
|
||
还是要去拆分一下数据表
|
||
这个里面
|
||
应该会有三种不同的状态
|
||
首先是你的业务状态
|
||
这里有哪些订单
|
||
用户这个订单
|
||
对应着什么商品
|
||
第二个是你的交易状态
|
||
用户发起了这个
|
||
支付请求之后
|
||
有没有付钱？
|
||
用什么卡付钱？
|
||
付了多少？
|
||
然后现在是被拒绝了
|
||
还是已经支付成功了
|
||
第三个状态
|
||
就是你的资金状态
|
||
这笔钱有没有到账
|
||
这笔账要不要进行分配
|
||
有多少是最后要给商家的
|
||
有多少是最后
|
||
要付给支付渠道的手续费
|
||
所以这里三个状态
|
||
如果要做责任分离的话
|
||
至少是三张数据表
|
||
这三张数据表的读写模式
|
||
应该是完全不一样的
|
||
比如说这个资金状态这张表
|
||
它就应该是不可更改的
|
||
对于支付系统
|
||
这种合规驱动业务来说
|
||
有条件
|
||
我们还是多存一张表
|
||
也好过在同一张表里
|
||
改来改去
|
||
理论上我们可能是需要
|
||
order table
|
||
加上一个payment table
|
||
再加上一个ledger的账簿
|
||
这题的核心还是payment
|
||
那我们还是关注一下
|
||
payment表的数据结构
|
||
假设这里
|
||
就是这个payment表
|
||
我们可能需要哪些字段
|
||
首先你肯定会要有
|
||
这个charge ID
|
||
第二
|
||
然后你会有order ID
|
||
接下来可能是payment method
|
||
然后是对应的PSP是什么
|
||
这笔订单的status是什么
|
||
status可能是说
|
||
我一开始先去创建
|
||
这张支付的请求
|
||
然后这个支付开始处理
|
||
最后可能是success
|
||
或者是failed
|
||
这里通常是需要一个
|
||
状态机来表示
|
||
然后这里面会有多少钱
|
||
它对应的货币是什么
|
||
这笔支付是什么时候创建
|
||
又是什么时候更新的
|
||
最后这里可能需要一个
|
||
unique ID来做这个幂等
|
||
我直接叫他
|
||
idempotency key了
|
||
这张表要怎么存呢
|
||
通常来说和金融相关
|
||
我们都要注意一致性
|
||
但是一致性
|
||
也分内部一致性
|
||
外部一致性
|
||
内部一致性其实好处理
|
||
对吧
|
||
我直接拿关系性数据库
|
||
这关系性数据库
|
||
是有一致性保障的
|
||
那么外部一致性
|
||
这个时候我们就要盘一下
|
||
这个workflow
|
||
用户在这里去进行下单
|
||
他打开这个客户端
|
||
点击一个checkout
|
||
然后开始支付
|
||
用户的预期是
|
||
我就把这一单结了
|
||
这里其实最怕
|
||
发生的是一个
|
||
double charging
|
||
或者double spending
|
||
比如说用户
|
||
网卡了一下
|
||
然后连着点了好几次
|
||
然后接下来服务器这边
|
||
就收到多个请求
|
||
那服务器这边
|
||
多个请求
|
||
肯定不能通通去扣款
|
||
对吧
|
||
他肯定要做一个
|
||
exactly once
|
||
这个exactly once
|
||
就需要依赖了
|
||
这个idempotency key了
|
||
当用户点开
|
||
这个checkout页面的时候
|
||
服务器这个时候
|
||
应该会生成一个幂等键
|
||
然后后续流程
|
||
全都带着这个幂等键
|
||
用户点开这个页面
|
||
服务器把这幂等键
|
||
发给客户
|
||
客户下完单之后
|
||
带这个幂等键
|
||
再返回到payment service这边
|
||
service这端
|
||
我看到这个idempotency key
|
||
开始去做de-duplication
|
||
拦截重复的请求
|
||
这样就算用户点了多次
|
||
也只有一个请求
|
||
会被进行后续的处理
|
||
处理的时候
|
||
需要去更新
|
||
payment表的status状态
|
||
比如说一开始是created
|
||
然后传给他一个idempotency key
|
||
然后当你收到一个
|
||
合法的请求之后
|
||
就转入这个start状态
|
||
表示这个支付请求已经收到了
|
||
下一步就要去调用
|
||
外部平台的这个支付的API了
|
||
也就是说调用这个PSP
|
||
PSP收到这个请求开始处理
|
||
就中间可能会有一些风控啊
|
||
或者是授权之类的
|
||
交易授权这里可快可慢
|
||
通常你这里提交完
|
||
至少应该收到一个明确的信号
|
||
比如说“你的支付请求已经受理”
|
||
或者告诉你“交易失败了”
|
||
然后这个时候payment表里的status
|
||
应该去转入到processing阶段
|
||
这里最好画一下这个状态机
|
||
好 有了这个状态机之后
|
||
我就可以把这个简化一下
|
||
由于PSP是异步处理
|
||
所以我们实际上不知道PSP
|
||
什么时候能处理好
|
||
但通常来说PSP应该先给你一个
|
||
“我已经在处理了”
|
||
那如果PSP就没有给你一个信号
|
||
比如说有网络抖动
|
||
对吧
|
||
他给你信号
|
||
但是你没有收到
|
||
所以这里你应该引入一个retry的机制
|
||
那通常来说
|
||
一旦我们要加入retry的话
|
||
那你就要想到retry的四个要素了
|
||
第一个就是timeout
|
||
这个retry的等待时间
|
||
应该是有个最大限制
|
||
超过这个timeout的时间之后
|
||
你才去触发这个retry
|
||
那第二个就是backoff
|
||
我是间隔一秒钟
|
||
还是间隔两秒钟
|
||
还是说我不断去增加这个时间间隔
|
||
通常来说
|
||
这里比较推荐的是
|
||
做一个exponential backoff
|
||
我第一次等待一秒
|
||
然后第二次等待两秒
|
||
然后第三次等待四秒
|
||
这下来等待八秒
|
||
每次延长这个间隔的时间
|
||
这样不会给后端造成太大压力
|
||
那第三点是做一个jitter
|
||
jitter的意思是
|
||
我每次向后端发请求
|
||
我加入一些网络抖动
|
||
比如说我加一个正负15%
|
||
比如说我按照某个频率
|
||
给后端去发送这个重试的请求
|
||
但是这里有另一个服务器
|
||
它也采用这个频率
|
||
跟你同步的发送这个请求
|
||
那这个时候对后端来说
|
||
它可能在同一个时间
|
||
会收到多个请求同时涌入
|
||
然后在下一个间隔
|
||
大家又同时暂停了
|
||
然后再到下一个间隔
|
||
又同时涌入
|
||
加入jitter之后
|
||
我可以对这个间隔时间
|
||
做一个正负15%的抖动
|
||
这样可以将这个分布
|
||
打得更加均匀一点
|
||
第四个要素就是
|
||
dead letter queue了
|
||
所谓死信队列
|
||
retry这里
|
||
我们最好设置一个
|
||
最大的重试次数
|
||
一旦超过这个次数之后
|
||
你可以当做
|
||
你的后端这个PSP
|
||
已经宕机了
|
||
你就不要再进行retry
|
||
你应该把这个消息
|
||
放入这个死信队列
|
||
然后去进行一些处理
|
||
比如说你本地
|
||
做一个整体的回滚
|
||
通常可能还要再
|
||
熔断一段时间
|
||
那么对于外部的PSP来说
|
||
因为你这里不断的在重视
|
||
所以外部的PSP
|
||
也要去做
|
||
这个de-duplication的操作
|
||
那么这样一来
|
||
它代表着你这个幂等键
|
||
也应该同步的
|
||
穿透到外面的PSP去
|
||
这样至少也能
|
||
增加一道保险
|
||
等PSP返回消息
|
||
提交成功之后
|
||
就可以先给用户
|
||
返回一下信息了
|
||
比如说你告诉用户
|
||
“已经下单”
|
||
“等待确认”
|
||
然后PSP里面
|
||
会进行一步的处理
|
||
通常来说
|
||
我们会给PSP
|
||
一个callback URL
|
||
PSP处理完这笔支付
|
||
会调用这个URL
|
||
通知我们
|
||
但是如果这个PSP
|
||
调用这个callback URL
|
||
失败了
|
||
它没通知到我们
|
||
对吧
|
||
网络还是有抖动
|
||
所以这个时候
|
||
你还要再补上一个轮询
|
||
超过一段时间
|
||
没有收到这个callback
|
||
那就是主动查询一下
|
||
当PSP处理完之后呢
|
||
这状态机
|
||
就应该进入这个success
|
||
或者是fail
|
||
得到一个固定结果
|
||
然后把这个结果通知用户
|
||
那如果这里进入success
|
||
就代表着扣款成功了
|
||
那这个时候
|
||
你应该就要去写这个ledger
|
||
这个里面又会涉及到
|
||
对账户 交易和分录的建模
|
||
所以也是一个比较复杂的系统
|
||
一般来说
|
||
行业的标准是
|
||
商务的实体要采取复式记账(double-entry bookkeeping)
|
||
也就是说
|
||
每笔交易至少要
|
||
影响到两个账号
|
||
产生一组
|
||
金额相等 方向相反的记录
|
||
这里非要扯一下的话
|
||
你应该考虑到ledger的金融属性
|
||
账本这种东西
|
||
一旦你写入之后
|
||
就是不可变的
|
||
所以这个ledger
|
||
通常应该写入到一个
|
||
append-only的数据库去
|
||
这里除了你能想到的
|
||
关系型数据库之外呢
|
||
通常来说
|
||
对于这种specific domain
|
||
你可以去猜一下
|
||
问一下面试官
|
||
是不是应该有一个
|
||
专用的技术栈
|
||
那ledger这里
|
||
确实是存在ledger使用的数据库
|
||
比如说amazon会有一个QLDB(Quantum Ledger Database)
|
||
或者是Alibaba
|
||
开源的ledgerDB这种东西
|
||
他们都提供了SQL接口
|
||
然后专门为金融事务
|
||
进行了优化
|
||
这种专业优化过的数据库
|
||
通常来说
|
||
开发难度会比较低
|
||
然后很多你需要的功能
|
||
都是已经内置好了
|
||
比如说审计啊
|
||
或者是加密之类的
|
||
最后一步就是进行对账了
|
||
因为任何在线链路
|
||
都可能遇到bug
|
||
所以银行这里
|
||
应该定时发过来
|
||
这个settlement file(结算报告)
|
||
我们可以每天执行一次
|
||
对账任务
|
||
如果有问题呢
|
||
那就可以触发一个自动补偿
|
||
或者是转到人工进行审核
|
||
这样一来
|
||
应该就是这个完整的支付流程
|
||
你看这个流程有问题吗
|
||
其实还是有的
|
||
你记得这里
|
||
我们补了一个轮询
|
||
有一笔交易一直在审核
|
||
然后商家这边
|
||
等不到这个callback
|
||
于是开始进行轮询
|
||
轮询几次
|
||
到达这个最大上限
|
||
然后写入了一个fail
|
||
fail了之后
|
||
PSP这边突然发现
|
||
交易过了
|
||
于是这个PSP
|
||
调用了这个callback
|
||
那这个时候
|
||
就应该写入一个成功
|
||
对吧
|
||
这个就叫做状态机的跳变
|
||
它也不是不能解决
|
||
这里我们可以使用一个
|
||
单调状态机
|
||
一旦你这个状态进入fail之后
|
||
就不能再覆盖成这个success
|
||
或者说我这里
|
||
打一个版本号的补定
|
||
每次进行更新的时候
|
||
我要去比较这个版本号
|
||
那最差的情况下
|
||
你还可以等到
|
||
这个日终的对账环节
|
||
总之你的账不能出错
|
||
但是这个问题的根源在于
|
||
你每次状态机的变化
|
||
实际上是对于这个
|
||
paymentDB的一条记录
|
||
发起了一次UPSERT
|
||
用UPSERT这个语句
|
||
覆盖之前的状态
|
||
但是这个问题也不大
|
||
因为大部分PSP
|
||
其实都是这条方案
|
||
一张表去维护
|
||
这个实时的操作状态
|
||
另一张账务表
|
||
会负责这个资金的守恒
|
||
这样一来
|
||
它开发成本也比较低
|
||
维护成本也低
|
||
方案本身呢
|
||
也比较成熟
|
||
也是合规的
|
||
但如果你要进一步呢
|
||
其实这里确实是存在
|
||
另一种方案
|
||
之前我们也讲过一些
|
||
数据库和流系统互换的案例
|
||
有过这么一篇
|
||
《Turning the database inside-out》
|
||
我们在这里去掉这个数据库
|
||
然后采用一个event store
|
||
event store呢
|
||
可以使用Kafka
|
||
或者是Apache Pulsar
|
||
之类的流系统
|
||
也有可能是一个
|
||
append-only的db
|
||
当然你也可以两个都使用
|
||
那这样一来
|
||
所有的变更
|
||
都作为一个事件
|
||
写入到这个event store里面
|
||
从这个event store
|
||
作为source of truth
|
||
在我们再通过
|
||
projection或者view的方式
|
||
来生成视图表
|
||
加速查询
|
||
事件一旦写入呢
|
||
就不再更改
|
||
任何的纠错
|
||
以新事件的方式写入
|
||
进行冲正
|
||
不少互联网公司
|
||
其实都会采用
|
||
这种ledger系统
|
||
比如说stripe用过
|
||
Coinbase用过
|
||
Square也用过
|
||
都是一个不可变的账本
|
||
再加上事件流的形式
|
||
这样一来
|
||
你既可以获得一个
|
||
金融系统的正确性
|
||
也可以获得一个
|
||
互联网系统的可拓展性
|
||
但它的代价也比较明显
|
||
这里有一个比较高的
|
||
系统复杂度
|
||
那开发和运维的成本
|
||
也比较高
|
||
团队本身呢
|
||
需要对流系统和
|
||
金融系统都比较熟悉
|
||
具体怎么选型
|
||
还是要看你的场景
|
||
一旦你接受了
|
||
这个流系统的这种设定
|
||
那其实这个系统
|
||
可以产生很多的变化
|
||
比如说
|
||
我将这个消息队列
|
||
放到前面去
|
||
进行一下削峰填谷
|
||
同时进行数据落盘
|
||
那这样一来的话
|
||
Payment Service
|
||
作为一个Broadcast
|
||
把你每次的事件
|
||
投放到不同的数据库去
|
||
别的结构可以不变
|
||
每次对账的时候
|
||
你可以在消息队列的前端
|
||
进行事件的重放
|
||
重新计算一下
|
||
如果你最后还有时间的话
|
||
我建议还是做一下
|
||
show off
|
||
给你的面试官录一手
|
||
比如说这里
|
||
我们可以在Payment Service
|
||
前面插入一个Risk Engine
|
||
去做一下Fraud Detection
|
||
欺诈检测
|
||
其实有很多的方案
|
||
不一定一上来
|
||
就要做什么机器学习
|
||
那最简单
|
||
你可以说
|
||
我使用一个规则引擎
|
||
比如说我加入一个规则树
|
||
或者是黑名单
|
||
白名单这样
|
||
那这种方法比较简单
|
||
门槛也比较
|
||
也便于合规和审计
|
||
但是呢
|
||
它的问题就不太适合
|
||
比较复杂的欺诈手段
|
||
那另一种比较常见的是
|
||
我使用一些统计学的方式
|
||
或者是直接上一些
|
||
简单的机器学习模型
|
||
那这类的方案
|
||
通常会受限于数据本身
|
||
对于新的欺诈手段
|
||
反应会比较慢一点
|
||
而且你也需要
|
||
手动去寻找特征
|
||
标注一下数据
|
||
大的公司
|
||
可能会使用无监督学习
|
||
来解决冷启动
|
||
或者零样本的问题
|
||
但是这种方案呢
|
||
也有一定的误报率
|
||
需要人工介入进行审核
|
||
infrastructure的支持呢
|
||
你可以上一些图模型
|
||
或者GNN这样的手段
|
||
来捕捉比较复杂的形式
|
||
这类系统的维护和开发
|
||
都会比较复杂
|
||
模型的推断和开销
|
||
也会比较大
|
||
但是金融风控力
|
||
还是比较常见的 |