用户账户

在去年的时候做了用户虚拟账户的设计，后来接手订单后，
断断续续订单出了很多事情，相反账户好像很稳，
就算在订单出现问题的情况下，也没有让公司产生损失，总结下账户的一些情况。

基于TCC的账户设计

账户本身是个金融性很强的操作，公平和稳定才是最大的成功，两段式提交可以尽量保证账户的稳定性。并且就算再出现情况下，也不至于让公司损失资产。
因为账户本身是依赖订单的成功性的，在最终一致性的要求下，需要有可变的账户流水状态进行预扣和返还，同时流水还需要记录账户的变动，包括总金额、每个账户的当前余额、消费额度、以及期末余额，不要觉得没必要记录那么多，当排查问题的时候，你会发现很多好处，记录一目了然，就算真的出现问题，重新扣回来也不是问题。

预扣款：当下单时，订单服务会发送相应的扣款金额，扣款账户等进行预扣款。
扣款：当订单成功时，订单服务会发送相应异步消息，收到消息后，对相应的订单服务进行二次确认，在一系列确认完成之后，进行变更状态操作，这个时候才能算一笔流水成功入库，继续通知相关业务服务进行下一步操作。
返还：一般预扣款之后，会有延迟任务进行返回操作，比如1分钟内，如果订单还是未被确认的，就需要再次确认订单服务的订单是否还是有效订单，把相应的钱款返回到账户，当然这里和订单机制有关，有些系统的设计是订单有效期内，下单还是会返回当前订单的，这里就需要相应的服务进行方案确认了。

预扣款的时候排队扣款问题：预扣款应当是同步和幂等的，不会对相同的订单重复扣款，对于用户来讲扣款应该是有序的
扣款：扣款应该是经过准确校验的、幂等的同一个订单不能扣款两次
返还：返还的时候必须要确认订单的相关信息，看看到底是返还是扣款，同样这里也是需要幂等的

当然还有很多的账户功能，就不在这里做叙述了，主要是为了描述一些TCC的设计。

订单和账户的对账

对账可以帮忙发现很多问题，不管是订单的还是账户，如果两边收入支出不平衡，可以发现一些错误的订单或者账户流水。
可以发现问题的方式都是好方式，不管是从财务上还是从技术本身。
对账就需要设计相应的流水记录，每个项目的对账方式可能都有不同的地方，所以在设计账户流水的尽量将对账的相关考虑进去。

报警和日志

相关的报警和日志还是比不可缺的，没有相关健全的保障措施，会让查找问题和排除等有很大的局限性，没有及时发现问题的措施，会让损失持续扩大化，可能最后不得不停服务采取这样的措施来解决。