论文对阿里巴巴集群中部署的大规模微服务进行了全面的研究。他们分析了 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%,这意味着有机会更好地平衡跨主机的批处理工作负载。