金融系统

金融业务

系统特点

场内交易

场外交易

绝大部分的金融交易都发生在交易所外,也叫场外交易

金融资产一旦被资产证券化,也属于场外交易

在场外交易的时候没法被动地发现价格,那么就只能主动发现价格了。所以对于场外交易的金融产品来说,你需要独立计算出合同的价格

信贷类

C端支付业务

鉴权

sequenceDiagram
  买家 ->> 三方支付公司: 姓名|身份证|卡号|手机号
  三方支付公司 ->> 买家开户行: 姓名|身份证|卡号|手机号
  买家开户行 ->> 买家: 验证码
  买家 ->> 三方支付公司: 验证码
  三方支付公司 ->> 买家开户行: 验证码
  买家开户行 ->> 三方支付公司: token
  三方支付公司 ->> 买家开户行: 拿着token进行所有合法的操作

拉取支付状态

stateDiagram-v2
  direction LR
  买家 --> 三方支付公司: 定时拉取状态
  三方支付公司 --> 买家: 通知支付状态
  买家开户行 --> 买家: 通知支付状态

跨行本币代收/代付

2022122515713

汇总

外汇做市商,一般是巨型的跨国商业银行,跨国商业银行有不同国家的大量储户,手上就拥有不同币种的巨额存款,做市商之间通过交换不同币种的大额固定利息存折来实现外汇交易,但为了对冲外汇市场可能会有的波动导致的账面亏损,机构都会处理外汇相关的市场风险,比如用期货、期权等衍生品来对冲风险

2022122515933

C端支付核心组件

信息流与资金流分离,资金使用权的转移过程就是信息流,资金所有权的转移过程就是资金流

2022122515279

支付环节的非银行参与者只能产生信息流,不能产生资金流

资金流和信息流分开之后,这两者将以不同速度在不同时间的不同主体分开流转,这意味着支付系统从本质上是一个异步处理系统,资金流和信息流的统一具有最终一致性

资金流和信息流最终需要同步,即需要一个核算系统来确认同步过程准确无误

点券系统

sequenceDiagram
  业务系统 ->> 支付网关: 发起交易订单:用户A用10元向用户B购买一支笔并生成支付订单
  支付网关 ->> 支付网关: 处理支付订单
  支付网关 ->> 财务系统: 用户A扣10元
  支付网关 ->> 财务系统: 用户B加10元
  查询系统 ->> 财务系统: 查询余额
  用户 ->> 查询系统: 查询余额

支付系统

20221225154731

异步系统对接时的架构设计原则:将同步系统的一次调用拆分成三个步骤:异步调用、轮询和对账

第三方支付系统

不能管理实际资金,因此都是信息流的处理系统

20221225155547

正确性

输入正确

金融系统的一些外部数据如通货膨胀率率公布后可能会更新,一些业务建立在这些外部数据的计算上,要如何保证选择正确时间的数据

双时序数据库记录数据

数据的可见范围

发生时间指的是数据的真实事件时间,记录时间则是这条数据记录到系统的时间

数据的查询也需要同时提供两个时间,也是发生时间和记录时间,查询的是离当前查询时间点最近(当有多个数据都是合理的时候,选择发生时间最晚的数据)的合理数据(数据既存在,且有意义)

双时序数据库保证了数据不可变、并且是唯一的

过程正确

使用事件溯源架构

基本概念

队列

所有的命令或者事件的处理都要有确定的顺序

20221226164917

执行事件和改变状态

查询

2022122617358

正确性的本质

任何一个时间点的状态等于之前所有事件效果的累积

$$\sum_{i=0}^{n-1}ei$$

结果正确

验证:选择不同的计算环境,这样才能降低和之前计算结果的相关性

在极其重要的场景,一般会验证 3 次,只有在至少 3 个结果完全一样的情况下才会向外输出结果

数据传输

交易数据

既要保证顺序的正确性,也要保证消息处理的一次性

使用限流手段来保护自身的服务器容量不被击穿,一旦上下游之间做了限流,那么整个系统就需要假设数据会丢失

非实时市场数据

非实时数据的传输方式分为订阅发布(Pub/Sub)和消息(Messaging)两大类。在订阅发布的情况下,每个消息的消费者是互相独立的,每个人都需要处理所有消息,并且每个人处理消息的顺序必须是一样的。消息则刚好相反。所有人之间共享所有消息

历史数据是有时效性的,如果所有历史数据对你的价值都是一样高,那么一般来说数据需要尽量完整。相反,如果越接近现在的数据对你的价值越高,那么数据则有可能允许丢失

实时市场数据

由于对延迟要求高,所以不能采用拉消息的模式,像Kafka的消费模式就不行

同时对消息的编解码效率要求也要很高,相比JSON、XML,二进制编解码协议的效率更高,如金融行业使用的FIX通讯协议,只需要传输数据变动的部分

20221227105457

数据存储

系统优化

吞吐量优化

互联网里的“快”,指的是服务器集群的处理能力快,能同时处理很多东西,即吞吐量大

使用高并发的优化手段

延迟优化

吞吐量优化是系统能力的横向扩展,是宏观资源的调配。而延时是系统能力的纵向扩展,是微观资源的调配

特殊优化

合并存储

把事件和前后两个状态都保存在一起,历史查询就变得非常简单。由于现在每个事件都有对应的前后状态,我们只需要寻找离查询时间最近的事件就可以了。找到了对应的事件,我们就可以找到对应的状态

20221227155549

对账优化

  1. 前一个事件的最终余额等于下一个事件的初始余额
  2. 每个事件的最终余额等于这个事件的初始余额加上事件变动金额

这样对于任何一个用户的任何一个状态,我们都可以顺着链条找到所有金额变动的过程,并对这个过程进行校验

支付系统设计

聚合支付:

stateDiagram-v2
  订单服务 --> 支付服务
  支付服务 --> 支付宝
  支付服务 --> 微信支付
  支付服务 --> 银联支付

表设计

批注 2020-04-06 114716

整体流程

sequenceDiagram
  订单Web ->> 订单服务: 下单
  订单服务 ->> 支付服务: 发送订单
  支付服务 ->> 订单服务: 支付令牌
  订单Web ->> 支付Web: userId,orderId,支付令牌
  支付Web ->> 支付服务: 完成支付