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

这个业务当前能承载的最大容量是多少？如果是看内存就简单了，可这是一个综合评估标准，要怎么拿到它呢？
作为一个有经验的运维，我觉得根据服务器当前硬件的表现，猜测最大容量不是困难的事情，但现在都 2019 年了，靠猜是不行的，我们通过压测获取最大容量值。
在实际环境中减少服务器数量，减少到不能再少，记录当前的容量值，作为最大容量，用压测开始之前的实际消耗值除以压测获取的最大容量，得到整个系统的消耗比。这个消耗比就认为是当前这个系统消耗的画像。
压测压到什么情况下达到最大容量不能再压呢？是要压到服务器宕机？
我们接入了另外一个概念叫消耗比，在耗时最大区间的 Ahits（请求数量）数（PPT 上显示：慢速比=100.0*当前容量（Ahits）/最大容量（max_Ahts））与总的请求数之比超过一定的比例，则是影响用户的体现。
这个压力达到最大值就不能再压了，就会记录当时的 Ahit 数，作为这个接口最大容量。

文章插图
④分级治理：水位线

文章插图
现在拿到了一个非常重要的容量值及消耗比来进行容量评估，用于描述当前的容量消耗情况。
拿到这个消耗比之后是不是就可以扩容了？还是可以缩容了？此处还需要一个评估标准，是 30% 就扩？还是 50% 再扩？
我们基于历史数据给予分析，制定了三条水位线，包括安全线、警戒线和致命线，拿当前消耗值与水位线进行对比，在不同阶段采取不同的措施。
比如，现在的消耗度远远低于安全线，说明现在服务器部署有冗余，我们可以进行逐步的缩容。
如果说现在已经高于致命线，则需要扩容，让这个值更加接近安全线，保证系统的稳定性。
⑤在线容量评估体系

文章插图
现在自动扩缩容的三个要素，当前消耗、水位线、容量决策系统都已经具备了，我们如何把这三个点联动起来？如何让它串在一起完成扩容动作？这些环节都包含在在线容量评估体系内，这个体系可以实现压测的过程。
我们刚才说了压测不是通过流量拷贝进行模拟测试的，我们是针对目标服务，就用线上的流量，记录当前（Ahits）数，开始减少服务器的数量，一直到慢速比达到临界值的时候，记录 Ahits 数作为本服务单元最大的消耗。
得到消耗值后和水位线进行对比，调用决策系统做出是否扩缩容的决定，接下来再对接云服务商，就完成了扩容的动作。
⑥实时演练体系

文章插图
前面进行的数据采集、计算，以及动作的串联，都是为了完成最后一个目标，服务扩容成功。
真正的服务器扩容到线上之后，怎么样才能保证服务是健康可用的呢？我们还有另外一套辅助系统叫扩容演练。在实时演练过程中，要注意以下几点：
部署效率：我们通过扩容演练来寻找整个扩容过程中的瓶颈，比如，我们下发是通过 DCP 对接云服务商来完成扩容的。
在真正的线上扩容过程中， DCP 有时要同时承载几千台节点的扩容并发。DCP 的效率是否能够满足？在扩容演练过程中需要确认这一点。
带宽限制：微博和云服务商之间确实是拉了专线，但是微博和云服务商不只是微博广告的一个业务，还有很多其他大户。
而且一般在流量增加的时候他们的扩容也是非常猛烈的，所以带宽是否可用，也是我们在日常演练过程中非常注意的现象。
依赖服务：这方面有很多案例，在这里简单分享一下， 2015 年春节，自动扩缩容的流程才刚刚开始，春节当天晚上我们扩容完几千个节点后，忽然发现负载均衡加不上去。