1. 背景

以滴滴内部某业务为例，从BI监控、流量晚的流量高峰、夜间的流量低谷。但把周期拉长，可以看到业务单量及服务流量的增加趋势。

对应该服务的资源使用，比如CPU Idle，长期看则有一定的下降趋势。

基于此，我们能否从中找到规律，回答几个重要的问题：

随着业务单量增长，该服务的流量也会增加，峰值会是多少？
随着该服务的流量增加，该服务消耗更多的资源，容量上限是多少？
以及终极问题：随着业务单量增长，该服务是否需要扩容，扩容多少？

2. 容量预估的思路

懵懂中有这样的猜想，服务的流量应该取决于业务单量。所以换个角度考虑，把上面三幅图的横坐标改为业务单量，纵坐标改为服务流量。如果关系成立，预测流量增长自然不难。

不出意外，资源使用率（如CPU Idle）应该取决于服务流量。如果关系成立，评估容量上限也会迎刃而解。

想法是否成立，我们快速验证一下，采集了5个线上服务，生成服务流量与业务单量的关系图，结果显示，有3个服务存在较强的关系：

接下来是资源使用率与服务流量，采集了多个资源使用率指标，比如内存、CPU Idle、磁盘IO等，结果显示，应用类服务的CPU Idle与流量存在较强的关系：

3. 容量预估的方案

评估容量上限

流量高峰时，如果某个服务的主要资源指标下降到一定程度，我们会觉得其容量到了上限。前面分析验证过，应用类的服务大多数是CPU类型，CPU使用率或者CPU Idle是主要的资源指标。有一定的理由相信，如果CPU Idle下降到基线标准，我们可以说该服务的容量达到了上限。

但基线标准如何定义？在达到特定的容量时，该服务的错误率有明显提升、或者时延SLA不达标、或者突然Crash，这就是一个经过验证、令人信服的基线值。

在没有验证的基线之前，我们可以依赖历史经验，比如这里取CPU Idle 40%作为基线值。

从图中可以看出，服务的CPU Idle与流量有较强的相关性，给出性能基线后，很容易评估其容量上限。

预测服务流量

很多时候业务上对增长有较明确的预期，比如半年之内单量增加50%，即使一些促销的运营类活动，也应该对业务增长有粗略的估算，这样底层的IT系统可以更好应对。

这些业务增长的预期，会直接转化为内部各服务的流量，前面已经分析和验证过二者的关系，因此服务的流量也是可以预测的。

下面的左图非常典型，流量与单量强相关。右图则不然，呈现出两个不同的阶段。其实这种情况不难理解，某些服务的流量不只受单量影响，还受制于司机数量，即使单量增加，但司机不够，很多订单分不出去，相关服务的流量必然不会一直增长。所以需要综合考虑服务流量与业务单量、司机在线数等多个因素的关系。

算法说明

持续采集线上数据，经过预处理、格式转换，可以用来做预测。多次训练和验证对比，并使用节假日时的高峰流量二次验证，为不同的服务选择不同的算法。

最后，由于关系图上的点有一定的离散度，引入bootstrap 95%置信区间算法，给出的预测结果是一个范围，而非具体的一个数值。

4. 预测结果的准确度

不难理解，大家会有很多疑问：

预测准不准，怎么证明？
按CPU Idle 40%进行计算，会不会出现CPU Idle 60%或者50%时服务突然Crash？

当某个服务的流量继续增加，CPU Idle持续降低，我们与哨兵压测合作，让该服务单台机器的流量增加，并采集资源类数据，如下图所示。肉眼看起来，基本符合预测的关系，并进行了量化计算，预测的准确度大概是89%。

至于是否会Crash，起码从哨兵压测CPU Idle降到40%的情况下，这两个模块未发生突然Crash。这当然避免不了流量继续增加是否会Crash，但我们在选择性能基线的时候可以更保守一些。容量的预估只需要采集相关的业务指标、流量数据、资源数据，几乎不需要服务侧做任何改动，仅此接入的成本较低。

5. 案例分析

容量的预估只需要采集相关的业务指标、流量数据、资源数据，几乎不需要服务侧做任何改动，仅此接入的成本较低。

案例一

以某服务为例，集群共有10台机器，当前的峰值流量1000QPS（非线上实际数值，仅为示例用途，下同），两个主要的关系图如下：

经过计算，该服务的结果如下：

若不扩容，该服务的容量上限预测结果为：【1500-1700】
单量增加30%、司机增加10%时，该服务的流量峰值是：【2000-2200】
按悲观估算，容量取下限1500，峰值流量取上限2200，则该服务需要扩容4~5台

案例二

以另一个服务为例，集群共5个容器，当前的峰值流量是250QPS。

经过计算，该服务的结果如下：

若不扩容，该服务的容量上限预测结果为：【1100-1200】
单量增加30%、司机增加10%时，该服务的流量峰值是：【450-500】
按悲观估算，容量取下限1100，峰值流量取上限500，则该服务需要缩容2台

案例三

从业务角度，可以看到各核心服务的容量上限、流量增长趋势，以及建议的扩容结果：

6. 局限性说明

线上业务面临各种各样的稳定性挑战，这种常规场景下的容量预估方法，当然也有其局限性：

性能基线如何选择

使用CPU Idle作为基线指标，源于本文对少量数据集的验证结果，大部分应用类服务是CPU资源型。

使用CPU Idle 40%作为基线值，则是源于经验。在40%之前服务是否存在性能拐点，是否会发生crash，则需要结合全链路压测、哨兵压测等其他机制验证。

对下游时延增加等性能抖动的容错

一旦下游服务或基础组件发生性能抖动，比如时延增加、错误率增加，对很多服务会产生致命的影响，甚至引发雪崩。

服务可以容错多大的性能抖动，可以结合防火等手段进一步验证。因此本文的容量预估结果，更多是对服务容量的一个参考。

作者介绍：

张晓庆

滴滴 | 高级算法专家

本文转载自公众号滴滴技术（ID：didi_tech）。

原文链接：

https://mp.weixin.qq.com/s?__biz=MzI1NDA3NzY4NA==&mid=2247485991&idx=2&sn=b05f02468e54fd0661cbf86299f77084&chksm=e9cbf5bcdebc7caa9b69dbbbeb6de6ba163a3553c7c5a4b23b96e5e6dd02b38c3a6f7f95abee&scene=27#wechat_redirect

创作场景

滴滴内部线上系统的容量评估方法