鹿晗关晓彤公布恋情微博服务器挤爆了,如何秒开千台服务器?

  • 时间:
  • 浏览:1

混合云 DCP 核心是弹性伸缩

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

DCP 系统架构优势



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

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

注:以上内容来源今日头条

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

针对这条数据,一知乎外国外国前前男友评论:这是不全面的,单纯的转发评论多,并可不后能 了压垮微博。况且鹿晗的这条微博在微博史上并不算转发评论最多的一根绳子 。是将会转发、评论密集度过多了,短时间一块儿在线没办法 来越快爆涨,把服务器挤跨了。

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

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

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

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

蘑菇街运维经理赵成于今天夜深 在微信 《从技术层厚谈谈鹿晗你这名事儿》 里表示: 源于用户访问模型,这次事件的模型一定是跟平时正常时期的热点访问模型不一样,对于微博技术团队来说极有将会是可不后能 了遇到过另另另另一个的访问模型,今天突发,自然也什么都有有我可不后能 了对应的立马见效的预案执行,将会执行了可不后能 了马上见到效果,可不后能 了摸索着尝试。

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

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

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

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

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

DCP 目前将会具备 20 分钟内弹性扩容千台服务器规模,所谓 20 分钟内弹性扩容千台服务器规模,即公有云要满足 10 分钟内完成上千台服务器的创建与交付,一块儿,微博 DCP 平台则在接下来的 10 分钟内完成服务器的初始化、服务调度、上线等全流程,包括操作系统的安装、Docker 及运维软件环境的安装、各种授权、服务的启动、流量的引入、上线等,哪几种删剪在 20 分钟内完成。峰值来临没办法 来越快调度部署云服务器为新浪微博的流量峰值分摊流量,可不都要很好的正确处理私有云短时间无法没办法 来越快扩容服务器的问题报告 。公有云的按量弹性需求十分贴合新浪微博的需求,也可不都要降低几瓶成本。

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

在应对流量峰值时,单单依靠管理员进行人工操作是远远过低的,为社 让“无人值守”的自动化扩缩容显得十分必要。要实现“无人值守”的扩缩容,首先内部内部结构的工具系统都要实现自动化,各系统之间通过 API 打通,实现删剪系统间的联动。

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

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

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

写在最后

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

流量峰值肩上,到底该关注哪几种?

除了公有云具有弹性伸缩能力之外,私有云也可不都要具有弹性。公司内某个部门将会都是什么都有有业务,将会每个业务都保留什么都有有冗余则会因为资源的几瓶闲置浪费。微博采用的是将每个业务的冗余玩转信用卡 来插进共用的共享池内,当业务有需求时,从共享池内申请冗余;使用完成后撤除申请的服务器,通过你这名土土办法实现私有云的弹性伸缩。

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

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

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