买球平台(股份有限公司)-官方网站

　　从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毫秒，因为跨机房调⽤导致的请求迟延就达到了50毫秒，这个是不能接受的。 因此，在多机房架构设计时，要尽量避免跨机房调⽤ （避免跨机房调⽤做不到，也要 做到“最⼩化”跨机房调⽤），会使⽤“ 同连”的系统架构。 “ 同连”也很好理解，在⾮必须的情况下，优先连接同机房的站点与服务： （1）站点层只连接同机房的业务服务层； （2 ）业务服务层只连接同机房的基础服务层； （3 ）服务层只连接同机房的“读”库； （4 ）对于写库，没办法，只有跨机房读“写”库了； 这个⽅案没有完全避免跨机房调⽤，但其实它做到了“最⼩化”跨机房调⽤，写主库是 需要跨机房的。但互联⽹的业务，99%都是读多写少的业务，例如百度的搜索100%是 读业务，京东淘宝的电商99%的买球官方网站浏览搜索是读业务，只有下单⽀付是写业务，58同城 99%帖⼦的列表详情查看是读业务，发布帖⼦是写业务，写业务⽐例相对少，只有这 ⼀部分请求会跨机房调⽤。 迁移机房的过程使⽤这样⼀个多机房的架构，最⼤的好处就是，除了“配置⽂件” ，整 个单机房的架构不需要做任何修改，这个优点是很诱⼈的，所有的技术部门，所有的 业务线，只需要配合在新机房部署应⽤与服务 （数据库是DBA统⼀部署的），然后使 ⽤不同的配置⽂件 （如果有配置中⼼，这⼀步都省了），就能实现这个迁移过程，⼤ ⼤简化了迁移步骤。 这个⽅案当然也有它的不⾜： （1）跨机房同步数据，会多5毫秒 （举个栗⼦，不要叫真这个数值）延时 （主从本来 会有延时，这个延时会增⼤），这个影响的是某⼀个机房的数据读取； （2 ）跨机房写，会多5毫秒延时，这个影响的是某⼀个机房的数据写⼊，当然这个写 请求⽐例是很⼩的； 这个“ 同连”架构⾮常适⽤于做机房迁移，当然也可以⽤作多机房架构，⽤作多机房架 构时，还有⼀个缺点：这个架构有“主机房”和“从机房”的区分。 多机房架构的本意是容机房故障，这个架构当出现机房故障时，例如⼀个机房地震 了，把⼊⼜处流量切到另⼀个机房就能容错，不过： （1）挂掉的是不包含数据库主库的从机房，迁移流量后直接容错； （2 ）挂掉的是包含数据库主库的主机房，只迁移流量，其实系统整体99%的读请求可 以容错，但1%的写请求其实会受到影响，此时需要⼈⼯介⼊，将从库变为主库，才 能完全容错。这个过程只需要DBA介⼊，不需要所有业务线上游修改 （除⾮，除⾮， 业务线直接使⽤的IP连接，这个，我就不说什么了）。 也正是因为这个原因，在机房故障的时候，有⼀定概率需要少量⼈⼯介⼊，才能容 100%的机房故障，因此这个架构才被称为“伪多机房架构” ，还不是完全的“多机房多 活”架构。 “⾃顶向下的机房迁移⽅案” 话题收回来，机房迁移的过程中，⼀定存在⼀个中间过渡阶段，

　　2、成为VIP后，下载本文档将扣除1次下载权益。下载后，不支持退款、换文档。如有疑问请联系我们。

　　3、成为VIP后，您将拥有八大权益，权益包括：VIP文档下载权益、阅读免打扰、文档格式转换、高级专利检索、专属身份标志、高级客服、多端互通、版权登记。

　　4、VIP文档为合作方或网友上传，每下载1次， 网站将根据用户上传文档的质量评分、类型等，对文档贡献者给予高额补贴、流量扶持。如果你也想贡献VIP文档。上传文档

　　《java从入门到精通》2009122201_异常的捕获与处理.doc

　　《中小型企业员工离职原因与对策分析—以锦州石化为例》10000字.doc

　　T_CNHAW 0019—2025(肛门直肠狭窄中西医结合诊疗指南).pdf

　　2023年保定数字城市投资发展集团有限公司招聘考试试题及答案解析.docx

　　2.6 直线系方程与圆系方程-(选择性必修第一册) (教师版).docx

　　原创力文档创建于2008年，本站为文档C2C交易模式，即用户上传的文档直接分享给其他用户（可下载、阅读），本站只是中间服务平台，本站所有文档下载所得的收益归上传人所有。原创力文档是网络服务平台方，若您的权利被侵害，请发链接和相关诉求至 电线) ，上传者