从IDC到云端架构迁移之路（GITC2016）

大家好，很高兴来到GITC2016的舞台，我是来自58到家的沈剑，今天我分享的主题是《58到家从IDC到云端架构迁移之路》。

机房迁移是一个很大的动作：

15年在58同城实施过一次（“逐日”项目），几千台物理机，从IDC迁到了腾讯的天津机房，项目做了10个多月，跨所有的部门，与所有的业务都相关；

16年在58到家又实施了一次（“凌云”项目），几百台虚拟机，从IDC迁到阿里云，前后大概一个季度的时间，也是所有技术部门都需要配合的一个大项目。

 

“单机房架构-全连”

要说机房迁移，先来看看被迁移的系统是一个什么样的架构。

上图是一个典型的互联网单机房系统架构：

（1）上游是客户端，PC浏览器或者APP；

（2）然后是站点接入层，为了面对高流量，保证架构的高可用，站点冗余了多份；

（3）接下来是服务层，服务层又分为与业务相关的业务服务，以及业务无关的基础服务，为了保证高可用，所有服务也冗余了多份；

（4）底层是数据层，数据层又分为缓存数据与数据库；

至于为什么要做分层架构，不是今天的重点，不做展开讨论，这是一个典型的互联网单机房分层架构：所有的应用、服务、数据是部署在同一个机房，这个架构有的一个关键词，叫做“全连”：

（1）站点层调用业务服务层，业务服务复制了多少份，上层就要连接多少个服务；

（2）业务服务层调用基础服务层，基础服务复制了多少份，上层就要连多少个服务；

（3）服务层调用数据库，从库冗余了多少份，上层就要连多少个从库；

比如说，站点接入层某一个应用有10台机器，业务服务层某一个服务有8层机器，那肯定是上游的10台会与下游的8台进行一个全相连的。系统架构的可用性保证，负载均衡保证，是服务的连接池去做的。不仅仅接入层连接业务服务层是这样，业务服务层连接基础服务层，服务层连接数据库也都是这样，这就是所谓的“全连”。

 

“机房迁移的目标是平滑”

单机房架构的特点是“全连”，那么机房迁移我们是要做一个什么样的事情呢？先看这张图：

之前单机房架构部署在机房A内，迁移之后仍然是单机房架构，只是换了一个B机房，做完这个迁移，有什么好的方案？最容易想到的一个方案，把所有服务在新机房全部搭一套，然后流量切过来了。

当系统有几千台机器，有非常非常多的业务的时候，这是一种“不成功便成仁”的方案。做技术的都知道，设计时要考虑回滚方案，如果只有上线方案而没有回滚方案，这便是一个“不成功便成仁”的方案，根据经验，不成功便成仁的操作结果，往往就“便成仁”了。

最重要的是，全量搭建一套再流量切换，数据层你怎么搭建一套？怎么切？数据层原来都在A机房，B机房还没有全量的数据，是没办法直接切的。要做一个数据同步的方案，最简单的，停两个小时服务，把数据从旧机房导到新机房，数据导完流量再切过去，这是一个数据迁移的简单方案。这个方案对业务有影响，需要停止服务，这个是无法接受的，何况像58同城一样有两千多台机器，无限多的数据库实例，无限多的数据表的时候，停服务迁移数据