微博作为当今中文社交媒体的第一品牌，拥有超过3.6亿的月活用户，也是当前社会热点事件传播的最主要平台。而热点事件往往具有不可预测性和突发性，10分钟内可能带来流量的翻倍增长，甚至更大。如何快速应对突发流量的冲击，确保线上服务的稳定性，是一个非常巨大的挑战。 传统的人工值守，手工扩容的运维手段，显然无法满足这一需求。为此，我们的目标是做到系统的自动扩容，在流量增长达到系统的警戒水位线时自动扩容，以应对任意时刻可能爆发的流量增长，确保服务的高可用性。

微博作为当今中文社交媒体的第一品牌，拥有超过 3.6 亿的月活用户，也是当前社会热点事件传播的最主要平台。热点事件的发生具有不可预测性和突发性，以 9 月 26 日上午“谢娜宣布怀孕”事件为例，从图 1 可以看出微博评论的流量在短短 10 分钟内迅速上涨，并在 20 分钟后达到了日常晚高峰的 2 倍之多。可见，为了应对突发事件带来的流量冲击，确保线上服务的稳定性，能够进行随时随地的快速弹性扩容十分重要。

传统的面对而传统的人工值守，手工扩容的运维手段，显然无法满足这一需求。为此，我们的目标是做到系统的自动扩容，在流量增长达到系统的警戒水位线时自动扩容，以应对任意时刻可能爆发的流量增长，确保服务的高可用性。

微博 Web 弹性调度演进
接下来，将为大家介绍微博 Web 系统如何从人工值守的手工扩缩容一步步演进到无人值守的自动扩缩容。

第一代：人为触发扩缩容
人工根据监控系统的 QPS、AvgTime、load 等判断是否扩容；

根据经验值人为预估扩容机器数；

支持 PC、手机等多渠道触发。

问题：需要人为介入确认扩容时机和扩容数量。

第二代：无人值守定时扩缩容
每天晚上 8 点定时扩容，12 点前定时缩容；

Web 与依赖的 RPC 可以依赖扩容。

问题：只能解决晚高峰问题，无法应对突发事件。

第三代：智能触发自动扩缩容
自动压测评估线上服务池最大承载量

实时评估线上服务池冗余度

冗余度不足则触发扩容，充足则触发缩容

下图展示了在 # 薛之谦与前期复合 # 事件中，智能触发自动扩缩容的实际效果。

下面对智能弹性调度系统进行详细介绍，图 6 展示了这一系统包括的几个主要组成部分。

全数据日志分析 Profile，生成业务系统的各种指标并采集汇报给实时监控系统 Graphite。

实时监控功能系统 Graphite，实时汇聚并计算多维度业务指标数据，并提供 API 给在线容量评估以及智能弹性调度系统已作决策。

在线容量评估系统 Diviner，对在线服务池进行压测，以评估服务池的最大承载能力。

智能弹性调度系统 DCOS，根据系统实时的水位线情况，决策是否需要进行扩容以及扩容机器数。

混合云平台 DCP，向私有云和公有云申请机器，进行弹性扩容。

Profile- 全数据日志体系
在实际的扩容决策中，需要以一些关键指标如 QPS、AvgTime 或多种指标叠加作为判断依据，所以自动扩缩容系统首先要解决的问题就是关键指标的生成和采集。

指标的生产
一般情况下，指标的生产有两种方式：一种是在业务代码里以特定格式打印各业务关心的业务指标日志，如 API 的 QPS、AvgTime 等，但这种方式对业务代码的侵入性强，不建议采纳；一种是在框架的关键路径上埋点，统一打印 metric 日志，不侵入业务代码，对业务开发更加友好。我们就采用了这种方式，如在 motan 服务化框架上埋点，来记录 RPC 调用的 QPS、AvgTime、P99 等指标。

指标的采集
指标的采集主要涉及两个问题，一个是如何规范 metric 日志，便于在不同系统间传递，一个是如何传输的问题，有多种途径如 scirbe、kafka、udp 等。为了解决第一个问题，我们制定了规范的 profile 日志格式，各种 metric 信息均以标准的格式记录，如下图 7 所示。为了简化系统和传输效率，我们通过 udp 方式将各种 metric 信息传递给监控系统。

实时监控系统
有了关键业务指标的 Profile 日志，就可以对它们进行实时监控，其工作原理如图 8 所示。

从上图可以看出，实时监控系统的核心就是 Graphite。它主要包含两方面的功能：

将实时传输的 profile 日志进行聚合计算，产生各种维度的数据存储到时序数据库中。

还需要提供 API 接口，以提供 dashboard 展示，压测系统以及智能调度系统调用以用于扩缩容决策。下面将对 Graphite 进行详细介绍，其架构如图 9 所示。

为了减少延迟，我们对 graphite 系统中的关键模块进行了优化，主要包括两个方面：

用 go 重写了 statsd-proxy 和 statsd 模块

carbon 中添加缓存，7 天的数据存储在缓存中，7 天以外的数据存到 SSD。

在线容量评估系统
有了关键业务指标的实时监控，就可以对系统进行压测，以评估系统的最大支撑能力。而如何对系统进行压测，以合理评估系统的承载能力主要取决于两个方面：

合理选择业务指标来衡量系统健康度；

精确定位性能拐点以确定系统临界值。

下面分别就上面两个问题进行阐述。

合理选择业务指标来衡量系统健康度

常见的可作为衡量系统健康度的指标有 avgTime、load、5xx、连接数等，对于单一业务模型的系统来说，选取其中一个指标即可。但对于复杂的业务系统，以微博 web 系统为例，既包含了 CPU 和带宽消耗较高的 feed 接口，又包含了低延迟和高并发的计数器接口，单一接口健康并不能代表整个系统健康。除此之外，单一指标正常也不能代表系统正常，比如我们经常遇到 feed 接口 avgTime 正常，但延迟大于 1s 的比率超过了 1%，这时候会直接造成 1% 用户刷新失败，影响了用户体验。

为此，我们建立了多接口多指标的健康度评估模型。

多接口，是指选取服务池中多个具有代表性的接口，并且还会考虑整体服务池中接口的情况，比如我们在微博 web 系统中不仅选取了 feed 接口，还选取了计数器接口等。

多指标，是指不仅仅选取单一指标作为参照，比如我们在实际压测过程中，会考虑接口的平均耗时、5XX 以及慢速比（延迟超过 1s 的比率）。

精确定位性能拐点以确定系统临界值

常用的系统压测方案主要包括两种：

在线缩减机器数量以增加单机承载量，从而压测到单机承载能力的最大值。

模拟洪峰，对服务池进行全链路压测，以模拟出峰值流量下系统的承载能力。

目前，我们主要采用方案 1 进行压测。通过减少在线机器数，以增加单机承载量来压测，直到服务池的健康度到达临界点时暂停压测，待系统恢复后，继续缩减在线机器数，否则则停止压测并记录服务池的临界值。

智能弹性调度系统
有了系统的最大承载能力，就可以根据实时监控系统中服务池当前的流量，来决定是否需要扩缩容以及扩容机器数。智能弹性调度的智能主要体现在两个方面：

快。

智能弹性调度并不等到系统的承载量已经濒临临界值时才进行扩容，因为此时可能流量很快上涨超过水位线，在扩容完成之前就已经把系统压垮了。为此，我们给系统设置了三条线：致命线、警戒线、安全线，如图 10 所示。

致命线。从字面意义上即可理解，当服务池的流量一旦触及致命线，就应当立即扩容。通常致命线的设定与业务的重要程度有关，一般核心系统的致命线设定要高一些，保证足够的冗余度，目前微博核心 web 系统的致命线设定为 1.6 倍冗余。

警戒线。当服务池的流量到达警戒线时，再结合业务指标综合考量是否需要扩容。以微博核心 web 系统为例，如果流量到达警戒线，并且 1s 的慢速比超过了 1%，也需要进行扩容。

安全线。主要用于决策缩容，当服务池的流量在安全线以上，则可以进行缩容。

准。

主要体现在两个方面：防抖动和合理扩容。

防抖动。当系统的承载量到达临界值时，理论上要进行扩容。但还要考虑在实际线上系统运行时，经常出现系统偶发的抖动现象，避免因为偶发抖动触发临界值进行扩容带来不必要的机器成本。为此，我们在智能弹性调度系统中，设定了 1min 的采集周期，并设置了 5min 的滑动窗口。在这个滑动窗口内采集的 5 个点中，任意满足 3 个点即判断需要扩容。

合理扩容。智能弹性调度系统会根据系统当前的水位线，以及系统当前机器数评估出合理的扩容机器数，按需扩容，避免浪费机器成本。

混合云平台 DCP
混合云平台 DCP 主要职能是向内部私有云和外部公有云申请机器，并部署服务扩容到线上服务池。目前微博混合云 DCP 平台，具备 15 分钟内扩容 1000+ 服务器的能力，关于这部分的介绍不是本文的重点，感兴趣的童鞋关注微博 OpenDCP 的 github 主页：

https://github.com/weibocom/opendcp