金融业务架构经验总结

金融业务架构经验之谈:

• 支付
• 资金账户系统

业务场景经验之谈：

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

等等

设计架构

首先，有个概念：

• 金融数据不能删除
• 金融数据更新要保留原记录
• 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