最近半年参与了部门的项目，这个项目需要对老的业务系统的某些功能进行剥离，实现功能重构，不仅代码要重写，数据也要进行迁移。主要原因是该系统是一个维护了十几年前的系统，一直没有进行过重构，新的业务需求越来越多，补丁也越打越多，代码耦合紧密，改动起来牵一发而动全身，风险大，代码也越来越难懂，上线部署慢；数据因为历史的原因已经漏洞百出，很多业务模块涉及到费用的计算，精确度很差，业务吐槽严重，已经接近无法使用边缘，鉴于此，经充分探讨并争取业务同意后，我们准备对该部分进行重构，从原系统中抽离，也就是Martin Flower 在他的一篇文章中提到的绞杀者模式。
... Create a new system around the edges of the old, letting it grow slowly over several years until the old system is strangled.
这就是说我们在改造这类遗留系统时，应该采取逐步改造的策略，不但将单体应用中的服务抽取出来，由新应用替代。随着越来越多的服务被新应用代替，原本的单体应用逐渐缩小至最终消灭。
整个过程中，耗时4个月左右才顺利上线运营，积累了一些经验，也有一些教训，现记录下来，做个归纳总结。
业务以及需求整理
1. 因为该部分功能使用已经很长时间，需要配合需求以及业务对整个功能进行梳理。由于历史需求文档的不完善，我们选择了一位对该块系统较为熟悉的技术人员，让他协助需求人员进行梳理。整理出数据的结构以及基本的业务逻辑。
2. 要尽量掌握现有数据的质量问题，当然无法知道全部，只有数据迁移的时候才能充分感受到。
系统的微服务化架构设计开发。
1. 鉴于前期需求的整理以及多次沟通探讨，慢慢梳理出了系统的功能，梳理出了多个系统服务的边界。
2. 数据库设计方面。 除非原数据库有大的设计上的问题，数据库结构尽量与原数据库保持结构上一致，这样可以避免数据迁移带来的巨大的工作量。
3. 此次开发是一个小团队作战，沟通效率很高，问题得到了及时沟通解决发现，团队每个人合作还是很默契的。
4. 跟需求的沟通也比较顺畅，由于有些细节问题，需求也无法尽善尽美的写入文档，有问题我们及时微信语音沟通讨论，虽然不在一个工作地方，但是沟通效率还是基本得到了保障，但是未来还是期望能时常坐在一起，以期达到更高的沟通效率。
5.开发过程要多进行代码审查，由于开发人员开发经验相对较少，开发过程中，不可避免团队成员的编码风格或多或少存在一些问题，为了让团队成员都能有一个好的编码风格，后期还需要跟大家多做些相关的培训，不要担心会影响工作进度，再忙也要去做，其实可以达到事半功倍的效果。
6. 系统虽然已经采用了微服务架构进行开发，因为时间问题以及其它问题未引入自动化持续交付流水线以及持续的部署，在接下来的工作中也努力在公司相关团队的协助下进行。
数据迁移
系统上线后，我们进入了数据迁移的阶段，这个过程我们没有前期没有对数据迁移的工作量要做充分合理的评估，以致于以为一周就可以完成的工作量，实际加班加点用了3周才基本搞定，期间遇到了各种问题，主要问题有：
1. 迁移脚本的逻辑性问题。期间出了一些问题，导致迁移出现了往复的问题，要尽量沟通解决。
2.历史数据的修复问题，因为系统跑了十几年，导致系统存在了很多的错误数据，有的是字段该有的字段数据没有，有的是数据字段本身产生了错误，有的是数据因为系统逻辑问题出现了重复，因此需要对问题数据进行人工校对修复，虽然有的表只有几百条，有的表只有几千条，在需求以及业务的帮助下却花了很长的时间。
总之，数据迁移要尽早着手准备，形成一个可靠的迁移方案，迁移脚本尽量提前写完，提前验证，因为这个过程还可能找出新系统存在的设计问题，早期就可以对新系统进行修正，所以系统要尽早进行迁移的相关工作；并且项目初期要充分预估迁移的工作量，以免让自己的工作陷入被动。
