万里赴戎机，关山度若飞。
1 前言
账户体系是一个应用系统的基石，在完整健全的体系之上可以开展各种各样的业务，账户不同于用户系统，用户是系统中的一个实体，可以具体到一个人，同一个人可以有多个账户，账户一般会涉及到转账、出账、入账、提现等业务内容，如前文所述的红包业务和积分发放业务，其中都会涉及到账户的操作。而用户一般是涉及个人信息的操作，
2 理解账户
账户一般按照用户类型分为 B 端和 C 端， C端用户一般指的是消费者， B 端一般指的是商户账户和其他业务账户（跟商户主体相关的结算账户和应用系统级别的账户)。下面是两种账户的特点：
css
1 C端账户
用户数据总量大，用户的活跃性遵循 28 分布，通常需要对用户数据进行分库分表。
2 B端账户
B端账户的用户数量小，用户间的数据量区别和特征悬殊，通常还存在热点账户的问题，账户的访问频率低，通常统计性的工作比较多。
在之前的业务中，已经介绍了红包和积分分发的业务，其中红包的业务涉及到了 C 端用户的出账和入账，积分的分发同时涉及到了 B 端和 C 端的交易逻辑。在这个过程中，为什么需要将 C 端的账户和 B 端的账户进行分离，这个需要从业务上来理解。前文我们已经分析了C端和B端账户的特点，分离这两种账户，可以使得业务更加聚焦，同时也为提高其性能打开了空间。C 端账户需要考虑用户高峰和分库分表的问题，而 B 端账户需要考虑热点账户和分布式计算的问题，这两者可以单独建立微服务，对外提供相应的接口即可，职责单一可以很方便的提高其性能，同时也在业务高峰期进行扩容。
分离了 C 端和 B 端的账户服务有很多的好处，同时也带来了一些问题，比如分布式事务的问题，需要在账户服务上建立一个业务服务来处理诸如转账等业务，需要记录一些包含业务属性的订单或者日志。考虑一下之前已经编写的红包和积分分发，还有后续要加入的订单、优惠券等业务，也需要在业务层进行实现。
3 账户操作
账户的业务已经介绍了，但是账户需要提供的能力有哪些呢？
通常情况下， C 端的业务一般有 出账、入账、转账、提现，如果允许用户欠款的情况，还会有欠款和还款的逻辑，后续还会添加积分到期的业务逻辑，C 端账户内部还需要有处理积分失效的业务逻辑。
B 端账户的业务逻辑相对 C 端会复杂一点，C 端账户数量大， 有分库分表来分担其业务的流量压力，但是对于 B 端，账户数据量相对小，但是会出现批量操作和统计，对于某些热点账户操作的业务还是需要慎重考虑。以批量入账和批量出账为例，可以通过一次操作账户，批量处理日志来解决。对于某些时间段内，大批量的入账操作，可以建立热点账户表，将请求分散到各个子账户中，然后异步的处理这些请求，类似于 LongAddr 的操作，分组计算而后求和。
同时 B 端账户还会涉及到账户冻结和解冻的情况，在这样的业务场景下，特定的资金要有特定的账户，用户需要在确认支付后才可以给商家确认入账。这样的操作是为了从业务上解决资金上的专款专用、延迟确认入账等场景。
4 账户接口
如下图所示，分别定义了 C 端账户的操作和 B 端账户操作的业务接口。
C 端的交易接口包含了账户的出账、入账等业务。当然还有用户的开户操作，这个对于B 端账户也是同样需要的。 
B 端的账户接口相对比较多，因为其业务复杂性导致了其逻辑相对于 C 端比较繁琐，在后续的文章中将继续介绍其具体的实现和业务使用场景。 
5 总结
在本文中，主要讲解了作者对账户的理解和大致的业务场景，从大的方向和逻辑分别定义了其业务接口，在后续的业务中将继续分享其具体的业务逻辑实现和一些关于编程的思考，欢迎各位掘友继续关注。