运维:你好,给你介绍一下新浪微博被拖垮这件事儿

摘要: 站在运维的角度,谈谈鹿晗拖垮新浪微博这件事儿。

10-12 12:24 首页 InfoQ
编辑|谢然
鹿晗宣布恋情拖垮新浪微博

就在国庆长假的最后一天,10 月 8 日中午 12:00,艺人鹿晗通过微博公开与艺人关晓彤恋情,12:02 关晓彤进行了回复。紧跟着 12:32,新浪微博客户端爆出无法正常刷新、评论、多页面无法正常显示等问题。直到下午 4:04,微博搜索工程师丁振凯发微博 “埋怨”鹿晗,称:“服务器稳定了,岳父喊我喝酒去了,都是鹿晗干的好事!”。

下午 4:32,微博 CEO@来去之间表示,紧急租用增加了 1000 台阿里云服务器来应对流量高峰,确保网友们能正常访问微博。

网友热评

下午 17:42,“微博数据助手”证实,导致微博瘫痪的“元凶”正是鹿晗在中午发布的公布恋情的微博。数据显示,鹿晗公布恋情的微博共收获转发 462,884 次、 评论 986,409 条,点赞 2,566,617 个。

针对这条数据,一知乎网友评论:这是不全面的,单纯的转发评论多,并不能压垮微博。况且鹿晗的这条微博在微博史上并不算转发评论最多的一条。是因为转发、评论密集度太大了,短时间同时在线迅速爆涨,把服务器挤跨了。

还有知乎网友将此次微博宕机归咎于数据库问题。但想想微博这种级别的架构根本不是简单的分布式 server+DB 就能抗住的。别说是一个热点新闻,就算平时运营的压力也扛不住。另有网友提出数据库的吞吐量远大于 web server。

还有知乎网友分析是因为“微博自动扩容的算法没写好”,其实不然,知乎网友 @M 鹿 M 是这样反驳的:恰是因为自动扩容的算法写的太好了,才有了这次灾难。如果流量短时间内暴涨的太历害,稍做 Delay 几百毫秒,灾情就会过去;如果反应非常灵敏,流量上来了马上扩容增机,很快服务器集群池就会耗净。等到最后一台服务器被 100% 征用后,任何一个用户的回复就成了压倒骆驼的最后一根稻草,一个服务器跨了,流量迅速压向其它服务器,引发多米诺骨牌效应,服务器们指数级迅速宕下。

流量峰值面前,到底该关注什么?

新浪微博的资深运维架构师王关胜在 2016 杭州云栖大会的“开发者技术峰会”上,发表题为 《微博混合云 DCP:极端流量下的峰值应对与架构挑战》 的精彩演讲,在演讲中他提出:第一点是快速扩容、及时回收,这考验的是系统的弹性扩容、峰值应对的能力,这也是系统设计的最核心的目标;第二点要注意成本优化,可伸缩的业务利用公有云,私有云内弹性部署;第三点是运维标准化,微博流量来源主要是 PC 端和移动端,但两者的开发语言是不同的,因此系统需要打通多语言环境,通过 Docker 实现全公司统一平台;第四点,由于业务迭代快速迭代,因此基础设施需要标准化,以供公有云和私有云使用。

传统的峰值应对手段第一步需要设备申请,项目评审;第二步需要入 CMDB,上架装机;之后需要设备录入资源池,机器初始化;第三步需要运维人员进行服务部署,包括环境、监控、服务部署和流量引入;当流量峰值下降时,还需要服务自动下线以及设备置换或下架。整个链路十分冗长,大部分操作需要人工介入,而且依赖于企业内不同部门相互配合,在业务快速发展的今天,传统应对峰值的手段显然已经过时。

新浪微博是如何应对流量峰值的?

新浪微博混合云 DCP 项目技术负责人付稳在今年 4 月份 QCon 北京上,做了题为《新浪微博混合云架构应用实践之路》的演讲。

付稳回顾:每年的元旦、春晚、红包飞等会为微博带来巨大的流量挑战,这些业务场景的主要特点是:瞬间峰值高、持续时间短。每一次峰值事件的互动时间在 3 小时左右,而明星事件、红包飞等业务,经常会遇到高达多倍的瞬间峰值。微博 IT 的传统应对手段,主要是“靠提前申请足够的设备保证冗余、降级非核心及周边的业务”这两种,除了需要提前预知相关 IT 成本外,还有业务负载饱和度不一、扩缩容流程繁琐且周期长等问题。

付稳表示:当流量激增形成脉冲计算,要保证系统的稳定性和服务的正常运转,唯一的办法就是快速扩容,甚至实时扩容。新浪微博引入了阿里云的弹性计算资源来应对流量短时高峰。

混合云 DCP 核心是弹性伸缩

DCP 系统最核心的是弹性伸缩,能根据容量情况进行自动的弹性伸缩,以此来解决明显的早晚高峰及热点事件的峰值问题。

微博采用的正是 DCP 的弹性伸缩方案来应对流量峰值。架构内部主要采用私有云,早期采用物理机部署,通过化零为整建立冗余池;此外通过 OpenStack+KVM 的虚拟化方式进行资源整合,建立 VM 池。在公有云方面,通过采用阿里云等设施进行多云对接。

微博混合云平台 DCP 设计理念

微博混合云平台 DCP 的核心设计思想,主要是借鉴银行的运作机制,在内部设立一个计算资源共享池外,既有内部私有云的需求,又引入了外部公有云,使其在设备资源的弹性能力大大提升。

建立统一的设备资源管理池后,下一步需要考虑的是服务部署、资源调度等问题。目前,微博采用的是基于 Docker 的云化架构:业务上,由于部分业务并非无缝迁移到该架构上,这时需要对业务进行微服务化、消息化等改造;平台上,需要部署敏捷基础设施,打通持续集成平台以及实现多租户隔离、弹性伸缩、故障自愈等能力。

除了公有云具有弹性伸缩能力之外,私有云也可以具有弹性。公司内某个部门可能就有很多业务,如果每个业务都保留很多冗余则会导致资源的大量闲置浪费。微博采用的是将每个业务的冗余拿出来放到共用的共享池内,当业务有需求时,从共享池内申请冗余;使用完成后归还申请的服务器,通过这种方式实现私有云的弹性伸缩。

在应对流量峰值时,除了弹性伸缩系统,还需要统一的监控平台、核心链路服务自动伸缩、预案 & 干预手段相互配合,以保障峰值服务正常运行。

DCP 系统架构优势

DCP 平台,主要包含 4 层架构:主机层、调度层及业务编排层,最上层则是各业务方系统。底层的混合云基础架构则架 Dispatch 设了专线,打通微博内部私有云以及阿里云。

DCP 目前已经具备 20 分钟内弹性扩容千台服务器规模,所谓 20 分钟内弹性扩容千台服务器规模,即公有云要满足 10 分钟内完成上千台服务器的创建与交付,同时,微博 DCP 平台则在接下来的 10 分钟内完成服务器的初始化、服务调度、上线等全流程,包括操作系统的安装、Docker 及运维软件环境的安装、各种授权、服务的启动、流量的引入、上线等,这些全部在 20 分钟内完成。峰值来临迅速调度部署云服务器为新浪微博的流量峰值分摊流量,可以很好的解决私有云短时间无法迅速扩容服务器的问题。公有云的按量弹性需求十分贴合新浪微博的需求,也可以降低大量成本。

新浪微博平台核心总体分为前端和后端平台,前端主要是 PC 端、移动端、开放平台以及企业开放平台,后端平台主要是 Java、PHP 编写的各种接口层、服务层、中间件层及存储层。就平台前端来说,每日超过千亿次的 API 调用、超过万亿的 RPC 调用,产生的日志就达百 T+。这么大体量的业务系统对于运维的要求也很严格,例如接口层的 SLA 服务水平协议就必须达到 4 个 9,接口平均响应时间不能高于 50ms。

有 DCP 做后盾,新浪微博为啥还是挂了?

蘑菇街运维经理赵成于今天凌晨在微信 《从技术角度谈谈鹿晗这个事儿》 里表示: 源于用户访问模型,这次事件的模型一定是跟平时正常时期的热点访问模型不一样,对于微博技术团队来说极有可能是没有遇到过这样的访问模型,今天突发,自然也就是没有对应的立马见效的预案执行,或者执行了没有马上见到效果,只能摸索着尝试。

写在最后

新浪微博几亿 + 的用户量,热点事件给其带来数倍流量瞬间暴增,如何不影响用户体验,又不增加巨大的服务器成本投入对技术是一个挑战。

在应对流量峰值时,单单依靠管理员进行人工操作是远远不够的,因此“无人值守”的自动化扩缩容显得十分必要。要实现“无人值守”的扩缩容,首先内部的工具系统需要实现自动化,各系统之间通过 API 打通,实现全部系统间的联动。

运维自动化包含业务指标和容量指标监控,将产生的数据提供给容量决策系统,在容量决策系统的决策下,实现从运维自动化进化为无人值守的扩缩容。


首页 - InfoQ 的更多文章: