【新年第一篇】平台的帐号管理系统设计的设想

 

今天说的是电商平台的帐号管理系统设计，或者是支付平台帐号管理系统设计，或者是充值平台帐号管理系统设计。

 

之前本身也设计过电商平台的帐号管理系统，也涉及了充值这个功能，就是用户充值到平台，而后能够用充值的钱买平台的商品。

那时候本身设计的简单，直接就是用户信息，而后充值信息。用户信息记录用户当前的余额，充值信息记录充值的历史记录。

可是需求老是在变化的，由于要适应不一样场合，系统要发展，并且要跟得上线下的发展，兼容线下的游戏规则。

 

其实用户信息和帐号信息就应该是分开的，一个用户能够有多个帐号，好比说网站帐号，手机客户端帐号，充值帐号，消费帐号等等。有人会说，这么多帐号，有什么用呢，信息都是一个样的，多余吧。我要说的是，这确定很少于，除非你的系统只是个demo。由于真实的系统确定会演进，会升级，会变化，设计这么多的帐号，后面你升级系统，分离子系统，变动需求的时候就会很方便，谁用谁知道哦。

 

经过个人观察，一号店就是这么干的。由于我在一号店网站的帐号和手机客户端的帐号，两个帐号登录用户名和密码是同样的，可是里面的收货地址不是同样的。我在网站保存的收货地址在手机客户端登录以后没有看到，我就又在手机客户端保存了一个同样的地址，而后登录网站发现两个一样的地址，这就说明一号店的网站帐号和手机客户端帐号是两个独立的帐号，尽管使用了相同的登录信息。后来一号店手机客户端更新说明也证明了个人猜测，有一次他们的更新说明写到“同步手机客户端和网站的收货地址信息”。

 

好比说消费帐号吧，记录充值消费变化，这个之后就能够独立出来一个支付系统，甚至是支付宝之类的独立系统。

若是你设计的时候没有作这样的考虑，后面你是不可能分离的，就算分离也会很痛苦，极可能就是从新来一遍，若是你没有认识到这个问题，就算从新来一编，也仍是不能支撑过久，又会须要从新来一遍了。

 

有充值，有消费，就会有结算。

我想说的是，确定会衍生出来一个充值返利的需求，你怎么实现呢？

难道直接把余额信息放大，那就会出现混乱，数据对不上了，看不明白。由于没有地方记录此次的充值还有额外的返利，返利多少，返利的规则是什么。

我要说的是我想到的一个办法，不知道现实中有谁作过相似的设计，确定有系统有相似的需求，还但愿你们赐教。

 

设计一个系统内部结算消费的币种，而后充值的钱和这个币种有某种规则匹配，好比说1:1，或者是1:5之类的比例，这样的话，就能够轻松解决充值返利的需求，并且顺便还能够解决多国货币的需求，由于咱们系统内部消费结算使用统一的平台币，而后外部的任何币种都根据匹配规则换算成平台币来计算。不论是充值，仍是消费，仍是返利，仍是结算，都是用统一的平台币，固然了，平台币对用户是透明的，最终用户看到的是本身的币种。甚至用户也能够有多种币种，都没有关系的，反正平台内部使用的是统一的平台币。