您当前所在的位置:首页 > 关于我们 > 新闻中心

“异地多活”多IDC机房部署经验谈

来源:未知 发布时间:2015-05-25

 摘要:“异地双活”,或称“多机房部署”异地多活的好处包括异地灾备、提升访问速度、降低部署成本等,通过实践发现优势包括异地容灾、动态加速、流量均衡、在线压测等,而挑战包括增加研发复杂度、存储成本增加等。

近期阿里巴巴的同学分享了阿里在“异地双活”(微博称“多机房部署”,为便于理解本文统称“异地多活”)的一些经验( http://www.infoq.com/cn/articles/interview-alibaba-bixuan ),由于我曾代表平台在2012年主导微博的广州机房部署项目以及北京双机房部署项目,也分享一下微博在多机房部署方面的一些心得和踩过的坑。

异地多活的好处阿里同学已经充分阐述,微博的初始出发点包括异地灾备、提升南方电信用户访问速度、提升海外用户访问速度、降低部署成本(北京机房机架费太贵了)等。通过实践发现优势包括异地容灾、动态加速、流量均衡、在线压测等,而挑战包括增加研发复杂度、存储成本增加等。

微博外部历程

先说说微博外部的历程,整个过程可谓是一波多折。微博的主要机房都集中在北京,只有很小一部分业务在广州部署,2010年10月因微博高速发展准备扩大广州机房服务器规模,并对微博做异地双活部署。第一版跨机房消息同步方案采取的是基于自研的MytriggerQ(借助MySQL从库的触发器将INSERT、UPDATE、DELETE等事件转为消息)的方案,这个方案的好处是跨机房的消息同步通过MySQL的主从完成的,方案的成熟度高。而缺点则是,微博同一个业务会有好几张表,而每张表的信息又不全,这样每发一条微博会有多条消息先后到达,这样导致有较多时序问题,缓存容易花。第一套方案未能成功,但也让我们认识了跨机房消息同步的核心问题,并促使我们全面下线MytriggerQ的消息同步方案,而改用基于业务写消息到MCQ(MemcacheQ,新浪自研的一套消息队列,类MC协议,参见 http://memcachedb.org/memcacheq/ )的解决方案。

2011年底在微博平台化完成后,开始启用基于MCQ(微博自研的消息队列)的跨机房消息同步方案,并开发出跨机房消息同步组件WMB(Weibo Message Broker)。经过与微博PC端等部门同学的共同努力,终于在2012年5月完成Weibo.com在广州机房的上线,实现了“异地双活”。

由于广州机房总体的机器规模较小,为了提升微博核心系统容灾能力,2013年年中我们又将北京的机房进行拆分,至此微博平台实现了异地三节点的部署模式。依托于此模式,微博具备了在线容量评估、分级上线、快速流量均衡等能力,应对极端峰值能力和应对故障能力大大提升,之后历次元旦、春晚峰值均顺利应对,日常上线导致的故障也大大减少。上线后,根据微博运营情况及成本的需要,也曾数次调整各个机房的服务器规模,但是整套技术上已经基本成熟。

异地多活面临的挑战

机房之间的延时:微博北京的两个核心机房间延时在1ms左右,但北京机房到广州机房则有近40ms的延时。对比一下,微博核心Feed接口的总平均耗时也就在120ms左右。微博Feed会依赖几十个服务上百个资源,如果都跨机房请求,性能将会惨不忍睹;

专线问题:为了做广州机房外部,微博租了两条北京到广州的专线,成本巨大。同时单条专线的稳定性也很难保障,基本上每个月都会有或大或小的问题;

数据同步问题:MySQL如何做数据同步?HBase如何做数据同步?还有各种自研的组件,这些统统要做多机房数据同步。几十毫秒的延时,加上路途遥远导致的较弱网络质量(我们的专线每个月都会有或大或小的问题),数据同步是非常大的挑战;

依赖服务部署问题:如同阿里目前只做了交易单元的“异地双活”,微博部署时也面临核心服务过多依赖小服务的问题。将小服务全部部署改造成本、维护成本过大,不部署则会遇到之前提到的机房之间延时导致整体性能无法接受的问题;

配套体系问题:只是服务部署没有流量引入就不能称为“双活”,而要引入流量就要求配套的服务和流程都能支持异地部署,包括预览、发布、测试、监控、降级等都要进行相应改造;

微博异地多活解决方案

由于几十毫秒的延时,跨机房服务调用性能很差,异地多活部署的主体服务必须要做数据的冗余存储,并辅以缓存等构成一套独立而相对完整的服务。数据同步有很多层面,包括消息层面、缓存层面、数据库层面,每一个层面都可以做数据同步。由于基于MytriggerQ的方案的失败,微博后来采取的是基于MCQ的WMB消息同步方案,并通过消息对缓存更新,加上微博缓存高可用架构,可以做到即便数据库同步有问题从用户体验看服务还是正常的。

这套方案中,每个机房的缓存是完全独立的,由每个机房的Processor(专门负责消息处理的程序,类Storm)根据收到的消息进行缓存更新。由于消息不会重复分发,而且信息完备,所以MytriggerQ方案存在的缓存更新脏数据问题就解决了。而当缓存不存在时,会穿透到MySQL从库,然后进行回种。可能出现的问题是,缓存穿透,但是MySQL从库如果此时出现延迟,这样就会把脏数据种到缓存中。我们的解决方案是做一个延时10分钟的消息队列,然后由一个处理程序来根据这个消息做数据的重新载入。一般从库延时时间不超过10分钟,而10分钟内的脏数据在微博的业务场景下也是可以接受的。

微博的异地多活方案如下图(三个节点类似,消息同步都是通过WMB):

异地多活最好的姿势

以上介绍了一下微博在异地多活方面的实践和心得,像没有完美的通用架构一样,异地多活的最佳方案也要因业务情形而定。如果业务请求量比较小,则根本没有必要做异地多活,数据库冷备足够了。不管哪种方案,异地多活的资源成本、开发成本相比与单机房部署模式都会大大增加。

以下是方案选型时需要考虑的一些维度:

能否整业务迁移:如果机器资源不足,建议优先将一些体系独立的服务整体迁移,这样可以为核心服务节省出大量的机架资源。如果这样之后,机架资源仍然不足,再做异地多活部署;

服务关联是否复杂:如果服务关联比较简单,则单元化、基于跨机房消息同步的解决方案都可以采用。不管哪种方式,关联的服务也都要做异地多活部署,以确保各个机房对关联业务的请求都落在本机房内;

是否方便对用户分区:比如很多游戏类、邮箱类服务由于用户可以很方便分区就非常适合单元化,而SNS类的产品因为关系公用等问题不太适合单元化;

谨慎挑选第二机房:尽量挑选离主机房较近(网络延时在10ms以内)且专线质量好的机房做第二中心。这样大多数的小服务依赖问题都可以简化掉,可以集中精力处理核心业务的异地双活问题。同时,专线的成本占比也比较小。以北京为例,做异地多活建议选择天津、内蒙古、山西等地的机房;

控制部署规模:在数据层自身支持跨机房服务之前,不建议部署超过两个的机房。因为异地两个机房,异地容灾的目的已经达成,且服务器规模足够大各种配套的设施也会比较健全,运维成本也相对可控。当扩展到三个点之后,新机房基础设施磨合、运维决策的成本等都会大幅增加;

消息同步服务化:建议扩展各自的消息服务,从中间件或者服务层面直接支持跨机房消息同步,将消息体大小控制在10k以下,跨机房消息同步的性能和成本都比较可控。机房间的数据一致性只通过消息同步服务解决,机房内部解决缓存等与消息的一致性问题。跨机房消息同步的核心点在于消息不能丢,微博由于使用的是MCQ,通过本地写远程读的方式,可以很方便的实现高效稳定的跨机房消息同步;

异地多活的新方向

时间到了2015年,新技术层出不穷,之前很多成本很高的事情目前都有了很好的解决方案。接下来我们将在近五年异地多活部署探索的基础上,继续将微博的异地多活部署体系化。

升级跨机房消息同步组件为跨机房消息同步服务。面向业务隔离跨机房消息同步的复杂性,业务只需要对消息进行处理即可,消息的跨机房分发、一致性等由跨机房同步服务保障。且可以作为所有业务跨机房消息同步的专用通道,各个业务均可以复用,类似于快递公司的角色。

推进Web层的异地部署。由于远距离专线成本巨大且稳定性很难保障,我们已暂时放弃远程异地部署,而改为业务逻辑近距离隔离部署,将Web层进行远程异地部署。同时,计划不再依赖昂贵且不稳定的专线,而借助于通过算法寻找较优路径的方法通过公网进行数据传输。这样我们就可以将Web层部署到离用户更近的机房,提升用户的访问性能。依据我们去年做微博Feed全链路的经验,中间链路占掉了90%以上的用户访问时间,将Web层部署的离用户更近将能大大提升用户访问性能和体验。

借助微服务解决中小服务依赖问题。将对资源等的操作包装为微服务,并将中小业务迁移到微服务架构。这样只需要对几个微服务进行异地多活部署改造,众多的中小业务就不再需要关心异地部署问题,从而可以低成本完成众多中小服务的异地多活部署改造。

利用Docker提升前端快速扩容能力。借助Docker的动态扩容能力,当流量过大时分钟级从其他服务池摘下一批机器,并完成本服务池的扩容。之后也可以将各种资源也纳入到Docker动态部署的范围,进一步扩大动态调度的机器源范围。

以上是对微博异地多活部署的一些总结和思考,希望能够对大家有所启发。

上一篇:兆维工业园区电力整改通知

下一篇:没有了

Copyright © 2014 北京市微网聚力版权所有 . All Rights Reserved 京ICP备14025704号 增值电信业务经营许可证 京B1-20160057 京公网安备11010802015990号 Website Design & Power by HE JUN