企业数据上云最佳实践( 四 )

配置迁移工具，从源端向OSS迁移数据，这一步不影响您的业务，异步的从源站将数据搬迁到OSS 。

数据搬迁接近完成的时候，将业务上的读写从之前的源站切换到OSS 。

等待迁移工具从源搬迁完所有的老数据（这种场景下如果您的业务有对数据的覆盖写是需要注意的，可能会造成老数据覆盖新数据）

如上所说，我们有两种方式Bucket回源属性可以做到无缝迁移，即镜像和重定向[5]：
镜像回源

利用镜像回源做无缝数据迁移
上图中带有数字标记的箭头就是数据访问miss时的数据流向。在镜像回源的方式下用户访问OSS如果Object miss，那么OSS会替用户从源站读回文件，并写入到OSS，这样一来，如果用户的请求可以遍历所有的文件，那么这个异步的迁移过程其实是可以省略掉的。
重定向回源

利用重定向做无缝数据迁移
上图中有数字标记的箭头就是数据访问miss时的数据流向。在配置重定向回源的方式下，如果Object miss，那么需要您的客户端去源站去读取一次数据。这就要求您的客户端要能理解http协议中的3xx重定向语义（OSS的重定向回源是通过3xx重定向来实现的）。需要注意的是，在这种回源方式下，OSS不能自动帮用户搬迁数据，用户的数据必须依靠迁移工具/服务来异步的搬迁到OSS上面来。上图中也能看到在这种场景下配合CDN一起使用，那么文件会cache在CDN上，无需每次miss之后都回源站读取，也是一种减少延迟、节省源站流量的方式。如果不使用CDN，那么就需要用户自己完成回源站读取数据的过程。
两种回源方式都能实现数据无缝迁移，具体选择哪种可以参考以下使用建议：

如果要迁移的文件较少，建议配置镜像回源的方式，按照文件列表逐一访问OSS，OSS会把所有的文件从源站读取出来，回写到您的Bucket，这种方式是一个最简单的迁移方案。
如果需要迁移的文件量比较大，或者文件的大小比较大，那么由于镜像回源的方式带宽有限，依靠这种方式来搬迁数据可能会花费比较长的时间，影响您的使用体验，建议使用“重定向回源+迁移工具/服务”的方式，如果Object miss，直接让客户端从源站读取数据，由迁移工具/服务来异步的搬迁数据，不影响您的服务。
如果您的业务对延迟比较敏感，建议在大部分数据迁移完成之后再将业务切到OSS上来，否则像文章开头的两张图中所示，如果数据访问miss的话，用户的请求都会经过一个比直接访问OSS上的Object更长的过程，这一过程会增加访问延迟，可能会降低您的用户体验，所以这个重定向或者镜像的数据比例要控制的尽可能小一些。

两种回源规则均可通过阿里云OSS控制台或命令行工具ossutil进行操作。
典型企业案例数据迁移方案需要因地制宜，选择合适的数据迁移方案，可能会涉及到不同迁移方案的组合。下面介绍两个典型的数据迁移案例。
115科技45天百PB数据迁移场景2018.2，阿里云支持115科技的数据迁移。115科技总数据量约100PB、130亿文件存储在东莞、佛山、梅州三个机房，分别有数据50PB、30PB、20PB 。整个迁移过程要求整体服务不停机，客户无感知，数据无遗漏错误。当时互联网历史上还未有规模如此大的公有云数据迁移先例。
迁移方案为了保障115业务平滑迁移，阿里云将分布在不同地区的数千台物理机内的数据与云上的位置进行了一一对应的规划，保证每一比特都有迹可循。从于迁移成本和效率考量，阿里云最终采取在线迁移和离线迁移的组合迁移方案。