论文对阿里巴巴集群中部署的大规模微服务进行了全面的研究。他们分析了 7 天内 20,000 多个微服务的行为，并根据收集的 100 亿条调用跟踪来分析它们的特征。该论文获得SOCC 2021最佳论文奖。
他们发现：
- 微服务图在运行时是动态的
- 大多数图形像树一样分散生长
- 调用图的大小遵循重尾分布
根据他们的发现，他们提供了一些有关提高微服务运行时性能的实用技巧。他们还开发了一个随机模型来模拟微服务调用图依赖关系，并表明它近似于他们收集的数据集（可在https://github.com/alibaba/clusterdata获取）。
一个微服务运行在多个容器上。对前端微服务的调用会触发对其他微服务的调用，依此类推。在生成的调用图中，每条边将上游微服务 (UM) 连接到它调用的下游微服务 (DM)。呼叫的响应时间 (RT) 是 UM 呼叫其 DM 到收到响应之间的时间。
阿里巴巴集群使用Kubernetes来管理裸机。在线服务（例如微服务）和离线批处理作业共存于同一个裸机节点中，以提高资源利用率。有状态服务（即数据库和Memcached）部署在专用集群中。
微服务调用图的大小遵循重尾分布。大约 10% 的调用图由 40 多个微服务阶段组成。最大的调用图甚至可以包含数百到数千个微服务。对于包含超过 40 个微服务的调用图，其微服务中大约 50% 是 Memcached（MC）。
发现：
- 调用图变得更深，查询的缓存未命中率迅速增加。当数据在缓存中未命中时，查询将发送到数据库服务。
- 超过10%的微服务对的乘积>=5，这意味着阿里巴巴集群中很多微服务对具有很强的耦合依赖关系。
- 微服务调用率与 CPU 利用率和 Java 年轻代垃圾回收 (Young GC) 高度相关，但与内存利用率无关。这意味着与内存利用率相比，CPU 利用率和 Young GC 是微服务容器资源压力更好的指标。阿里巴巴微服务轨迹中大多数容器的内存利用率在运行时几乎稳定（方差小于 10%）。
- 由于主机 CPU 利用率较高，响应时间 (RT) 可能会大大缩短。当主机CPU利用率超过40%（或80%）时，微服务的RT平均下降20%（或30%）以上。
- 这些结果表明，大多数在线微服务对 CPU 干扰很敏感，强烈需要更高效的资源调度器，能够很好地平衡不同主机之间的 CPU 利用率。
- 跟踪显示，每分钟跨主机的 CPU 利用率差异可能高达 20%，这意味着有机会更好地平衡跨主机的批处理工作负载。