迁移上云
迁移的类型
首先我们说说迁移的类型，我们可以把迁移的类型分为服务器迁移、数据库迁移、文件迁移。可能很多人都认为，服务器迁移是最重要的。其实不然，服务器迁移是“最关键”的，但并不是最重要的。最重要的是数据库迁移。因为数据是服务的命脉，服务可以重新部署，而数据一旦丢失，对企业来说则是致命的。所以，数据库的迁移是迁移的重中之重。
迁移的方式
不同的迁移类型，都存在停机迁移和在线迁移两种迁移方式。
停机迁移
相比之下，停机迁移相对简单。由于停机迁移预留了窗口期，且停机迁移无论在业务上还是数据上，都不存在实时数据输入导致的数据不一致的问题。所以，停机迁移相对安全、稳定。在大多数情况下对于可停机的迁移，我们都建议优先考虑停机迁移。
比如规定一个维护时间，通告用户凌晨 0 点到 6 点进行维护。在那个时间段，用户是无法访问服务的。对于用户来说，体验会变差，但对于企业来说，这是最安全的一种做法。连续性不强的业务，比如游戏、相册等服务，用户是可以接受服务在某段时间不可用的，这种情况下，我们就可以采取停机迁移。但如果这个服务对业务连续性至关重要，比如电商、即时通信，企业一般不会选择停机迁移，因为停机迁移带来的问题是比较大的。
停机迁移带来的问题：
首先是停机迁移对用户的使用体验变差，这会在某种程度上降低用户的忠诚度。
其次这类在线的服务不太允许用户数据中断，数据中断就意味着企业会损失资金，尤其是电商这类服务，一旦停止对外服务，损失是按秒计的，所以这类的服务也就无法接受停机迁移。
对于大型的业务，停机时间是一定的，而业务越大，数据量越大，数据结构越复杂，迁移过程越长。迁移过程越长，容许迁移出事故救场执行的时间也就越有限。在有限的时间内处理事务，要保证不出错，这就要求迁移人员要足够细心。
在线迁移
相比于停机迁移，在线迁移挑战性和难度都比较大，而且需要根据不同的服务类型确定相应的在线迁移方式。
对于服务器，现在的云厂商几乎都提供了在线迁移的云工具，可以不停机一键迁移上云。比如亚马逊的 Application Migration Service，阿里的 Server Migration Center 工具。
对于这类工具，其本质是在服务器内部安装一个代理 Agent，由 Agent 向控制中心进行迁移服务器的注册。在迁移的过程中，数据实时同步。云厂商会自动为你开启一台中转服务器，这台中转服务器帮助你将线下的机器迁移到线上。当控制台中显示迁移完成后，说明你已经将线下的服务器同步到云端的一个“仓库”中了。
此时，并没有万事大吉。到这一步，我们只是将我们的环境同步到线上，还需要对我们的环境进行进一步的验证。这里的验证不仅仅是我们自身业务方面的验证，还有我们云上环境的验证。虽然现在的云主机已经支持大部分的系统和自动化的迁移流程，但不排除有一些特殊情况需要手动设置。比如说，线下的网卡信息不兼容，需要手动修改网卡启动项目，路由条目等。在线迁移有十大关键步骤，我已一一列出，你可以看一下。
在线迁移 10 大关键步骤：
- 在源服务器上安装 Agent
- 等待初始同步完成
- 启动测试实例
- 在服务器上执行验收测试
- 等待切换窗口
- 确认没有滞后
- 停止源服务器上的所有操作服务
- 启动一个割接实例
- 确认割接实例启动成功，完成割接
- 归档源服务器
数据库迁移也分为停机迁移和在线迁移。由于数据库的数据价值最高，所以数据库的迁移是重点要考虑的，主要考虑以下几个方面：
- 数据库版本问题
- 云上数据库兼容问题
- 数据库在线 / 停机迁移
无论是服务器还是数据库，我们最好的方式是使用同等版本的服务，这样产生的版本误差是最小的。但如果遇上确实需要跨版本迁移的极端情况，比如你自建的数据库是 MySQL 8.0 的，而某个云厂商 RDS 只支持到 5.7，或者是由于一些其他原因必须要使用 5.7。那这时候首先你要确定的是是否有新特性支持的对象，一旦测试通过，不影响业务，我们就可以进行迁移。
比如我们 MySQL8.0 到 5.7 的转换，MySQL8.0 的字符集和排序规则较 5.7 有如下改动：
表编码为 utf8mb4_0900_ai_ci
排序规则为 utf8mb4
utf8mb4 替换为 utf8
就需全局替换相关字段，进行如下操作：
utf8mb4 替换为 utf8
utf8mb4_0900_ai_ci 替换为 utf8_general_ci
utf8_croatian_ci 替换为 utf8_general_ci
utf8mb4_general_ci 替换为 utf8_general_ci
你需要手动将 *.sql 文件中的关键词按上述的要求进行替换，或者使用 Navicat 等第三方工具进行替换导出。
正如你所见，这样的迁移实属麻烦，需要停机 - 手动 dump 导出 - 手动导入。由于数据库的特殊性，停机迁移会丢失大量的实时数据，所以，我们找到了一种无数据丢失的解决方式，就是使用在线迁移工具进行迁移。
现在，云产品为我们提供了实时的在线迁移工具，如 AWS 云的 DMS 服务，阿里云的 DTS 服务，这些云厂商的迁移服务工具都支持在线迁移，提供数据传输支持同 / 异构数据源之间的数据交互，数据迁移 / 订阅 / 同步交互功能。可以很方便地在控制台中进行监控和观察。由于现在云厂商的数据库在线迁移已经非常成熟，而且没有像服务器那样需要考虑网卡、网关、VPC 等相关的兼容调整，所以现代数据库迁移几乎都是使用在线迁移工具进行迁移。
迁移的策略
上面我只是简单地对服务器和数据库这两方面做了大体迁移路径的分析和指导。对于迁移策略，业界一般称之为 6R 迁移策略，分别是 Re-Host，Re-Platform，Re-Purchase，Re-Architect，Retire、Retain。
其实对于迁移，我们是需要具体评估用户环境的，且不同迁移是需要混合使用的。比如，我们刚才所说的服务器迁移，就用到了 6R 中的 Re-Host，而我们的数据库迁移是从自建数据库迁移到云上 PaaS 级 RDS for MySQL 数据库，这就是 Re-Platform 的思想。
而且随着云原生的发展，我们进行业务迁移并不是简单的 P2V、V2V 进行直接的迁移，大多数情况下，我们需要对整个业务进行优化的转换，比如之前的服务存储在本地的硬盘中，那么在上云之后，我们是否可以考虑将数据存储到对象存储中以减少成本？亦或者是加上 CDN 进行缓存加速。这都是作为架构师需要考虑的点。
