@citian3094
2017-11-13T00:33:46.000000Z
字数 1540
阅读 977
胡忠想，微博服务化项目架构师、技术负责人，2012年加入微博工作至今，承担过微博计数器架构升级，春晚和奥运服务保障，以及微博feed业务架构升级等工作。目前，主要专注于服务化方向，工作内容包括：微服务治理，弹性调度以及自动化监控等。
胡忠想将在ArchSummit分享《微博应对突发热点事件的弹性调度实践》，本文整理节选自11月9日胡忠想在InfoQ的直播中的微博调度演进，完整内容可关注ArchSummit公众号或InfoQ公众号获取。
微博作为当今中文社交媒体的第一品牌，拥有超过3.6亿的月活用户，也是当前社会热点事件传播的最主要平台。热点事件的发生具有不可预测性和突发性，以9月26日上午“谢娜宣布怀孕”事件为例，微博评论的流量在短短10分钟内迅速上涨，并在20分钟后达到了日常晚高峰的2倍之多。可见，为了应对突发事件带来的流量冲击，确保线上服务的稳定性，能够进行随时随地的快速弹性扩容十分重要。
传统的面对而传统的人工值守，手工扩容的运维手段，显然无法满足这一需求。为此，我们的目标是做到系统的自动扩容，在流量增长达到系统的警戒水位线时自动扩容，以应对任意时刻可能爆发的流量增长，确保服务的高可用性。
接下来，将为大家介绍微博 Web 系统如何从人工值守的手工扩缩容一步步演进到无人值守的自动扩缩容。
人工根据监控系统的 QPS、AvgTime、load 等判断是否扩容；
根据经验值人为预估扩容机器数；
支持 PC、手机等多渠道触发。
问题：需要人为介入确认扩容时机和扩容数量。
每天晚上 8 点定时扩容，12 点前定时缩容；
Web 与依赖的 RPC 可以依赖扩容。
问题：只能解决晚高峰问题，无法应对突发事件。
自动压测评估线上服务池最大承载量
实时评估线上服务池冗余度
冗余度不足则触发扩容，充足则触发缩容
下面对智能弹性调度系统进行详细介绍，图 6 展示了这一系统包括的几个主要组成部分。
全数据日志分析 Profile，生成业务系统的各种指标并采集汇报给实时监控系统 Graphite。
实时监控功能系统 Graphite，实时汇聚并计算多维度业务指标数据，并提供 API 给在线容量评估以及智能弹性调度系统已作决策。
在线容量评估系统 Diviner，对在线服务池进行压测，以评估服务池的最大承载能力。
智能弹性调度系统 DCOS，根据系统实时的水位线情况，决策是否需要进行扩容以及扩容机器数。
混合云平台 DCP，向私有云和公有云申请机器，进行弹性扩容。
在实际的扩容决策中，需要以一些关键指标如 QPS、AvgTime 或多种指标叠加作为判断依据，所以自动扩缩容系统首先要解决的问题就是关键指标的生成和采集。
一般情况下，指标的生产有两种方式：一种是在业务代码里以特定格式打印各业务关心的业务指标日志，如 API 的 QPS、AvgTime 等，但这种方式对业务代码的侵入性强，不建议采纳；一种是在框架的关键路径上埋点，统一打印 metric 日志，不侵入业务代码，对业务开发更加友好。我们就采用了这种方式，如在 motan 服务化框架上埋点，来记录 RPC 调用的 QPS、AvgTime、P99 等指标。
指标的采集主要涉及两个问题，一个是如何规范 metric 日志，便于在不同系统间传递，一个是如何传输的问题，有多种途径如 scirbe、kafka、udp 等。为了解决第一个问题，我们制定了规范的 profile 日志格式，各种 metric 信息均以标准的格式记录，如下图 7 所示。为了简化系统和传输效率，我们通过 udp 方式将各种 metric 信息传递给监控系统。