至于属不属于作坊式的阶段我不反驳，流程上肯定是有缺陷的这个我认可，但并不是一个程序员写一个接口做几十亿的系统迁移，如果真的是这样那还需要留 20 号的人在这里干嘛。
这么大级别的数据迁移肯定是一个系统性的工程，并不是1、2个程序员可以负责的，但是迁移程序的发起入口用 1、2 程序员负责足以，中间需要调用 N 个系统的接口配合来完成整体的工作。
问题6 ：我觉得这个错误犯得很低级 日数据量达到几十亿次的应用 居然没考虑到数据量过大迁移耗时太长的问题？平时小项目写个定时器都会考虑会不会执行时间过长导致，第一次还没执行完就执行第二次，你们面对千亿的数据量居然没有考虑这个问题？
这个问题中有一个错误，交易额是日几十亿而不是交易量几十亿次，订单量远远没有到达这个量级。数据迁移当然考虑了迁移时间，在整个项目迁移之前其实已经进行过很多次的小规模迁移了，并不是第一次迁移，这个文章中也说明了，这个提问者明显没有看完就来喷了。
这个迁移程序在干这次大活之前，其实已经经历多次考验了，所以从某种程度上来讲这次出问题，轻视也是问题发生的原因之一。
不但已经多次使用，在正式迁移之前也安排进行了多次的验证，只是做为管理者没有和程序员一起深入排查部分细节，存在部分管理失职。
另外有的读者说为什么不使用多线程，我强调一下整个迁移项目使用了多线程，并且还不是仅仅一个多线程，只是程序的最外层没有使用多线程，也就是我们后面的补救方案。
其实还有很多问题，这里不再一一回应，有的提问真的是太低级，感觉都不应该是一个程序员提出的问题。
不过还是有一些读者会对这种大规模迁移有所了解，这其中涉及的细节简直不要太多，任何一个小的忽略都有可能导致大的问题，这种事情没有办法在文中一一举例出来。
不过我觉得有一位读者的回复我比较认可：
那些说风凉话的肯定没有做过上千张表新老系统的迁移，还数据库中间件对接，呵呵
最后，还是那句话：保持技术人的那颗初心，一切以解决实际问题为主。