首页 > 其他 > 详细

金融业务架构经验总结

时间:2020-09-07 21:14:54      阅读:58      评论:0      收藏:0      [点我收藏+]

金融业务架构经验之谈:

  • 支付
  • 资金账户系统

业务场景经验之谈:

  • 对账模型
  • 支付
  • 交易
  • 退款(取消交易)
  • 掉单
  • 补录
  • 改单

等等

设计架构

首先,有个概念:

  • 金融数据不能删除
  • 金融数据更新要保留原记录
  • log基于法律考虑要保留3年+

架构图参考:

点融逻辑架构:
技术分享图片
这张是非常常见、典型的逻辑架构:

  • 多个LB 分发到多个http server -- 前面的router看出,这个应该是keepalived的方案。
  • 再往后区分静态内容和session ,这些内容由NoSQL(mongodb or redis 之类)存储,静态内容前有缓存(varnish 之类)。
  • 有多个nodejs cluster 进行业务服务分发。
  • 还有非常重要的是背后的backup。备份机制需要多种(最好同时有)备份机制:
    • slave实时备份
    • 延时备份(防止实时污染)
    • 远程实时备份
    • x天内每小时备份(防止数据丢失快速恢复)
    • x天内每天备份

点融component架构:
技术分享图片
这张非常设计具体业务了,但金融部分仍非常值得参考,如一些component:

  • 支付服务
  • 审计服务
  • 风险管理服务
  • 权限管理服务
  • 备份服务

对账户模型

对账,也可以成为清算。一般为了保证系统的数据的准确性,尤其是金额数据。
金额的走向如下:
用户银行账户--支付--》银行(第三方支付平台)--通知--》内部系统。
所以银行会有流水,我们根据内部系统的支付记录与银行(第三方支付平台)的后台支付记录按流水进行一一核对。
另外,内部系统产生出的流水(transaction),我们通常有后续的步骤,譬如产生现金流cashflow。现金流同样要与内部的流水进行一一核对。
正常运作的时候,应该是有每日清算(不一定是EOD--end of day),保证用户的资产的正确性。有的公司会有更严格的清算处理:每个几个小时进行清算。

冲正

退款(取消交易)

由于某些特殊情况,如用户基于不知情、或账户安全原因(被盗卡),不承认某笔交易是正常交易。--那么就需要系统取消某一笔交易。取消交易时,资金一般可以按资金来路原路返回。
系统因此需要提供取消交易的功能,但不能简单的删除订单,要留下证据,一般可以更新为取消状态。(同时要保留操作记录
注意内部的逻辑关系,一笔已经达成的交易被取消,对应需要emit 一些event进行统计关联的计算数据。--有时类似牵一发动全身的感觉。

掉单

所谓掉单:用户A在第三方(银行/支付公司)支付了,然后在自身系统没有得到更新到用户的资产。
可能原因:第三方一般会一次同步回调或者多次异步回调不成功导致。要么网络有延时或者丢包导致第三方与自身系统网络通讯不成功,要么通知到了,但没处理好,或者没及时处理。
解决方案:

  • 找出未及时处理的原因,fix 之
  • 自身支付服务,接受到回调后,更多次的给自身系统提供多次异步回调。--降低错过的概率,对于部分第三方支付异步回调次数偏少,异步回调时间间隔偏短的问题
  • 搭建自己的DNS服务或者 DDNS ,并部署多机房。
  • 自身主动想第三方查询支付结果,询问支付创建但未完成的支付流水。

改单

改单,一个典型情况是,金额或者状态错了,需要进行对交易流水进行更新。但不能直接更新数据库,而应系统提供功能出来,以防直接改动数据,没触发其他关联数据的更新。这一点与退款类似。

复式记账法

该系统之所以称为复式簿记,是因为每笔交易都至少记录在两个不同的账户当中。每笔交易的结果至少被记录在一个借方和一个贷方的账户,且该笔交易的借贷双方总额相等。该方法发生的每一笔经济业务都要以相等的金额,同时在两个或两个以上相互联系的账户中进行登记。
类似于能量守恒定律,把来龙去脉都记下来.
技术分享图片

系统设计:

账户子系统存储要素应该包含2类表:
一个是账户表(账户余额/状态表)account,主要记录账户基本信息:ID,名称,类目,可用余额,冻结余额等;
另一个是账户流水表(又叫流水明细表)cashflow,记录这些账户所有相关变化的流水记录。

日结表:EOD 日结,应与账户体系隔离,属于清算日结,不要影响主业务。日结做了后,数据不会因为对以往进行修改(也不应该这样处理)而产生偏差。

账户与复式记账
结算相关复式记账的会计科目该如何设计

权责发生制

ref

参考:

连连支付文档
PayPalm支付文档
支付宝文档
支付宝架构
点融网架构

金融业务架构经验总结

原文:https://www.cnblogs.com/no7dw/p/13628873.html

(0)
(0)
   
举报
评论 一句话评论(0
关于我们 - 联系我们 - 留言反馈 - 联系我们:wmxa8@hotmail.com
© 2014 bubuko.com 版权所有
打开技术之扣,分享程序人生!