查看下篇文章，点击这里。
以下是直播内容精华整理，主要分为五个部分：
一、关于迁移那些事；
二、脚本时代迁移；
三、云API实现迁移自动化；
四、利用阿里云原生服务构建迁移平台；
五、未来展望。
一、关于迁移那些事
一提到迁移，大家可能想到的就是复杂，正如《企业迁云之路》这本书中写的那样，上云需要从战略、组织、风险、财务和技术等方面统筹思考，才能保证方向正确，并通过严格的项目管理对业务产生助力。
云计算对于企业T架构的冲击和变革是非常大的，因此需要一个较长的观察期，以便对业务和技术有足够的理解和思考。企业如果要上云，至少要从业务技术能力、项目开发能力和数据应用这三个方面综合考虑应怎样逐步迁移、哪些不能或者不需要迁移、迁移的时候是复制还是重构。上云前企业在思考什么，决定了上云后企业能够获得什么。
下图是Gartner在2018年发布的关于云计算的重复度曲线，预测云迁移将在4-5年内发生，私有云迁移是在最近两年内发生，该预测与目前的实际状况比较类似。注意图中的MultiCloud同样被预测在2-5年内出现，也印证了混合云的兴起。正是有了多云的出现，用户才有意愿将业务在不同云之间进行切换，云迁移的重要性才得以凸显。
Gartner对运管平台定义的十大模块中，迁移和容灾被单独列为一个模块，为了方便企业管制的一些需求，多数企业均会建立云管平台，也为多云的混合调度提供了很大的便利。但是云管平台实际上是在控制流做管理，数据和通讯还是用户去做的，无法实现从A云到B云的灵活迁移；而且在传统迁移的时候往往需要专业人员来帮助用户使用，但是在云迁移的概念下，迁移和容灾的行动，应该是一个自助的行为，那么就对云迁移提出了更高的操作简便性，使得普通用户也能便捷的使用。
二、脚本时代迁移
（一）迁移方式的选择
从下图中我们可以看到，迁移的方式有很多，比如重装、Re-Host、重构等等，而在这些方式中，最经济、最快的方式就是Re-Host方式。
如果想用Re-Host方式的话，从迁移的文件存储级别来看，我们有下面2中方法：
（1）文件级别
该方式缺陷有一个缺陷，是需要提前在云上把待迁移主机建立起来，但是由于线下的主机系统可能比较老，云上不一定能找到完全对应的版本，那么在这种情况下进行迁移的时候，很可能影响应用的稳定性问题。
（2）块级别
块级别的迁移方式和我们的需求是比较接近的，但是从市面上的产品来看，都是需要在迁移过程中远端停机，会对用户的业务稳定性产生很大的影响；另外就是这些方式需要大量的手动操作，在云迁移的方式下，其实并不适用。
（二）云迁移与传统迁移的区别
云迁移与传统迁移的最本质区别在于API接口的利用：在物理环境下，我们很难利用命令或者相关的API控制服务器来完成迁移工作，但是在云的环境下，一切被虚拟化，所以很容易的调用云平台的计算、存储、网络等资源，从而能够更快速的帮助用户将应用迁移到云端。所以，API的利用是一个云原生迁移平台要具备的第一个特性。
（三）云迁移诞生之缘
如下图所示，我们团队在实际业务中发现了云迁移的潜在需求，进而基于云原生的方式，开发了这样一款产品，大大提升了用户的迁移效率与安全性。
三、云API实现迁移自动化
（一）云迁移的主要技术与架构
当云API和迁移流程能够完美结合的时候，对迁移效率的提升非常明显：用云API实现迁移自动化的整个过程比人工方式快10倍以上，比其他工具要快5倍以上。
如果想要用云原生API实现迁移自动化，对于工具应该至少满足以下6点要求：
- 面向小白用户的设计，步骤简单，界面清晰，无须培训就可以开始使用；
- 实现在线“热迁移”效果，即迁移不影响业务；
- 能够支持私有云、阿里云公有云、专有云平台；
- 迁移过程中无须进入命令行操作，实现全自动、一键式迁移效果；
- 微服务设计，模块之间的通讯全部使用REST接口，不允许跨模块访问数据库；
- 对外提供REST API接口，能够被第三方产品进行整合。
云迁移过程中，想要满足以上几点需求，需要实现的关键技术有如下：
（1）块级别复制
块级别全量、增量复制，保证业务连续性，块级别差异捕获。业务系统可以整体恢复、无须重装或应用改造。
（2）数据传输
数据的传输支持多种传输协议和方式，能够支持大容量窄带宽传输方式，支持传输到存储设备。
（3）API接口
支持迁移到多个云平台，使用云原生API接口，形成高度自动化流程，使用云原生资源，在迁移过程中无须转换，提高效率。
（4）驱动适配
通过对驱动注入，保证操作系统可以在目标平台正常启动，规避在源端安装驱动的风险。
只有以上几个关键技术被满足之后，我们才能建立一个面向云原生方式的迁移平台。下图所示是单机版本的业务逻辑架构。
根据业务逻辑的抽象将模块分为三大类：源端代理、迁移调度管理和云平台代理端。其中，源端代理主要负责将块数据用全量和增量的方式读出，云平台代理端主要负责接收数据以及通过API调度云平台的资源配合迁移流程，而迁移调度管理平台主要负责整个迁移调度工作，降低整个迁移工作的复杂性。
三个模块中，除了源端代理无法部署在容器上，前迁移调度管理和云平台代理端都部署在容器上。底层上，我们即可以对接云平台，也可以对接传统存储，就解决了在大容量、窄带宽下的迁移工作。架构中的每个模块都是微服务架构，包括API与Worker服务，模块都是异步调用为主，满足了调用的灵活性和可扩展性。
其中，对于每个模块内的技术栈如下图所示。
这里特别介绍下关于存储抽象层的设计，在这里我们实际上用到了软件存储控制层的概念。一开始存储控制层的作用是将不同型号存储的API接口进行统一的管理，能够让应用层和编排层使用统一的接口去调度不同的存储。但是，如下图所示，在设计该平台的时候，我们做了一个创新的操作，将云平台也变成了一个存储，因此上层的应用层和编排层就能像普通的应用层一样使用阿里云，我们只管理到控制流，数据流还是之前的路径。除此之外，我们还能管理离线的设备，就解决了传统存储和云存储统一的问题。
（二）利用云原生资源进行数据同步
数据同步就是将源端的数据同步到阿里云的EBS上，并且每次同步之后会进行EBS快照，方便进行验证，完整的过程如下图所示。在该过程中，全量同步与增量同步进行配合，提高了同步效率，快照技术保障了数据的安全性。
（三）利用阿里云API将EBS变为ECS
在阿里云的接口里面其实并没有可以直接将EBS变为ECS的API，我们利用了主机镜像的方式来实现了该功能，具体的流程如下图所示。在这种方式下，无论是数据同步还是启动主机的过程，对源端业务系统都没有造成任何影响。实际上该过程类似于容灾体系中的容灾接管的过程，通过这种方式，大家可以对上云之后云主机的稳定性经过充分的验证之后再去完成同步增量等，进而完成完整的迁移过程。
（四）阿里云接口需求
从迁移的角度来讲，在各个阶段对阿里云的接口需求如下图所示。正式因为有了如下接口，整个迁移的过程才会更加的快速、便捷。