【支付系统设计从0到1】支付系统账户体系设计（下）

在上一篇里我们主要讲了支付系统的账户体系的产品设计，在这一篇里重点介绍技术设计上需要考虑的一些问题。

产品架构划分

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

上一篇里讲到，账户体系对应的是联机记账的过程，在实际过程中会划分为客户用户信息子系统、账户子系统以及记账子系统。

客户信息子系统技术设计

客户和用户涉及的信息

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

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

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

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

客户信息子系统技术设计

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

账户子系统

账户子系统存储要素

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

账户子系统技术设计

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

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

记账子系统

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