核心系统迁移方法论.docx

Informationclassification:Internal

信息分类:内部

1、梳理系统业务

系统切换之前必须要充分理解迁移涉及的每个业务模块，包括每个模块的业务逻辑，各个模块之间存在的依赖关系，各个业务模块另外也包括需要迁移的这些模块中当前已知的一些缺陷。

2、制定回归方案

系统迁移完成后一般需要跑几遍回归Case，确保新的系统可正常运行。因此迁移之前需要先准备好回归的Case。

回归Case可以采用地毯式的回归Case，也可采用自顶向下、从核心到周边的方式。具体使用哪种方式需要结合自身业务选择，原则的话就是准备的Case要尽量全面，覆盖尽量多的测试点，回归次数一般建议2轮以上。

3、性能压测

迁移前需要对已经部署好的新环境做几次性能压测，确保新环境可以支撑起现有的业务量，对存在瓶颈的部分需要尽快优化，不能将问题带到迁移中。

4、确定切流计划

一般做完前面的步骤后即可进行迁移计划的制定了，需要根据业务的优先级对业务进行排序，从优先级低重要程度的低的业务开始迁起，各个业务模块依次计划好迁移的顺序。

确定切流时最先切换的比例，如1%，确定切流的间隔周期，以及切流幅度。

5、制定应急方案

以上准备工作都处理完毕后，需要考虑下如果迁移过程中出现异常应该如何应对，指定兜底方案。

虽然压测和逐步切流可以避免很大的风险出现，但仍存在一些不容忽视的问题，如脏数据问题，需要对各种意外情况做好应急预案。

6、备份数据

迁移开始前需要检查各项数据库的自动备份是否正常，包括关系型数据和非关系型数据库，除了周期性备份之外，建议在迁移开始之前也要做一次全量的备份。

除了数据库中保存的数据之外，还建议保存诸如虚拟机的、容器的镜像数据，消息队列的数据等数据。

7、切流

具体切流时，安全起见一般建议逐步切，先切很小的一部分流量，如1%，看下切过去的流量在新系统中是否正常，如果正常再按照之前指定的切流方案逐步进行。

8、回归验证

执行到此步时系统一般已经切过来了，整个迁移过程已经完成了一半的工作。

不同规模的系统回归的工作量一般不同，大型的系统回归的工作量相对较多，一般建议进行至少两轮的回归，每一轮的回归必须包含前面设计的所有业务的链路，另外回归过程必须完成所有业务数据的检验，比如关系库数据、NoSQL数据、日志数据、消息数据等。尽量使用自动化的Case，自动化成本较大的Case可以考虑人肉排查。

9、数据监控

迁移过程中和迁移之前是不一样的，有些问题可能不会触发告警，即使我们配置了告警管理，这个时候就需要介入一些人为的判断，迁移过程中每个业务模块的技术人员都要时刻关注自己模块的运行情况。