从IDC到云端架构迁移之路(GITC2016)

从IDC到云端架构迁移之路(GITC2016)

ID:37805774

大小:538.31 KB

页数:10页

时间:2019-05-31

从IDC到云端架构迁移之路(GITC2016)_第1页
从IDC到云端架构迁移之路(GITC2016)_第2页
从IDC到云端架构迁移之路(GITC2016)_第3页
从IDC到云端架构迁移之路(GITC2016)_第4页
从IDC到云端架构迁移之路(GITC2016)_第5页
资源描述:

《从IDC到云端架构迁移之路(GITC2016)》由会员上传分享,免费在线阅读,更多相关内容在行业资料-天天文库

1、从IDC到云端架构迁移之路(GITC2016)⼤家好,很⾼兴来到GITC2016的舞台,我是来⾃58到家的沈剑,今天我分享的主题是《58到家从IDC到云端架构迁移之路》。机房迁移是⼀个很⼤的动作:15年在58同城实施过⼀次(“逐⽇”项⽬),⼏千台物理机,从IDC迁到了腾讯的天津机房,项⽬做了10个多⽉,跨所有的部门,与所有的业务都相关;16年在58到家又实施了⼀次(“凌云”项⽬),⼏百台虚拟机,从IDC迁到阿⾥云,前后⼤概⼀个季度的时间,也是所有技术部门都需要配合的⼀个⼤项⽬。“单机房架构-全连”要说机房迁移,先来

2、看看被迁移的系统是⼀个什么样的架构。上图是⼀个典型的互联⽹单机房系统架构:(1)上游是客户端,PC浏览器或者APP;(2)然后是站点接⼊层,为了⾯对⾼流量,保证架构的⾼可⽤,站点冗余了多份;(3)接下来是服务层,服务层又分为与业务相关的业务服务,以及业务⽆关的基础服务,为了保证⾼可⽤,所有服务也冗余了多份;(4)底层是数据层,数据层又分为缓存数据与数据库;⾄于为什么要做分层架构,不是今天的重点,不做展开讨论,这是⼀个典型的互联⽹单机房分层架构:所有的应⽤、服务、数据是部署在同⼀个机房,这个架构有的⼀个关键词,叫做“

3、全连”:(1)站点层调⽤业务服务层,业务服务复制了多少份,上层就要连接多少个服务;(2)业务服务层调⽤基础服务层,基础服务复制了多少份,上层就要连多少个服务;(3)服务层调⽤数据库,从库冗余了多少份,上层就要连多少个从库;⽐如说,站点接⼊层某⼀个应⽤有10台机器,业务服务层某⼀个服务有8层机器,那肯定是上游的10台会与下游的8台进⾏⼀个全相连的。系统架构的可⽤性保证,负载均衡保证,是服务的连接池去做的。不仅仅接⼊层连接业务服务层是这样,业务服务层连接基础服务层,服务层连接数据库也都是这样,这就是所谓的“全连”。“机

4、房迁移的⽬标是平滑”单机房架构的特点是“全连”,那么机房迁移我们是要做⼀个什么样的事情呢?先看这张图:之前单机房架构部署在机房A内,迁移之后仍然是单机房架构,只是换了⼀个B机房,做完这个迁移,有什么好的⽅案?最容易想到的⼀个⽅案,把所有服务在新机房全部搭⼀套,然后流量切过来了。当系统有⼏千台机器,有⾮常⾮常多的业务的时候,这是⼀种“不成功便成仁”的⽅案。做技术的都知道,设计时要考虑回滚⽅案,如果只有上线⽅案⽽没有回滚⽅案,这便是⼀个“不成功便成仁”的⽅案,根据经验,不成功便成仁的操作结果,往往就“便成仁”了。最重要

5、的是,全量搭建⼀套再流量切换,数据层你怎么搭建⼀套?怎么切?数据层原来都在A机房,B机房还没有全量的数据,是没办法直接切的。要做⼀个数据同步的⽅案,最简单的,停两个⼩时服务,把数据从旧机房导到新机房,数据导完流量再切过去,这是⼀个数据迁移的简单⽅案。这个⽅案对业务有影响,需要停⽌服务,这个是⽆法接受的,何况像58同城⼀样有两千多台机器,⽆限多的数据库实例,⽆限多的数据表的时候,停服务迁移数据根本是不可能的。所以,机房迁移的难点,是“平滑”迁移,整个过程不停服务,整体迁移⽅案的⽬标是:(1)可以分批迁移;(2)随时可

6、以回滚;(3)平滑迁移,不停服务;“伪多机房架构-同连”如果想要平滑的迁移机房,不停服务,在10个⽉的逐步迁移过程中,肯定存在⼀个中间过渡阶段,两边机房都有流量,两边机房都对外提供服务,这就是⼀个多机房的架构了。多机房架构是什么样的架构呢?刚刚提到了单机房架构,上层连中层,中层连下层,它是⼀个全连的架构,能不能直接将单机房的全连架构套⽤到多机房呢?在另⼀个机房部署好站点层、服务层、数据层,直接使⽤“全连”的单机房架构,我们会发现:会有⾮常多跨机房的连接(1)站点层连接业务服务层,⼀半的请求跨机房(2)业务服务层连接

7、基础服务层,⼀半的请求跨机房(3)基础服务层连数据层(例如从库),⼀半的请求跨机房⼤量的跨机房连接会带来什么样的问题呢?我们知道,同机房连接,内⽹的性能损耗⼏乎可以忽略不计,但是⼀旦涉及到跨机房的访问,即使机房和机房之间有专线,访问的时延可能增加到⼏毫秒(跟⼏房间光纤距离有关)。⽤户访问⼀个动态页⾯,需要⽤到很多数据,这些数据可能需要10次的业务服务层调⽤,业务服务层可能又有若⼲次基础服务层的调⽤,基础服务层可能又有若⼲次数据层的调⽤,假设整个过程中有20次调⽤,其中有⼀半调⽤跨机房,假设机房之间延迟是5毫秒,因为

8、跨机房调⽤导致的请求迟延就达到了50毫秒,这个是不能接受的。因此,在多机房架构设计时,要尽量避免跨机房调⽤(避免跨机房调⽤做不到,也要做到“最⼩化”跨机房调⽤),会使⽤“同连”的系统架构。“同连”也很好理解,在⾮必须的情况下,优先连接同机房的站点与服务:(1)站点层只连接同机房的业务服务层;(2)业务服务层只连接同机房的基础服务层;(3)服务层只连接同机房的

当前文档最多预览五页,下载文档查看全文

此文档下载收益归作者所有

当前文档最多预览五页,下载文档查看全文
温馨提示:
1. 部分包含数学公式或PPT动画的文件,查看预览时可能会显示错乱或异常,文件下载后无此问题,请放心下载。
2. 本文档由用户上传,版权归属用户,天天文库负责整理代发布。如果您对本文档版权有争议请及时联系客服。
3. 下载前请仔细阅读文档内容,确认文档内容符合您的需求后进行下载,若出现内容与标题不符可向本站投诉处理。
4. 下载文档时可能由于网络波动等原因无法下载或下载错误,付费完成后未能成功下载的用户请联系客服处理。