一、站点与服务迁移：无状态，迁移容易

　　站点和服务无状态，迁移起来并不困难。　　

　　步骤1，新机房准备就绪

　　步骤2，在新机房搭建好待迁移的子业务，部署好web站点，业务服务，基础服务，做好充分的测试。

　　步骤3，灰度切流量，将被迁移的子业务切5%的流量到新机房，观察新机房的站点与服务是否异常。如果没有问题，再依次的逐步放量，直至某个子业务迁移完成。

　　这是一个非常稳的迁移方案。

　　二、缓存迁移：有状态，但数据可重建

　　站点和服务迁移完之后，接下来再迁缓存。　　

　　经过第一步的迁移，如上图：

　　1）所有的入口流量都已经迁到了新的机房；

　　2）缓存和数据库，仍然使用旧机房；

　　步骤4，在新机房搭建好缓存，缓存的规模和体量与旧机房一样。

　　步骤5，按照子业务垂直逐步切换使用新机房的缓存，切换细节为：

　　1）运维做一个缓存内网DNS的切换（内网域名不变，IP切到新机房）；

　　2）杀掉原有缓存连接，业务线不需要做任何修改，只需要配合观察服务；

　　3）缓存连接池会自动重连，重连会自

　　三、数据库迁移：有状态，数据也要迁移

　　站点层，服务层，缓存层都迁移完之后，最后是数据库的迁移。　　

　　在迁移数据库之前，服务通过专线跨机房连数据库。

　　如何进行数据库迁移呢？

　　步骤6，先在新机房搭建新的数据库。

　　1.自建机房

　　2.阿里云RDS

　　步骤7，数据同步。自建机房可以使用数据库主主/主备架构同步数据，阿里云可以使用DTS同步数据。

　　数据库同步完之后，如何进行数据源切换呢？

　　能不能像缓存的迁移一样，运维修改一个数据库内网DNS指向，然后切断数据库连接，让服务重连新的数据库呢？这样的话，业务服务不需要改动，也不需要重启。

　　这个方式看上去很不错，但是：

　　1）一定得保证数据库同步完成，才能切流量，但数据同步总是有迟延的，旧机房一直在不停的写数据，何时才算同步完成？

　　2）只有域名和端口不发生变化，才能不修改配置完成切换，但如果域名和端口（主要是端口）发生变化，是做不到不修改配置和重启的。举个例子，假设原有数据库实例端口用了5858，而阿里云要求你使用3200，就必须改端口重启。

　　步骤八，最终的方案是，DBA在旧机房的数据库设置一个ReadOnly，停止数据的写入，在秒级别，RDS同步完成之后，服务修改数据库端口，重启连接新机房的数据库，完成数据层的切换。

　　这个过程中，为了保证数据的一致性，会损失秒级别的写入可用性。　　

　　自顶向下的机房迁移方案总结

　　1、先迁移站点层、业务服务层和基础服务层

　　2、缓存层迁移

　　3、数据库迁移