背景
笔者收到通知，有一个中心化项目需要迁移为部门自建。项目为微服务发布平台，包括闲鱼、淘宝、支付宝、天猫等许多部门的业务，都统一部署在此平台。由于中心化的部署方式有相应的运维和使用的不便，出于规避安全风险考虑，避免双十一期间多业务互相影响产生故障，平台方通知各业务方，进行微服务平台自建。
本项目时间紧急，到deadline总计16个工作日，大概三周时间。通过对项目背景的梳理，基本的代码阅读，迁移文档的了解，面临的挑战主要有：
项目代码复杂，依赖的中间件多，项目流程长。
数据迁移，项目同时存在mysql和nosql，需要保障数据一致，且不能影响旧业务。
功能验证复杂，除去基本的业务逻辑，还需要检查中间件的功能，且有多应用交互行为。
稳定性保障，新旧项目需要完全隔离，互相不能影响。
相信大家在迁移项目的过程中都或多或少遇到类似的问题，接下来我们来结合实际的处理案例一起看下，笔者是快速安全的克服这些困难。
方案落地
为了方便读者阅读，这里先简单介绍下要迁移项目的功能。
下面，结合具体的困难，一起看下迁移细节。
复杂的项目代码
一个要迁移的项目，一定是一个经年累月的老项目，有着庞大的体积，复杂的逻辑，和糟糕的代码味道。面对这样一个项目时，我们又该怎样去快速完成新项目的启动，拿下万里长征的第一步呢？
首先，写代码最快的方法就是粘贴别人的代码（并没有），我们先直接clone一份旧的代码库， git remoteset-url origin{newrepo}指向新的代码仓库。
接下来，新老项目依赖的配置，部署的方式，乃至运行的服务器，必然是不同的。那么，需要做一些基本的替换：
项目名替换，旧项目名称全局替换
配置替换（代码/中间件），申请新的中间件，在配置文件里替换
域名替换，控制台带有前端页面，需要调整相应的域名
代码包名替换，为了和旧服务完全区分，新的服务需要提供新的jar/war包。
dockerfile替换，dockerfile启动项会存在和项目相关的信息，也需要做统一的替换。
最后，进行本阶段验收：
本地可以启动服务
本地打包版本正确
在一系列替换操作下，我们不需要彻底理解老项目，也可以成功运行。这个过程势必会遭遇很多启动失败，我们也可以从失败中吸取经验，了解项目启动的必要条件。这个过程从9.23开始，到9.27截止，总计经过4个工作日。
数据迁移
项目迁移的过程中，数据迁移是不可避免，也至关重要的一环。服务的本质是数据的流入和流出，服务的迁移必然涉及数据流的迁移。一般而言，服务会依赖mysql做复杂数据的持久化存储，nosql做缓存或其他简单结构存储。持久化存储必然需要进行迁移；过期时间短的缓存一般是不需要做迁移的，因为会自动过期；其他存储在nosql的简单结构也需要迁移。经过以上分析，为了解决数据迁移保障数据一致的问题，笔者进行了以下处理：
迁移过程中有几个需要注意的点：
新老项目数据库完全区分。避免写入脏数据
库表结构一致性。避免上线后出现问题
数据一致性定期校验，避免数据不同步带来的业务影响
通过简单的依赖梳理和迁移工具的运用，可以最小化工作成本和操作风险，迅速完成任务。笔者最终在2个工作日内处理完毕。
功能验证
本次要去中心化的项目为微服务平台，本身涉及的中间件众多，且涉及到和其他服务的交互，验证流程非常长。如果不做好回归测试的计划，很难保证功能的完整可用，也会为后续的使用带来安全隐患。为顺利完成复杂的功能验证，在接手项目之初，我们就应该对项目的各种流程有一个清晰的认知，事先列举检查点，对可能的风险和问题有一个预估。以本次迁移的项目为例，业务检查点主要有：
登录权限申请
微服务列表展示
微服务创建
微服务发布
技术检查点包括：
数据库读写
消息队列，发布/消费
其他中间件使用
网络配置
以上，笔者整理了项目业务/技术上的检查点。在项目启动成功后，一般需要经过测试 - 预发布 - 生产，三个环境的验证，在每个环境部署成功后，都需要对以上的检查点进行检查。
以消息队列迁移的验证为例:
这个过程中，笔者也遭遇过一些问题，比如因为消息未广播发送，发生消费成功但微服务无法全部更新的情况等。消息队列无法正常打通可能有多种多样的原因，生产、消息通路、消费都需要进行仔细的验证。
总结下，业务上，我们观察业务流程是否正常；技术上，我们通过技术手段检查：
观察服务日志，中间件日志
debug工具观察代码执行，对于java开发，可以使用arthas工具，idea的远程调试等
数据库读写数据验证，消息队列接发消息验证等。
在功能验证过程中，我们不可避免的会遭遇各种各样的问题，有心理预期，对症下药，迅速针对问题作出处理，可以有效的提升工作效率，加快迁移进程。以上流程从9月29日开始，到10月13日截止，经历4个工作日。
稳定性保障
新项目迁移上线完毕后，还有非常重要的一个环节：稳定性保障。怎么保障新项目的服务稳定？怎么保障新项目的功能使用不会影响到老项目？怎么完成新老项目的交接替换？这些都是我们接下来要讨论的问题。
首先，我们先要保证新项目的稳定性，一般而言，需要对应用本身配置监控，包括但不限于：
服务器基准监控
jvm监控
服务接口监控
服务中间件监控
然后，确认新老项目的隔离，一般而言，完全隔离开新老项目的数据库、消息队列等中间依赖，完全隔离部署服务器即可。接下来，需要确定新老项目的交接替换方案，通常来说流程如下：
几个需要注意的点：
业务上交割时点确认后，需要保证新老项目的同时可用。
发生问题时，可以用老项目做备用来完成业务功能。处理完新项目的问题，继续进行切流。
整个项目上线后，需要一段时间的持续观察，确保观察期间没有意外的问题发生，才能正式结束迁移。
效果总结
笔者迁移的微服务平台，上线后对其进行了两周的观察，进行了数次微服务发布等。确认应用完全去中心化，业务功能正常，且服务运行稳定。完整的迁移工作流如下：
整个流程复盘下来，从项目部署，到项目启动，再到功能验证，最后的稳定观察，笔者都遭遇了各种各样的问题，但是，借助于完善的迁移计划，充足的准备工作，和多位同学的协助，迁移仍然在十个工作日内完成。复盘下来，要点有三：
拆分复杂问题，逐个突破
方案考虑周全，减少风险
充分理解项目，保障业务
迁移充满了安全风险，我们要勇敢的面对风险，包容风险，给出完整的解决方案，希望本文介绍的迁移经验能为读者带来些许的帮助，让迁移更加安全，更加高效。