从IDC到云端架构迁移之路(GITC2016)概要.pdfVIP

从IDC到云端架构迁移之路 （GITC2016） ⼤家好，很⾼兴来到GITC20 16的舞台，我是来⾃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同城⼀样有两千多台机器，⽆限多的数据库实例，⽆限多的 数据表的时候，停服务迁移数据根本是不可能的。 所以，机房迁移的难点，是“平滑”迁移，整个过程不停服务，整体迁移⽅案的⽬标 是： （1）可以分批迁移； （2）随时可以回滚； （3）平滑迁移，不停服务； “伪多机房架构-同连” 如果想要平滑的迁移机房，不停服务，在10个⽉的逐步迁移过程中，肯定存在⼀个中 间过渡阶段，两边机房都有流量，两边机房都对外提供服务，这就是⼀个多机房的架 构了。 多机房架构是什么样的架构呢？刚刚提到了单机房架构，上层连中层，中层连下层， 它是⼀个全连的架构，能不能直接将单机房的全连架构套⽤到多机房呢？在另⼀个机 房部署好站点层、服务层、数据层，直接使⽤“全连”的单机房架构，我们会发现：会 有⾮常多跨机房的连接 （1）站点层连接业务服务层，⼀半的请求跨机房 （2 ）业务服务层连接基础服务层，⼀半的请求跨机房 （3 ）基础服务层连数据层 （例如从库），⼀半的请求跨机房 ⼤量的跨机房连接会带来什么样的问题呢？ 我们知道，同机房连接，内⽹的性能损耗⼏乎可以忽略不计，但是⼀旦涉及到跨机房 的访问，即使机房和机房之间有专线，访问的时延可能增加到⼏毫秒 （跟⼏房间光纤 距离有关）。 ⽤户访问⼀个动态页⾯，需要⽤到很多数据，这些数据可能需要10次的业务服务层调 ⽤，业务服务层可能又有若⼲次基础服务层的调⽤，基础服务层可能又有若⼲次数据 层的调⽤，假设整个过程中有20次调⽤，其中有⼀半调⽤跨机房，假设机房 间延迟 是5毫秒