在银行、支付公司以及电商平台的支付系统中，如果不是只做交易转发，而是真正需要做账务处理清结算，一定会涉及到账户体系的设计，一套好的账户体系应该是与业务无关的。账户体系在银行叫核心系统，在支付公司或者电商平台都是虚拟账户体系。

账户体系涉及的东西

按照经典的来源于电信行业的基于客户、用户和账户的三户模型，我简单梳理了账户体系里可能涉及到的概念如下。

账户信息

1.基本信息:包括实名认证信息、联系方式等等信息。

2.账户信息:比较重要的属性是账户资金/余额，此处的账户资金实际上只是虚拟账户的资金信息，并非实际的资金，实际的资金存放在支付平台在银行设立的银行账户上。而如果是银行的账户体系，则代表实际的对应银行金库里的资金，可以随时通过ATM提取现金。

记账方式

金融机构核心账户/账务的设计一般采用复式记账法。如果要求不高或技术储备有限，也有很多公司直接采用单式记账法。虽然都能满足业务需要，但相对于复式记账法，单式记账法无法从借/贷、科目/账户多维度来进行交叉检验，保证账务核心的平衡。目前也有一些电商平台甚至支付公司采用单式记账法，而银行等金融机构通常采用复式记账法。

会计科目

会计科目是对会计要素对象的具体内容进行分类核算的类目。会计对象的具体内容各有不同，管理要求也有不同。这部分内容我就不详细介绍了，感兴趣的可以专门找一本会计相关书籍进行单独学习。

通常来讲，会计科目分为资产类、负债类、所有者权益类、成本类、损益类和共同类六大会计科目。

系统中具体需要哪些科目及账户，需要对业务场景及业务模式仔细分析后才能确定。

记账过程

为提高交易性能，交易必须与账务分离，以提高交易处理性能和效率，从而有针对性的分块解决复杂业务逻辑。所以，我们在支付系统设计中一般是将记账为分2个步骤，支付成功后系统同步记录流水账，异步通知会计系统做复式记账。

传统的第一代支付系统通常是日终批量记账；现在的流行的支付系统设计通常是异步准实时记账，日终根据银行对账文件，对当日记账做批次结转核对并记录。

所以通常来讲，我们的支付过程与会计记账过程会进行分离。这部分我会另外写文章专门讲解，大家也可以参考支付宝架构中的记账分析过程。

产品架构划分

客户信息子系统技术设计

客户和用户涉及的信息

客户是一个社会化的概念，一个自然人或一个法人（任何社团、组织、机构等，具有社会关系比较紧密，并且有相似消费特征的团体）就称之为一个客户。

自然人一般包括，姓名、性别、年龄、职业、联系地址、联系电话、证件类型、证件号码、电子邮件地址、工作单位、工作性质、职位等等社会属性。

法人客户的概念同样成立，此实体应该包含了法人客户的社会属性的描述。如法人机构名称、证件类型、证件号码、联系人、联系地址、联系电话、法人机构性质等。

用户是客户使用了某种产品或者服务（签署协议）时，产生的一个实体。如果一个客户使用了多个产品，那么就会对应多个用户。

客户信息子系统技术设计

通常来讲，客户和用户信息属于比较静态的数据，数据量也不会很大，即使是微信这样也就几亿用户，可以用单库单表硬撑，在数据库上只需要做主从高可用、读写分离考虑即可，如果有条件，还可以加一个REDIS集群做缓存。对外提供服务的应用直接提供数据库读写操作即可。

账户子系统

账户子系统存储要素

该系统是整个账户体系的核心，在按照产品设计进行会计科目划分后，体现为单个账户，这些账户，具体在系统中落地为2类数据库表，一个是账户余额表(又叫账户表)，主要用来记录账户基本信息：账户ID，名称，会计科目，可用余额，冻结余额等；另一个是账户流水表（又叫余额变动明细表），记录这些账户所有相关变化的流水记录。

账户子系统技术设计

在存储层面，首先需要考虑的是账户流水会很多，而且都是按账户进行查询检索，所以可以考虑按客户号进行水平切分、分库分表，保证在交易过程中尽量只查单表，不跨库和多表联表查询。

在应用设计层面，对外提供单边借贷记和冲正接口，内部提供灵活的产品工厂封装。另外对于一些异步的通知功能如动账短信、告警等，可以使用MQ，异步完成，不影响正常交易。

记账子系统

该系统可以作为一个联机异步或者日终批量系统，可以与账户体系隔离，单独完成会计科目记账和核对。该部分可以采用的技术较多，可以根据各公司具体实际选择。