自顶向下的迁移方案

借鉴某位前辈的总结：

为什么上云

除了大环境和行业发展浪潮推动业务上云，还有更实在的原因，比如老板决定了要迁移上云、拥抱云，除此之外在技术上还有一些原因：

自行搭建满足行业要求的灾备系统并不容易，而迁移到云端是恰到好处的选择。本地机房扩展能力不足，将业务迁移至云端并构建混合云架构，可以为你的业务带来更强的稳定性和业务连续性。

最佳实践

- 蚂蚁搬家式迁移，迁移不可一蹴而就；

- 通过混合云架构实现平滑迁移。

迁移上云的步骤

从项目视角来看，迁移可以用“观云、迁云、享云”三步走来实现：

掌握云平台及业务自身情况做好迁移前的准备。通过实施、测试、演练和割接完成整个迁移过程。最终可以享受云平台带来的便利和稳定。

具体操作步骤分为这几个阶段：

准备阶段实施阶段测试阶段演练阶段割接阶段验证阶段技术视角

从技术视角来看，业务迁移上云包括主机迁移、数据迁移、流量迁移，如果采用了大数据、人工智能等业务则准备相应模块的内容即可，本文选取最基本的三块来介绍。

主机迁移

业务系统的应用层、逻辑层运行在主机上，该怎么迁移？

主机数量少：完全可以在云端创建相同数量的云主机，然后安装Apache、Tomcat或者IIS，在云端安装相同的软件、运行同样的代码，构建与本地环境一模一样的业务。主机数量多：我们可以选择通过制作镜像的方式进行迁移，即将运行业务的主机整体打包制作为镜像，然后复制镜像到云端并导入到云主机中，云主机启动后即可拥有相同的业务能力，避免了繁琐的手动安装环境的过程。

除了镜像迁移的方式，还可以通过底层文件同步的方式实现主机迁移。主机上的软件、代码、数据还是落在硬盘上，在本地硬盘和云端硬盘之间进行底层文件复制的方式完成主机迁移，在云端云主机挂在已经存有软件、代码和数据的硬盘可以恢复主机的业务能力。

数据迁移

业务系统除了应用层、逻辑层代码，还有数据。我们可以根据数据的类型采取针对性的迁移方案。面向结构化数据，也就是MySQL等关系型数据库，可以采用云平台提供的数据迁移服务UDTS工具来迁移。

UDTS支持将自建MySQL数据库迁移至云端数据库，接着开启增量迁移将新增的数据持续同步至云端数据库，最终达到本地和云端数据一致的情况，完成MySQL数据库迁移，可将对数据库的连接从本地更改到云端。

静态数据迁移

业务中海量的图片、视频、PDF、CSS等各种静态文件需要进行迁移，无论存储在本地环境还是其他公有云平台，都可以通过设置资源回源的方式完成资源迁移。这种方式牺牲了第一次访问该资源的相应时间，通过第一次的拉取为后续访问带来了便利。如果有少数资源从来没有被访问到，则还是仅存储在源站，这时可维护一个未回源的资源列表并触发程序去模拟访问资源完成回源访问，最终完成所有静态资源的迁移。

优点：静态资源通过回源的方式进行迁移，不会影响业务的使用，业务无需中断，没有额外的费用成本。

缺点：不过时间周期较长，不适合数量众多、超大文件的迁移。

迁移工具

UCloud云平台提供有对象存储迁移工具ufile-import，将工具部署在本地环境或其他云平台中，即可将数据迁移至UCloud对象存储UFile中。流量迁移

业务和数据都迁移完成后，还需要将用户请求从本地环境切换到云端，也就是常说的割接。至少有三种方式实现切换：

直接切换，为业务设置一个维护时间，比如业务请求量低的凌晨进行流量切换，业务需要中断；并行切换，通过混合云的实行实现平滑迁移上云，在一段时间内本地环境和云端按照不同的流量比例共同运行，也就是实现业务双活，然后逐步移除本地环境的流量，最终将所有流量切换到云端完成迁移；分段切换，按照不同项目的不同阶段进行切换，选择容易实现的方式进行上云并验证，逐步实现所有业务完成上云。

内容源自《云端架构》作者吕昭波