我们认为的流量有序的，而真实的流量却是随机的，不确定的。
抖动性
在理论的世界里面，吞吐量是请求量的函数，可以表示为如下的公式：
Throughput=f(load)
如果没有其他因子的干扰，在系统达到饱和之前，吞吐量和请求量的关系应该是线性的。而现实世界里面，这种理论模型几乎是不可能出现的。为什么？因为抖动。为什么会出现抖动？因为网络，磁盘等等的不确定性。
排队系统的特性
我们的业务可以简单的抽象成为一个排队系统，请求从左边随机的进入系统，等待被处理，处理完成之后，从右边离开队列。在系统未达到饱和状态时，系统可以很好的处理用户的请求，而一旦队列接近饱和，那么队列的长度可能会显著的增加，而且请求的平均响应时间也会出现增加，甚至会出现部分请求超时的情况。对于一个理论上能处理 1000q/s的系统，在不同流量的情况下，可能的状态如下（特定系统的测量结果）：
从图中可以看出：
请求达到率增加2倍，队列的长度会增加约60倍。
当系统接近饱和时，请求端极小的变化将会对系统造成很大的影响。请求达到率从0.95 ~ 0.99，队列的长度将增加40%。
排队系统的特征是：系统会在接近饱和时出现拥堵，拥堵会导致服务的时间变长，而这反过来又会加重拥堵的程度。随着情况的恶化，系统的资源（cpu，mem）最终会被耗尽。拥堵和服务质量下降表现为正相关性，这种特性会随着时间急剧的恶化，最终拖垮系统，出现故障。
高德业务特点
出行业务有其特有的特殊性，会受到诸多因素的影响。具体到高德业务而言，系统的行为会受到区域，地形，路况，路网密度，季节，天气，政府活动等等因素的影响。
以驾车导航为例，导航系统会受到如下因素的影响：
区域：不同的区域经济发展水平不一致，人们选择出行的交通工具也会不一样，经济发达地区的人们汽车拥有率会更高，使用汽车出行的频率也会更高。
地形：山区，城市繁华地区会因gps信号遮挡导致定位不准确，可能被系统认为偏航，从而引发路径重新规划。
路况：事故，拥堵，施工，限行，管制 这些路况都对导航服务造成影响。
路网密度：导航算法所要求的计算资源和路网的密度有很强的关联，路网越密，路径规划所消耗的cpu资源，内存资源就会越大，同时计算的时间也会越长。
距离：路径规划的距离越长，导航算法对计算资源的要求就越高。
季节&天气：人们的出行行为和季节也会呈现相关性，如 五一，端午 人们可能集中前往景区旅游。十一，春节 人们可能会集中返乡。这样在导航行为上就会出现导航距离分布不同的情况，不同的导航距离对服务的要求会不一样，越长距离的导航对服务资源的要求越高。
政府活动：交通管制，修路，限行等等。
对于高德而言不能单纯的通过放大流量来对系统进行压测，在流量构造阶段我们需要考虑到流量的特征，考虑到所有影响服务行为的因素。
高德全链路压测平台的自建起因身在阿里，说起全链路压测，首先想到的肯定是大名鼎鼎的Amazon平台，Amazon 诞生于2013年，自2013年起，Amazon一直作为淘宝、天猫稳定性保障体系中神一般的存在。经过多年的发展和演进，Amazon平台已经日臻稳定和成熟，在施压能力，链路治理，数据构造，用户模拟方面已经做到极致。