[logseq-plugin-git:commit] 2025-07-04T12:30:11.051Z

pages/Payment Service.md

@@ -1,2 +1,886 @@
+- 金融牌照
 - 平台跳转
-- 商家
+	- 商家-收款方
+	- 用户-持卡人
+	- 中间-卡组织
+		- 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
+- ![image.png](../assets/image_1751630881799_0.png)
+- 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这样的手段
+	  来捕捉比较复杂的形式
+	  这类系统的维护和开发
+	  都会比较复杂
+	  模型的推断和开销
+	  也会比较大
+	  但是金融风控力
+	  还是比较常见的