@HarrisonHDU
2016-06-08T09:14:08.000000Z
字数 553
阅读 1029
用户账户系统初步框架
工作
账户结构
| 账户类型 | 入账渠道 | 出账渠道 |
|---|---|---|
| 余额账户 | 充值，被打赏 | 打赏，申请提现 |
| 奖励账户 | 系统奖励 | 打赏 |
| 冻结账户 | 申请提现 | 提现成功 |
- 每种账户类型存在一张流水表，每次交易发生都对涉及的账户记录流水
- 理论上，每个账户 每日期初余额 + 入账 - 出账 = 每日期末余额
- 可以通过上述试算平衡公式，审计资金账户流水，虽然审计起来比较繁琐，但一定能发现问题源头
相关交易流程
- 用户账户初始余额，这个就根据运营策略了，技术上没啥好说的
- 账户提现，当点击确认提现时更新冻结账户余额，也没啥好说的
- 打赏功能（账户余额足够的前提下），只涉及到我们系统内部的两个账户一增一减，也没啥好说的
- 重点在于充值和充值后直接打赏。考虑到实现成本，选择了Ping++第三方服务聚合不同支付渠道
上述客户端发起的支付请求既可以是充值，也可以是充值后直接打赏。这会在服务端收到异步通知支付结果后进行不同处理
工期预估
| 功能 | 工期/天 | 备注 |
|---|---|---|
| 账户基本结构搭建 | 0.5 | |
| 提现账户管理+账户密码设置 | 0.5 | 需要研究下能否在支付宝充值后直接获取用户账户信息；支付宝授权接口 |
| 交易流水 | 1 | 梳理各种交易类型，抽象简化各种交易方式，考虑数据量大时的性能问题 |
| 提现 | 3 | 客户端接口 + 后台审核操作 |
| 充值 | 2 | 对接Ping++的各种渠道 |
| 打赏 | 1 | 各种对象的打赏列表 + 资金流转 |
| 其他 | 0.5 | 推送 + 通知 |
总天数 = 8.5 * 1.5 = 13天
