互联网账户系统如何设计(上篇)?

在很多互联网公司业务发展的早期,业务模式比较单一的情况下,涉及用户账户资金交易相关的逻辑也比较简单,但是随着公司业务模式的不断创新及类型的多元化发展,会渐渐发现现有系统账户逻辑越来越雍肿,不仅难以支持新业务的扩张,对现有业务的支持也适配困难,最终导致新业务系统不得不重新搭建自己的业务账户逻辑,造成重复建设不说,也往往给后续的财务资金核算造成混乱。

以某互联网A租车公司的业务发展路径为例?

阶段A

A公司在早期开展租车业务时根据用户使用场景规定用户必须在缴纳押金以后才可以租车,并且支持用户进行余额充值,余额可以支付租车费用以及购买相关优惠产品。所以账户资金流是这样子的:

通过上述设计基本上就满足了简单的业务需求,用户缴纳押金单独存放在一个押金账户,用户的每次押金冲退都记录账户流水(缴押金记+,退押金记-);用户余额充值单独存放在一个余额账户,用户的每次余额充值、消费、退款都记录账户流水(余额充值记+、余额消费记-、余额退款记-)。

事实上,以上账户逻辑的设计基本已经能满足业务早期的发展的需要了,并且如果账户流水记录完整(例如记录必要的业务类型,如余额购买了一张租车次卡)那么后续也能基本满足早期业务的财务核算需求。遗憾的是,很多公司在类似以上简单账户逻辑的设计上都比较混乱,如有的公司将账户直接绑定在用户信息表上、有些直接更新账户余额,没有完整记录账户流水或账户流水记录业务信息缺乏等,这种情况即使业务没有多元化发展,也很难满足后续业务逻辑的扩展,特别是会造成严重的财务数据核算困难,更不用谈业务多元化发展后如何能够快速支撑了,造成这种问题的原因是多方面的,这里也就不在赘述。

下面我们继续看A公司租车业务的发展演进情况!

假设在A公司租车业务发展过程中为了鼓励用户进行余额充值,采用了充值+返现的形式进行活动,如:“充值100赠送20”,此时用户余额账户的总金额应该是120,那么账户逻辑如何支持呢?

这里注意,之所以需要区分余额中真实充值和赠送的原因在于,如果产品逻辑允许余额退款,那么清晰地区分了真实充值和赠送所对应的余额的话,退款逻辑的实现将会比较简单,否则就会变得比较痛苦,并且不清晰的逻辑也会增加造成公司资金损失的风险;另外如果余额返现账户变动流水记录得比较明确的话,对财务后续的收入核算也会方便很多。

但是,是否这样就能满足业务需求了呢?

显然,这样还不能让逻辑完全运行起来,因为增加了账户相应地交易逻辑与资金逻辑都需要进行相应的改变才行,以上业务场景中原来余额充值只需要调用余额账户记账一次,现在需要根据充返逻辑再调用余额返现账户记账一次;而余额消费则需要根据业务规则进行余额消费记账,假设业务规则为“余额消费优先扣减余额返现账户,再次扣减余额账户”,那么系统交易及记账逻辑如下图所示:

从逻辑上看业务交易系统需要根据业务规则多次调用余额账户及余额返现账户进行记账,并且需要从流程上保证两个账户记账调用的事务一致性,例如一笔消费订单金额为20元,此时余额账户余额为10元,余额返现账户余额为5元,在优先消费返现账户金额扣款5元后无法再从余额账户消费15元时,交易失败后需要回滚余额返现账户消费逻辑,余额返现账户“交易冲正 +5”。

阶段B

在阶段A中,单个业务会根据不同的产品设计进行账户逻辑的迭代,增加余额充返账户后虽然从账户逻辑层面只是增加了新的资金账户,但是交易逻辑却是进行了较大的变更和调整;如果此时该业务场景又出现新的逻辑变化,例如某一天该租车业务针对某些信用良好的用户进行免押金用车活动,并且支持这类用户在退押金时可以选择将押金的全部或部分金额进行余额充值,那么在流程设计上还会存在账户转账的情况(押金账户->余额账户)。

每次产品业务的迭代涉及用户资金逻辑,都不免会影响交易逻辑及账户逻辑本身,但如果业务品类单一,这种迭代及扩展通过硬编码方式多少还能继续支持。但是,如果随着公司业务向多元化发展,问题往往就变得复杂了。

假设A公司在主营租车业务发展态势进入到趋于平缓的阶段后,为了扩展业务范围需要尝试新的业务,例如,某团队提出不能仅仅只搞租车也得弄个网约车平台,那怎么弄?

 

首先肯定是需要先集结队伍啦。集结完队伍就需要好好分析分析下业务场景了,我们先大概看看一个网约车平台的大概业务场景是什么样子的,其中涉及的资金交易的流程应该如何设计呢?

在A公司的租车业务中,从参与角色角度来看涉及的逻辑并不算太复杂,只有“用户、车、租车公司(内部可称租车业务线)”,而从交易场景上看,用户缴纳押金、预存余额及余额消费都只是单向的C->B交易模型,如果不考虑公司层在线交易账户体系(这里是指公司层面的交易账户)业务复杂度还不算十分复杂,并且在这种单向业务模式下,没有公司层面的在线交易账户本身并不影响业务流程,收入核算只需要线下计算即可,这也就是为什么前面会特意强调账户流水业务关键信息不能缺失的原因了。

而约车业务则是多向的C->B-C-B的交易模型,因为从参与角色上看除了普通打车用户外,还有司机、打车平台都会紧紧地参与到整个业务流程中;而从账户资金流上看用户支付的车费不会以C->C的模式直接支付给司机,而是会由打车平台代收,打车平台扣除订单抽成后剩下的车费才会打到司机在打车平台开的账户上,司机才能从个人账户提现。

从上图的分析中我们可以看到,我们需要为普通用户、司机账户、打车平台分别设置必要的账户逻辑,普通用户账户逻辑与之前的租车业务比较类似,用户可以直接支付打车费用、也可以通过余额充值后使用余额支付打车费用;而平台则需要代收用户的打车费用并且需要按照服务规则从代收的打车费用中扣掉部分服务费,然后通过代收/付平台账户将车费实时结算给司机端收款账户,司机通过个人收款账户发起提现后经过结算账户完成提现。资金流如下:

此外,为了满足产品逻辑的扩张,例如要具备冻结司机账户的业务功能,则需要设置冻结账户;平台为了进行市场营销活动,如发放红包则需要设置平台市场营销账户等。

阶段C

业务发展到这个阶段,初步看好像并没有太多的逻辑变动,并且看着只需要扩展下之前租车业务的账户逻辑就好了。但真的是这样吗?

事实上从单纯的产品逻辑来看,同一套个人用户账户貌似是没有什么问题的,但是根据很多互联网公司业务发展的路径来看,不同的业务线根据发展情况不同往往会分别设置不同的法律主体,而且根据业务性质的不同监管层面的政策也是完全不一样的,例如在国内运营的租车业务司机车费代收代发这类业务是要求运营公司具备支付牌照的,没有则会牵扯到非法二清这样的法律风险,而一般来说在没有支付牌照又想继续运营的话,替代方案目前主要是采用银行资金托管的方式,即用户资金通过银行三类账户进行托管。

一旦涉及这类业务,整个系统的业务复杂度会成倍地增长,所以如果采用同一套个人用户账户的话,资金流将会变得难以拆分,对整个系统的升级也会造成比较大的困扰。

另外如果除了租车业务、打车业务外又尝试了别的新业务,如直播之类。业务类型完全不同,且财务本身就要求进行分类的话,只能重新设计新的账户逻辑了;但,从某种角度看这类账户逻辑实质上又是与之前业务存在共性的。如直播类平台也是普通用户充值,购买平台礼物后打赏给主播,此时平台会对用户赠送的礼物抽成后将其转换为可提现的余额结算给主播账户,这类账户逻辑与约车平台其实是很类似的。

那么,是否存在既能统一财务数据又能良好地支持业务的横向扩展相对通用的账户系统模型呢?

 

接下来继续和大家探讨一套可以持续扩展的业务账户系统该如何设计?

业务模型

首先我们分析下大多数在线资金业务涉及的逻辑实体,用户是第一存在,但是用户根据参与的性质不同又分为普通消费端用户、普通服务端用户,拿打车来说一个普通打车的人属于普通消费端用户,而司机个人则属于普通消费用户,并且司机身份也是可以转换为普通打车用户,另外就是平台用户,是指公司内部各个不同的业务主体,它们关联的法律主体可能是同一个也可能是不同的。

所以综上所说,我们需要的可能是一套“为不同公司主体下,不同业务的同一个/不同用户提供不同账户交易逻辑支撑,并且可以满足业务及用户平滑扩张的系统”。

事实上要达到这样的效果是很难的,需要在系统平台层面进行良好地系统及业务架构设计,并且确保在制定业务规则时遵循一定的制度及规范才行。

以下图示为目前业内相对比较完整的通用账户体系模型,俗称“三户模型”,最早是电信行业为适配复杂通信业务场景而设计的一套账户体系模型;而大部分互联网公司业务的复杂度是低于复杂的电信业务的,所以在这里我们对此模型进行部分改进,以期形成适应互联网公司业务发展的通用账户体系模型。

在上述模型中信息被划分成了三个类型:客户、用户、账户。客户是用户身份信息的承载实体,例如张三这个人是一个客户;而客户也不仅仅只是针对个人,针对业务线所关联的法律主体也划分在客户的范畴,如某某打车公司。而有了基本的客户信息后,企业客户具体可以开展什么业务,普通个人用户是否使用了该企业客户提供的服务,在模型中是采用用户这个概念来承载的。企业客户开展该业务时根据业务的设计需要开通什么平台账户,普通个人用户使用该业务服务需要开通什么样的个人账户都可以根据业务的设计通过用户下设立相应地账户进行隔离区分。

假设此时A公司的租车业务与打车业务法律主体尚未进行拆分属于同一家公司,但是财务上要求隔离两类业务的资金流,那么可以在账户系统上为租车业务开立租车业务用户,如果张三使用了租车业务则为张三设置租车业务用户并在该用户下开立余额、余额返现、押金三类账户并配置业务及记账规则,此外若希望业务资金在平台上也有个完整体现也可以在租车业务用户下设立相应的平台账户,只是业务流程上可以采用缓冲或异步记账的方式。

而打车业务则需要根据普通客户信息为普通打车用户开立相应的个人账户,若是司机则需要开通司机相关的业务账户,而平台也需要开通相应的平台账户。在信息流上,客户信息为所有业务所共用,用户信息则是根据不同的业务设置,账户是根据业务挂在相应地业务用户下。如若各业务间没有横向地联系,各业务层账户体系根据自身业务分别运行、互不干扰,而如果存在联系,如租车余额可以进行打车,则可以设计为允许业务层间账户的互转,只是这种资金流会更复杂,需要配置的记账分录也会更加复杂。

以上述模型的定义而设计的账户系统会初步形成一个具备支持多类业务账户逻辑并行的通用中台账户系统雏形,从财务角度看账户层次会相对清晰。另外,图中还定义了机构的概念以支持总公司-分公司这样具备层级关系的财务核算需求,当然这种情况在互联网公司的扁平化模式下并不常见,所以可以暂时忽略。

本篇通过业务场景举例从业务模型上大概阐述了互联网账户系统如何设计得相对通用和清晰,事实上在系统设计上也需要进行更多的设计,并且需要根据公司实际业务情况进行一定的取舍。

引用:https://mp.weixin.qq.com/s/wL4wx9tnYHFeLYyR2yw4zg

原文地址:https://www.cnblogs.com/blue85/p/11653189.html

时间: 2024-10-04 06:20:28

互联网账户系统如何设计(上篇)?的相关文章

电商峰值系统架构设计--转载

1.1 系统架构设计目录 摘要:双11来临之际,<程序员>以“电商峰值系统架构设计”为主题,力邀京东.当当.小米.1号店.海尔商城.唯品会.蘑菇街.麦包包等电商企业,及商派.基调网络等服务公司,分享电商峰值系统架构设计的最佳技术实践. 自2009年11月11日,淘宝商城(现名天猫)拉开网购狂欢节的序幕,各大电商的促销浪潮此起彼伏.此时的电商大战不仅是价格之争,更是技术的较量.如何设计电商峰值系统来更好地满足用户蜂拥而至的访问,如何在海量数据处理中实时发现有效信息并转化为商机,成为众多电商企业密

支付系统中,账户体系的设计与记账处理

账户体系和会计的设计是整个支付系统的底层基础,是支付系统在基础支付服务的基础上,为个人用户及企业商户提供的对于资金收.付.管的服务.本文所说的账户体系定义所有的操作均以交易的形式发生,但从金融核心系统的发展来看,将由以交易驱动转变为以用户为中心的按照产品进行管理的账户体系. 一. 交易模型 前文说道,本文所说的账户体系定义所有的操作均以交易的形式发生,即账户的变动均基于交易而发生.对于账户的处理,需要依据业务,结合相应的产品体系,建立交易模型. 如下: 产品:如B2C网银.B2B网银.快捷支付.

IM系统架构设计之浅见

背景:除去大名鼎鼎的QQ这款即时聊天工具,还有许多细分行业的IM,比如淘宝阿里旺旺.网易泡泡.YY语音.......恰巧公司产品也要开发一款基于我们自己行业的类IM系统,很有幸我担当了这个产品的架构师,核心代码编写.实现者.下面我近年来从技术上我对IM系统(即时消息的传输,不包括语音,视频,文件的传输)的理解和设计分享出来,浅薄之见,望大家别见笑,欢迎给出批评意见. 一.网络传输协议的选择 目前我知晓的所有IM系统传输即时消息无外乎使用UDP.TCP.基于TCP的http这几种协议中的一种或几种

38、生鲜电商平台-会员积分系统的设计与架构

说明:互联网平台积分体系主要用于激励和回馈用户在平台的消费行为和活动行为,一个良好的积分体系可以很好的提升用户的粘性及活跃度. 一.互联网平台积分体系设计必要性 互联网平台积分体系是一个独立.完整的系统模块,主要用于激励和回馈用户在平台的消费行为和活动行为,通过积分体系可以激发与引导用户在平台的活跃行为,逐步形成用户对平台的依赖性和习惯性,提升用户对平台的黏度和重复下单率. 积分体系在保持系统独立性的同时,又与平台会员系统.商品系统.订单系统等具有紧密的关联性,积分体系的规划设计需与平台其他系统

互联网金融系统技术沙龙:小米风控实践

导读:最近上映的 魔兽世界有一句话"光明源于黑暗,黑暗涌现光明",和互联网金融的安全风控领域非常相似.在 6 月 19 日,微博商业产品部联合小米支付等金融技术团队策划了首届互联网金融系统沙龙,围绕在互联网金融过程中碰到系统安全等问题与业界展开分享及交流.本文是邓文俊在沙龙上的演讲,授权高可用架构首发. 邓文俊,小米高级研发工程师,2013 年加入小米,参与了数据后台,风控系统,支付等系统的研发工作. 我来自小米支付,今天分享的主题是小米风控实践.为什么选风控这个题目?其实在我看来风控

电商抢购秒杀系统的设计_1_应用场景分析

电商抢购秒杀系统的设计_1_应用场景分析 概述 所谓知已知彼,百战不殆,在开始详细介绍实战中的抢购秒杀系统时,我们了解一些抢购秒杀系统系统面临的尴尬与难点.另外需要说明一点,下面的内容都是在工作中慢慢总结得来,我们团队也是慢慢摸着石头过河,甚至最初的的架构设计并非是抢购秒杀系统. 评估系统处理能力 理论基础:LNMP的并发考虑与资源分配 虽然有基础去评估我们应用系统的处理能力,但是电商购买的业务流程挺复杂,从登录,商品详情,购物车,填写收货地址,选择支付方式,创建订单,完成支付,以及隐含的定时服

简洁常用权限系统的设计与实现(一):构造权限菜单树的N(N&gt;=4)种方法

权限系统,Web开发常见标准子系统之一.结合自己的一些思考和实践,从本篇开始权限系统的设计与实现之路. 最近,重构了项目的权限菜单构造过程,向前端返回json格式的权限树. 这一篇,只是大致介绍下这个问题,并给出4种方法的整体思路,后续再分别详细介绍这4种方法,再往后介绍完整的权限系统的设计与实现. 权限表的结构: acl.parent_acl, 最重要的就是这2个字段,有了这2个字段,就可以构造一棵树了. 前端需要的json格式: "data":[{ "acl":

[译]搭建账户系统

原文地址:Building account systems 原文作者:Mike Hearn 译者:shawnchenxmu 校对者:undead25 DeadLion 搭建账户系统 Troy Hunt 近期发表了一篇题为『新时代的认证指南』的博文.文章对于「你的网站应该使用什么样的密码规则」给予了很多实用的建议,而通过参考权威机构的建议总是有助于说服同事或老板. 我在 Google 工作期间从事过的一个项目就是他们的统一账户系统(特别是反劫持).大多数网站都会有一个登录系统,阅读 Troy 的文

构建账户系统

最近项目需要,自主构建一套账户系统,总结一下需要注意的问题.账户系统技术上不难,但是里面涉及到多种状态与交互,工程性比较强. 这里只考虑用邮箱注册的情况,登录名即邮箱. 1.安全问题.首选https. 2.注册,激活,登录,登出,找回密码,重置密码,重新获取激活链接,注销(暂时不做),获取用户信息. 3.设计是规划好错误提示信息和错误码 注册:邮箱已注册, 邮箱已注册,未激活 注册成功,请打开邮箱激活, 系统错误 激活:激活成功, 激活失败, 该用户已激活, 激活码过期. 登录:用户或密码错误(