百万台服务器！双十一阿里巴巴电商业务的高效资源运营之道

最新推荐文章于 2022-12-01 08:49:34 发布

cj2238

最新推荐文章于 2022-12-01 08:49:34 发布

阅读量336

点赞数

文章标签： devops 数据库操作系统

讲师 | 杨仪阿里系统软件事业部调度系统技术专家

编辑 | 黄晓轩

本文整理自杨仪在GOPS全球运维大会上的演讲，首发于公众号：高效运维

讲师简介

杨仪
2010年入职阿里从事监控系统运维研发
2012年调入运维团队，负责淘系核心交易系统运维
2016年负责系统软件事业部资源运营团队，负责阿里在线业务的资源运营。
负责过多年双11交易运维保障，在自动化运维、DevOps、资源运营方面有一定的实践经验。

前言

大家好，我是杨仪，今天我给大家带来一些关于资源运营方向的分享。我们今天讨论的主要内容有四部分：

资源运营的演变
规模化运维平台
降低资源成本
智能化运营

资源运营的演变

首先我想分享一下整个阿里在 Devops 的演进历程。

Devops 的概念这几年是很火，阿里的业务运维也是经历了这样一个阶段。

我刚进阿里的时候大部分运维相关操作，运维人员都是通过登机器、敲键盘去做的。逐步我们会有一些工具去操作、执行重复性的工作。

随着业务规模不断增大，团队发现不可能无限数量地招运维人员去做重复的事情，所以引入 Devops。

经过这两三年的发展，阿里在线运维基本上达到了初步自动化的状态，同时我们正在向智能化的方向摸索。

整体看下来我认为阿里在运维领域，容器化是 Devops 转型过程中最重要的里程碑阿里现在在线业务中大规模使用 docker 容器。

接下来我想讲一下阿里这十几年来在线业务的升级。

未来运维的方向是 Opsless。

传统运维能做的事情一定越来越少，最终有可能会做到 NoOps 的状态。

近三年来运维人员规模没有增长，甚至有些是下降的。

整体来看一开始是做面向单对象运维，配置文件、包等这个时代已经过去了。

接下来是面向容器运维，当下演进的状态，运维粒度扩大到image。第三个是面向Pod运维，业界流行，服务相关容器打包到Pod，进一步扩大运维粒度。第四是面向Box运维，阿里规模大，业态丰富，所以后面有可能到达第四个阶段。

运维做久了以后他的上升空间，比方说整天都在做些运维的事情，那未来发展的方向是什么呢？

在阿里运维他是有两个方向要突破：

第一方向是回归到业务，和业务去做深度融合，比如专注去做智能化监控、智能化故障定位等。第二方向是下沉到调度领域，下沉到内核这块。

我现在的团队相当于做的是下沉这块。所谓的资源运营就是指我们想要做超大体量的数据中心的资源管理策划，做这些最终是为了降低整个阿里生态体系的资源运行成本。

想做到这些我们有很多挑战：

建设统一调度的能力。阿里有很多业务，比如说淘宝、天猫、聚划算等等，各种各样的电商业务，我们对这些业务怎么去做资源的分配，这就需要我们有同步的调动器。
资源供需模式，需要的是集中式、扁平化的资源供需。把整个的在线资源调度能力作为中台输出。
提升资源利用率。大家知道在线业务要考虑容灾、异地部署的需求，有的数据中心，集群的利用率都不会很高，但阿里的资源利用率都在10%，整体来看提升空间非常非常大。

前面提到是资源运营本身的挑战，我们从运维团队转型做资源运维，面临更多的挑战是围绕着效率、成本、稳定性去解决双11资源使用问题。

传统运维运营向自动化运营的转型。每到双11大促，所有的业务都来和你说要加机器，以前都是人肉评估，人肉去运营的模式。我希望把这种运营模式转化成系统运营。
资源需求的集中爆发。在双11场景下，资源需求是集中爆发的，我们会有数十个BU，因为“双11”这么大的活动在阿里内部是整体协同的大作战，包括优酷、菜鸟、天猫都会参与到“双11”里面来，那这里面的需求量，很多很多系统都会来问我们要资源。
业务和成本之间寻求平衡。为了支持双11，怎么能够用最低的成本去满足最多的业务需求。
运维平台要有很高的可靠性。

规模化运维平台

基于前面的那些挑战，我们最核心的关键是要打造一个规模化的运维平台。阿里有两万多个工程师，每个工程师负责一个系统的话就有两万多个系统。

我们通过规模化运维平台来提升资源运营的效率。

资源调度系统。提到了Sigma调度器，一站式资源交付。他可以很简单的点几下按纽，就可以把需要的资源交付给他。
资源管理的过程中引入了预算和额度管理机制。年初的时候希望每个团队都向资源运维团队提供未来一年资源需求的规划。我们基于这个规划会统一的看阿里巴巴集团未来资源的需求，然后会制定相应的资源交付计划。
弹性伸缩。解决海量应用的容量备容效率问题。
解决规模化执行问题。
比如说双11的时候要扩容几十万个容器上去，这对我们规模化执行的效率要求就很高。还有点现在都用的是容器，容器就会涉及到容器级别的偏袒，一台物理机要怎么样部署，要有哪些组合才能让这台物理机上的资源运用好。

这是规模化运维平台整体的架构。规模化运维的目标是做批量大规模的，不会去对单个应用做传统的运维支撑，所以规模化运维是用很少的运维人员投入解决万级别的系统交付。

首先在资源运营这块有预算额度和整个的管理系统，比方说业务他要提交他的预算，整个系统会根据他的预算决定在哪个时间点交付多少资源。

第二是容量规划，根据业务平时的表现可能会去推算未来阿里巴巴在明年的业务增长。

第三是弹性伸缩，我们会对所有的线上系统做实时的分析，在平时的时候通过弹性来做自动的容量管理。其实还有一系列的架构在里面，比方说决策中心。

整个规模化的操作都会在决策中心做数据处理，比方说执行大规模的销毁容器的动作，那可能就会由决策中心预判。上面是资源运营的体系，最下面是调度器。基于上面这套对最底层的容器去做一整套的管理。

这是额度生态。在阿里巴巴内部所有的系统使用资源都会有上限，就是在某一个时期你能用的最大资源数量。这个数量我们是把他细化，你能用多少核的CPU，能用多大的磁盘空间，基于这套额度系统会整个形成系统化的闭环。

降低资源成本

其实我们做的这些系统归根到底是为了解决资源成本的压力。阿里在2014年做下一年的财政预算的时候就预见到阿里巴巴未来在基础设施的投入是非常非常难，第一年做预算的时候发现下一年要采购的机器数翻倍，这对于整个的投入是非常非常难。

这块主要挑战来自两块，一是像“双11”的场景，很多人买买买，我们要提供几十万的峰值交易能力。

还有一块是离线任务计算，也是有非常大的资源需求。像刚才提到“双11”是很麻烦的事情，在“双11”之前可能买了很多机器，“双11”用完之后大量机器就闲置，那闲置成本对于阿里来说也非常非常高昂。

基于这些我们就想说怎么样才能用最少的成本去支撑“双11”。首先想到用阿里云，比方说去年30万笔交易，我们有很大一部分都用的阿里云的资源，因为阿里云有这么大的体量。

这里面的技术难点主要是阿里集团要和阿里云体系打通，怎么样才能快速的把电商业务部署到云上去，基本上只用十几二十天撑过“双11”就可以，这样成本会大幅度下降。

第二我们想到怎么把手头机器用好。在线服务，他的CPU利用率是跑的比较低的，刚才说到只有10%，但离线计算CPU用的比较高，就想这两种服务能不能够同时去跑。比方说把离线、实时计算、在线同时跑就可以达到很高的CPU使用率。

阿里大概从2015年开始就做这块的尝试，把不同的业务做混合部署。在阿里我们基本上是这么做的，在线业务都是物理机，那离线直接在物理机上，像在日常情况下可以用在线的服务器去满足离线资源。这个技术给阿里带来了极大的成本节省，现在CPU利用率已经能够跑到很高的水位了，包括平时在线集群上只有离线任务在跑，并且离线任务对在线的影响可以控制在10%以内。