酷应用

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

百家作者：InfoQ 2017-10-10 02:11:51

编辑｜谢然

鹿晗宣布恋情拖垮新浪微博

就在国庆长假的最后一天，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 打通，实现全部系统间的联动。

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