金融业务架构经验之谈:
- 支付
- 资金账户系统
业务场景经验之谈：
- 对账模型
- 支付
- 交易
- 退款(取消交易)
- 掉单
- 补录
- 改单
等等
设计架构
首先，有个概念：
- 金融数据不能删除
- 金融数据更新要保留原记录
- 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 日结，应与账户体系隔离，属于清算日结，不要影响主业务。日结做了后，数据不会因为对以往进行修改（也不应该这样处理）而产生偏差。
权责发生制
参考：
连连支付文档
PayPalm支付文档
支付宝文档
支付宝架构
点融网架构