微服务——简单应用钱包服务的设计

• 写在前面：

现在基本上每个APP或者其他网页都会加入用户钱包这一功能，钱包是
一个常见的产品需求，那么本博阐述非金融的钱包或者称为简单钱包的
设计思路和具体实现。

• 设计目标：

业务目标：
    1.用户金额的管理；
    2.用户的出入账记录；
    3.用户的取现保证；
技术目标：
    1.可水平扩展的服务
    2.保证钱包的出入账正确
    3.服务的单一性保证

• 设计思路

表设计：
    1.设计两张表：钱包金额表、钱包出入账表。
    2.金额表维护用户的余额、（可选：总收入、总支出）。
    3.出入账表维护用户的钱包出入账记录。
接口设计：
    1.开放一个增加出入账记录的接口。
    2.开放一个更改出入账记录状态的接口。
流程设计：
    其他服务在业务过程中通过增加出入账记录，这条记录可能是这样的:
    {"id"："主键","order_id":"订单号","owner_id":"钱包账号","target_id":"交易","type":"-1,1，负的支出，正的收入","amount":"交易金额","state":"0未入账，1入账"}
    在业务完成后，通过修改状态的接口对出入账记录进行操作同时修改用户的账户余额。
    这样做的好处是，将修改用户余额的操作放在钱包服务之下，统一进行事务管理

• 常见场景实现：

支付购买商品：
    用户 --> 下订单 --> 在线支付订单成功 --> 写入一条充值记录type=2(充值)，一条用户支出记录type=-1，一条应用收款记录type=1 --> 告诉订单支付成功，检查无误，回调钱包服务，可以操作票款了 --> 钱包更改以上三条记录的状态，同时修改各用户钱包的余额

用户取现：
    用户发起取现请求 --> 创建一笔支出单type=-2 --> 检查无误确认提现 --> 在线打款成功 --> 修改支出单状态，修改用户余额

• 总结：
  本钱包的设计基本满足既定目标，有较好的扩展能力，简单，避免了分布式事务的困扰，尽可能减少了相关业务的侵入，能够支撑非金融应用的钱包大部分需求。同时，通过出入账单可对用户的钱包数据进行发掘，更好的获取用户的消费特征，为其他功能的实现提供数据支持。