微博“异地多活”部署经验谈

  • 时间:
  • 浏览:0
  • 来源:大发彩神6合_大发神彩6合官方

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

微博的异地多活方案如下图(另一兩个 节点相似,消息同步完整版都是通过WMB):

阿里巴巴确定了单元化的出理 方案,这套方案的优势是将用户分区,也不 所有四种 用户相关的数据完整版都是另一兩个 单元里。通过这套方案,都不可不可以较好的控制成本。但缺点是除了主维度(阿里巴巴是买家维度),其他所有的数据还是要做跨机房同步,整体的简化度基本没降低。另外也不 数据分离后原应拆成了相当于两份数据,数据查询、扩展、问题报告 报告 出理 等成本均会增加较多。总的来讲,个人认为这套方案更适用于WhatsApp、Instagram等国外业务相对简单的应用,而不适用于国内功能简化、依赖众多的应用。

以下是方案选型时还要考虑的其他维度:

以上介绍了一下微博在异地多活方面的实践和益得,也对比了一下阿里巴巴的出理 方案。就像都不可不可以不可不可以 完美的通用架构一样,异地多活的最佳方案也要因业务状况而定。原应业务请求量比较小,则根本都不可不可以不可不可以 必要做异地多活,数据库冷备足够了。不管哪种方案,异地多活的资源成本、开发成本相比与单机房部署模式,都是大大增加。

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

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

关于为应对故障而进行数据冗余的问题报告 报告 ,阿里巴巴的同学也做了充分的阐述,在此也补充一下我门的其他经验。微博核心池容量冗余分另一兩个 层面来做,前端Web层冗余同用户规模成正比,并预留日常峰值30%左右的冗余度,而后端缓存等资源原应相对成本较低,每个机房均按照整体两倍的规模进行冗余。也不 原应某另一兩个 机房不可用,首先我门后端的资源是足够的。接着我门首先会只将核心接口进行迁移,四种 操作分钟级即可完成,同時 原应冗余是按照整体的30%,全都 即使所有的核心接口流量完整版迁移过来不可不可以支撑住。接下来,我门会把其他服务池的前端机也改为部署核心池前端机,也不 在一小时内即可实现整体流量的承接。同時 ,原应故障机房是负责数据落地的机房,DBA会将从库升为主库,运维调整队列机开关配置,承接数据落地功能。而在整个过程中,原应我门核心缓存都不可不可以脱离数据库支撑另一兩个 小时左右,全都 服务整体会保持平稳。

跟阿里巴巴遇到的问题报告 报告 相似,我门也遇到了数据库同步的问题报告 报告 。原应微博对数据库完整版都是强依赖,换成数据库双写的维护成本过大,我门确定的方案是数据库通过主从同步的措施 进行。这套方案原应的缺点是原应主从同步慢,也不 缓存穿透,这时原应会出显脏数据。四种 同步措施 已运行了三年,整体上非常稳定,都不可不可以不可不可以 趋于稳定原应数据同步而原应的服务故障。从2013年也不刚结束了,微博启用HBase做在线业务的存储出理 方案,原应HBase四种 不支持多机房部署,换成早期HBase的业务比较小,且有单独接口都不可不可以回调北京机房,全都 都不可不可以不可不可以 做异地部署。到今年原应HBase支撑的对象库服务原应成为微博非常核心的基础服务,我门也在规划HBase的异地部署方案,主要的思路跟MySQL的方案相似,同步也在考虑基于MCQ同步的双机房HBase独立部署方案。

数据同步问题报告 报告 出理 也不,紧接着就要出理 依赖服务部署的问题报告 报告 。原应微博平台对外提供的完整版都是Restful风格的API接口,全都 独立业务的接口都不可不可以直接通过专线引流回北京机房。也不 对于微博Feed接口的依赖服务,直接引流回北京机房会将平均出理 时间从百毫秒的量级直接升至几秒的量级,这对服务是无法接受的。全都 ,在2012年我门对微博Feed依赖的主要服务也做了异地多活部署,整体的出理 时间终于降了下来。当然这完整版都是最优的出理 方案,但在当时微博业务体系还相对简单的状况下,很好地出理 了问题报告 报告 ,确保了2012年5月的广州机房部署任务的达成。

以上是对微博异地多活部署的其他总结和思考,希望不用可不可以对我门有所启发,也希望看了更多的同学分享一下个人公司的异地多活架构方案。

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

原文发布时间:2015-04-29

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

而配套体系的问题报告 报告 ,技术上完整版都是很简化,也不 操作时却很容易出问题报告 报告 。比如,微博也不也不结束了做异地多活部署时,测试同学都不可不可以不可不可以 在上线时对广州机房做预览测试,也不 原应过其他线上问题报告 报告 。配套体系还要覆盖整个业务研发周期,包括方案设计阶段的不是要做多机房部署、部署阶段的数据同步、发布预览、发布工具支持、监控覆盖支持、降级工具支持、流量迁移工具支持等方方面面,并需开发、测试、运维都参与进来,将关键点纳入到流程当中。

(题图来自:jimijones.com)

本文来自云栖战略战略合作伙伴“linux中国”

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

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

根据微博的实践,一般做异地多活都是遇到如下的问题报告 报告 :

第一版跨机房消息同步方案采取的是基于自研的MytriggerQ(借助MySQL从库的触发器将INSERT、UPDATE、DELETE等事件转为消息)的方案,四种 方案的好处是,跨机房的消息同步是通过MySQL的主从完成的,方案心智成熟的句子的句子的句子 度高。而缺点则是,微博同另一兩个 业务会有好几张表,而每张表的信息又不全,也不 每发一根微博会有多条消息先后到达,也不 原应有较多时序问题报告 报告 ,缓存容易花。

先说说微博实物的历程,整个过程可谓是一波多折。微博的主要机房都集中在北京,都不可不可以不可不可以 很小一主次业务在广州部署,2010年10月,因微博高速发展,全都 准备扩大广州机房服务器规模,并对微博做异地双活部署。

这套方案中,每个机房的缓存是完整版独立的,由每个机房的Processor(专门负责消息出理 的系统进程,类Storm)根据收到的消息进行缓存更新。原应消息不用重复分派,也不 信息完备,全都 MytriggerQ方案趋于稳定的缓存更新脏数据问题报告 报告 就出理 了。而当缓存不趋于稳定时,会穿透到MySQL从库,也不 进行回种。原应出显的问题报告 报告 是,缓存穿透,也不 MySQL从库原应此时出显延迟,也不 就会把脏数据种到缓存中。我门的出理 方案是做另一兩个 延时10分钟的消息队列,也不 由另一兩个 出理 系统进程来根据四种 消息做数据的重新载入。一般从库延时时间不超过10分钟,而10分钟内的脏数据在微博的业务场景下也是都不可不可以接受的。

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

第一套方案未能成功,但也我门我门认识到跨机房消息同步的核心问题报告 报告 ,并有有助于我门全面下线MytriggerQ的消息同步方案,而改用基于业务写消息到MCQ(MemcacheQ,新浪自研的一套消息队列,类MC协议)的出理 方案。

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