新浪微博上云实践：极端流量下的峰值应对与架构挑战.docxVIP

-------------各类专业好文档，值得你下载，教育，管理，论文，制度，方案手册，应有尽有-------------- ---------------------------------------------------------精品 文档--------------------------------------------------------------------- 新浪微博上云实践：极端流量下的峰值应对与架构挑战 本文章来自于阿里云云栖社区 摘要：?在混合云架构中，核心关键是专线，它是实现内部与公有云之间弹性的核心。目前微博和阿里云之间已经拉通了多条专线，日常的核心消息通过多机房的消息组件同步到阿里云缓存中，实现前端层面和缓存层面的弹性伸缩。在混合云的模式下，微博目前采用了两种部署方案。 做为目前最火的国内社交APP，微博常常在特定时间或特定事件发生时迎来流量高峰。通过对近五年时间应对的峰值进行总结，可以抽象为三种常见的峰值：? 第一种是日常的晚高峰； 第二种是各种运营活动以及明星、大V的热门微博所带来的流量高峰； 第三种是非常极端的突发事件导致的核心服务数倍的流量增长。 之所以需要关注这三类场景，主要是因为： 第一，尽管微博的功能众多，但冗余是非常少的，因此早晚高峰需要弹性扩容； 第二，活动、大V的热点事件能够提前预知，可以提前准备所需资源； 第三，极端事件是最需要关注的，它对系统的自动化程度要求非常高。 这三类场景可以简单总结为两大特点：瞬间峰值高、互动时间短。 流量高峰下的挑战 在应对流量峰值时，微博面临着以下三点挑战： 产品迭代快，目前微博的现状是功能多，依赖复杂，导致发布和变更频繁； 运营上，站内外，活动、运营、大V均有Push场景，导致全量极速下发，互动时间短； 技术上存在突发的极端流量，目前热点多，“马航”、“王宝强”等事件十分考验服务的弹性伸缩。 那么在应对流量峰值时，应该主要关注哪些方面呢？ 第一点是快速扩容、及时回收，这考验的是系统的弹性扩容、峰值应对的能力，这也是系统设计的最核心的目标； 第二点要注意成本优化，可伸缩的业务利用公有云，私有云内弹性部署； 第三点是运维标准化，微博流量来源主要是PC端和移动端，但两者的开发语言是不同的，因此系统需要打通多语言环境，通过Docker实现全公司统一平台； 第四点，由于业务迭代快速迭代，因此基础设施需要标准化，以供公有云和私有云使用。 传统应对手段 v.s. 云端弹性伸缩方案 传统的峰值应对手段第一步需要设备申请，项目评审；第二步需要入CMDB，上架装机；之后需要设备录入资源池，机器初始化；第三步需要运维人员进行服务部署，包括环境、监控、服务部署和流量引入；当流量峰值下降时，还需要服务自动下线以及设备置换或下架。整个链路十分冗长，大部分操作需要人工介入，而且依赖于企业内不同部门相互配合，在业务快速发展的今天，传统应对峰值的手段显然已经过时。 目前，微博采用的是DCP的弹性伸缩方案来应对流量峰值，具体架构如上图所示。架构内部主要采用私有云，早期采用物理机部署，通过化零为整建立冗余池；此外通过OpenStack+KVM的虚拟化方式进行资源整合，建立VM池。在公有云方面，通过采用阿里云等设施进行多云对接。 建立统一的设备资源管理池后，下一步需要考虑的是服务部署、资源调度等问题。目前，微博采用的是基于Docker的云化架构： 业务上，由于部分业务并非无缝迁移到该架构上，这时需要对业务进行微服务化、消息化等改造； 平台上，需要部署敏捷基础设施，打通持续集成平台以及实现多租户隔离、弹性伸缩、故障自愈等能力。 除了公有云具有弹性伸缩能力之外，私有云也可以具有弹性。公司内某个部门可能就有很多业务，如果每个业务都保留很多冗余则会导致资源的大量闲置浪费。微博采用的是将每个业务的冗余拿出来放到共用的共享池内，当业务有需求时，从共享池内申请冗余；使用完成后归还申请的服务器，通过这种方式实现私有云的弹性伸缩。 在应对流量峰值时，除了上面提到的弹性伸缩系统，还需要统一的监控平台、核心链路服务自动伸缩、预案干预手段相互配合，以保障峰值服务正常运行。 DCP的架构设计 下面是微博的DCP整体架构图。 最底层是物理主机资源；第二层是资源调度层；第三层是编排层，主要包括一些常见的自动化操作；最上层是业务层，由多种语言混合开发；架构的右侧是主要的基础设施。 在架构设计中面临的核心挑战主要包括以下三点。 镜像分发，包括镜像优化和分发速度的优化； 隔离设计，包括平台层隔离和部署/实例隔离； 弹性伸缩，包括自动扩缩容和故障转移。 下面分别进行说明。 架构挑战1：镜像分发 镜像分发的挑战，主要有镜像优化和分发速度的优化。 1. 镜像分发——镜像优化? 镜像优化主要从两点入手：一是镜像制