微博广告系统全景运维大法( 二 ) _微博

传统的业务运维

文章插图
按照传统运维模式，扩容计划从立项到服务器上线，会经过诸多的流程跟漫长的等待。
从结果上来看，服务器扩容了，而且对传统项目而言，整体流程都是可控的，这是它的优点。
它的缺点不言而喻，有以下几点：
首先，它时效性太差，如果按照新浪服务器的采购周期，从审计到上线需要两个月的流程。两个月后服务器上线，恐怕刚结婚的明星都已经离婚了，突发事件流量都已经过去了。
另外，它无法准确预估容量，在传统的业务运维模式下，范冰冰分手、双宋离婚带来的流量是无法实现的，我们无法评估扩容量。
除此之外，传统模式下资源利用率比较低，服务器很难在业务间共享。
在这些问题共同作用下催生了动态扩缩容体系。
弹性计算：实时动态扩缩容

文章插图
动态扩缩容不是一个工具，是一整套体系。它基于云服务，包含了在线压力检测和消耗度评测的功能，最终实现分级治理。
①弹性计算架构

文章插图
首先简单介绍一下弹性计算的架构，弹性计算依托于 Kunkka 自动化运维平台，以及 Oops 监控平台，在业务压测的情况下获取业务指标监控，将数据送到容量决策系统，做出是否扩缩容的决定。
在云服务商方面，我们常用阿里云、华为云跟一部分自建的私有云。DCP 混合平台是我们微博另外一个团队做了几年的平台，它能够对接云服务，快速生成云主机快速扩容。
今天的重点跟业务方有着最直接的关系：业务上要不要扩容？什么时候扩容？扩多少？我们要解决这样的问题。
②决策系统

文章插图
在上文的架构中，我们提到了容量决策系统，容量决策系统实际上指的是计算系统，会对我们获取到的业务指标进行计算、评估。
比如系统的基础信息、一些业务上日志来源的信息等，得到当前业务的容量，通过对历史数据进行同比、环比的分析，得到流量趋势，了解接下来流量会变成什么样子，这两组数据计算结果会给出扩缩容的建议。
同时，他们会计算这些数据并予以呈现，提供一个辅助的 API 接口，给上下游部门做扩缩容数据。
③容量评估方法
这个业务的当前容量是什么样的？是不是健康的？这个指标靠什么来评估？
由于业务系统、业务形态、架构的不同，选取一个实时且通用的指标是非常具有挑战性的，我们也尝试了很久，引入了 AVG-hits 的概念。
对于处在不同时间内的请求数进行加权、求和来拟合实际的单机消耗量，这个代表的是在不同的区间的耗时数，我们给它一个系数，大于 5 毫秒小于 10 毫秒，根据自己的业务给予耗时分区，这样就能计算出来。
事实证明，与之前传统的单一 QPS 负载对比起来，综合的数据对业务的评估比这种单一指标是更加准确的。
在获得这个数据之后是不是就能够描述当前的系统容量呢？
回答是肯定不能， AVG-hits 这个概念第一次接触，确实是有点生涩，举个简单的例子来帮助理解，比如说某个业务消耗指标衡量非常简单，需要通过内存判断消耗情况。
如果监控指标提示内存消耗到 80G ，那能不能用 80G 来描述当前系统的消耗情况？
这样问就比较容易理解，回答肯定是不能的，因为不知道服务器最大的内存是多少，如果最大是 96G ，那么 80G 已经超过 80% 了，接近危险值，如果最大内存是 256G 则消耗不到 30% ，是非常安全的值。
道理是一样的，仅拿到当前消耗值是不能对业务当前状态进行描述的，还需要另一个评估标准。