账户部分在之前我们讲的比较详细了，而且在线课堂也有账户的专栏，所以在此基础上我们来观摩一个实际的账户相关的案例；这是一个大型且高危的项目，危险程度要看涉及到的资金属性、账户数量、资金体量；比如你要是几十万，那闭着眼就做了；但是如果是千万用户，百亿资金情况下，小心脏就要时刻蹦蹦跳了
我们知道企业在发展过程中到了一定阶段，难免需要进行一些系统的重构或者数据的迁移；比如要做中台，那么业务的统一势必要将一些系统下掉，业务以及数据迁移到新的中台服务中去；今天我们要讲的就是“旧账户服务迁移至新账户服务”如何做，如何实现用户无感知的服务迁移
我相信，这个案例可以让你把账户掰开了揉碎了再认识一遍；而且对账户的把控力上升3个台阶；这也是高端面试过程中容易问到的问题，也是一个很容易脑子一片空白哑口无言的题目；当然这个案例也可以作为简历中一个经典的颇具竞争力的实战项目这次我计划采用半讲解半方案文档的模式书写这篇文章；既可以让大家理解，又可以作为半成品文档提供给各位拿来即用；好了，价值讲清楚了，你准备好开始了么......为了构建统一中台账户服务，围绕中台统一账户管理支持各业务线客户账户以及账务处理能力，需要将各业务线分散的账户业务全部切入中台账户服务中心，并且稳定后下线旧账户服务
2.整体方案框架
分期分批，为了确保资金安全，业务正常无停产运转，对于每个旧账户集群采取“兼平切”的方案理念，分阶段，分批次完成整个迁移工作；整个项目分三期完成
第一期：服务兼容
在旧账户服务层兼容新服务层，或者在新服务层兼容旧服务层，或者在新旧服务之上构建新的兼容服务层；这次基于“业务无感知，用户无感知”原则，我们采用第一种方式，在旧服务层内兼容新账户服务
第二期：账务处理灰度切入
先将加入灰度范畴的账户进行账务处理排队，先进行旧账户余额不扣减结转至对应新账户中，然后将结转后的账务处理包括排队中的请求双写入新的账户中
再将就账户的历史账户明细迁移转入新账户流水表中，并进行自洽验证，至此该账户完成了并行双写的账务结转，以此为节点，该账户今后将进行全部账务请求的双写处理
并对该映射账户进行双写校验；对于校验异常的账户进行差错处理，以确保全部最终校验正确
第三期：主次切换关停旧服
3个月以后对于校验正常的新旧账户组关闭旧账户双写，关闭旧账户，直至全部旧账户关闭，全部旧账户服务关闭
推动业务线逐步更换新账户服务，直至前部更换完成，最后下掉旧账户服务
3.方案基本原则
a账务准确：余额准确，明细准确；迁移前后新旧系统以及与实际一致相符b按账户灰度：灰度选择一个城市的全部账户进入灰度账户名单c新旧并行：余额同步至新账户，并行期间依旧旧账户对外提供服务，内部接口同步给新账户，财务数据同时从新账户出具一份d灰度成功后第二批切全部：不进行多次灰度，灰度成功后即执行全部迁入新账户中心e不停服迁移：在旧账户迁移至新账户执行期间进行账务处理排队，结转完成前不处理进账和提现，结转动作完成后按排队顺序进行处理
4.账户结构设计
我们先看旧账户结构，分多类型账户，下设二级类型子账户
我们在看新账户结构，设置三级账户结构，第三级结构记录账户余额与明细
5.新旧余额的核算关系
初始化期初：新余额期初余额=旧余额转入余额=旧余额期末余额期末：新余额期末余额=旧余额期末余额=期初余额+净发生额
6.灰度方案
灰度管理，以账户为维度建立灰度表，灰度表里包含全部旧账户；可以通过灰度表来监控灰度情况以及判断账户是否在灰度中
7.回滚方案
原则上业务层不进行回滚，技术层回滚方案由技术决定；针对出现问题的账户进行人为干预，业务上无逆向执行迁移
8.执行
以上便是整个方案的框架了，后面就按照该方案框架进行详细的技术设计以及执行了；先执行一批灰度账户；3个月后没有问题对全部账户进行灰度；再3个月后没有问题；开始逐步关停旧账户服务
9.复盘
整个项目完成以后，业务，运营，产品，技术等进行大复盘，了解各方业务情况，是否存在其他问题，比如财务记账准确性没有变化，正常结账是否有影响等
365天·从入门到产品专家
扫码或者点击阅读原文访问支付课堂
365天和1.1万+支付产品经理一起学习