2135 亿!11 月 12 日零点，2018 天猫“双11”全球狂欢节的成交额在数据大屏定格，较去年的记录增长近 27%，物流订单超 10 亿!天猫双 11 再次成为阿里巴巴创造纪录并突破纪录的商业奇迹。

此刻，比双 11 的数字更该被记录的，是阿里巴巴在双 11 背后做了哪些技术上的突破?

混部技术在业界还尚属于较少研究的领域，该技术只有在资源及成本的体量达到一定规模时，才会显现出其可观的技术红利。

今天，阿里系统软件部技术专家蒋玲从阿里巴巴混部探索简介、混部方案及架构以及混部核心技术等几个方面带大家全面了解混部技术，希望对你有所启发。

阿里巴巴混部探索简介

混部技术的出发点，源自于对不断增长的业务和日益攀升的资源成本如何平衡的思考，我们希望用最小的资源成本，支撑更大的业务需求。

是否能够复用已有的存量资源，来满足新增的业务，这就是混部技术发展的思想源头。

为什么做混部?

上图是阿里巴巴从 2009 年开始做双十一购物狂欢节以来的历年交易额曲线，对业务同学而言，这张曲线增长图比较漂亮，但是对于技术人员和运维人员而言，这张图背后意味着重大的挑战和资源压力。

对于做电商平台型业务的业界同行，大家应该知道我们在做促销活动时，技术压力往往来自于开卖的第一秒，是一个脉冲式的洪峰流量。

阿里巴巴在线业务的双十一零点峰值流量(通常用秒级交易创建量来描述)跟这张图的曲线走势基本吻合。

从 2012 年往后的年份开始，0 点峰值压力基本是上一年的两倍。可以看到在线侧业务发展如此快，主要跟我们促销活动密不可分。

除了在线型业务，阿里巴巴还拥有较大规模的离线计算型业务。随着 AI 技术的兴起，计算型业务也呈不断上升趋势。截止当前，我司大数据存储量达到 KPB 级、日均任务量在百万级。

业务不断增长，在基础设施层储备了大量的资源以满足在线型和离线业务的需求。

由于在线型业务和离线型业务有很多不一致的资源使用特性，最初设计时由两个独立的数据中心来支撑，当前，两个数据中心均已达到万台服务器以上的规模。

然而我们发现，数据中心的资源体量虽然庞大，但有些资源的利用率却并不乐观，尤其是在线业务数据中心，日均资源利用率仅在 10% 左右。

基于以上背景，同时考虑到不同业务对资源使用和要求的差异性：

• 一方面，不同业务具备不同时段峰值的特性(分时复用资源)。
• 另一方面，对资源被响应的容忍度不一(资源按优先级竞争和抢占)，促使我们探索不同业务混合部署的技术方向。

何为混部 ( Co-location )?

简而言之，混部技术就是：将不同类型的业务进行混合部署，用一份资源同时提供两份不同业务的资源当量的技术。

混部技术首先，是资源整合，把原本物理分离的业务部署于统一的物理资源上。

其次，进行资源共享，同一份资源，既支撑 A 业务，又支撑 B 业务，在 A 和 B 业务的视角，同时看到各一份的资源。

最后，是资源合理竞争，既然由原来的一份资源，一生为二，变成 2 份，必然存在资源的竞争，需要提供合理竞争的手段，使得不同资源需求的业务符合各自的服务要求。

混部最大的价值在于通过资源共享的方式充分复用资源，实现无中生有。而混部技术的核心目标在于出现资源竞争时，优先保证高等级的业务。

因此，我们希望通过调度管控和内核隔离的手段进行资源充分共享和竞争隔离。

在线离线混部

在线型业务，在混部技术里主要描述的场景是交易型业务、支付型业务、浏览型请求。

在线型业务的特性是实时性，对实时性的要求非常高，以及不可降级。如果用户在选购宝贝的过程中，出现长时间等待(比如秒级别)，很有可能该用户就会放弃购买;如果需要用户重试，估计就很难留存该用户了。

在线型业务，尤其像我们做电商的，业务量趋势非常明显。伴随用户作息时间，白天高、晚上低，白天买买买。

电商型平台另一个比较大的特性是，日常的流量相对于大促而言非常低，大促当天的秒级创建量可能是平常峰值量的十倍甚至百倍以上，它具有很强的时间场景性。

离线型业务，比如：计算业务、算法运算、统计报告、数据处理等业务，业务类型相比于在线而言，可以称之为时延不敏感。

用户提交的作业和业务，本身的处理时长就在秒级、分钟级以上，甚至有小时级、天级，因此它们可以运行一段时间后才完成。

同时它们可以接受重试，技术上我们应该更关心的是谁帮它重试。用户重试不可接受，但若有系统帮忙重试，用户是无感的。

此外，离线业务的时间场景性没有在线那么强，随时都可以跑，甚至表现出反在线业务时间特性，其有一定概率的白天比较低，凌晨比较高。

究其原因，也表现出和用户行为有关，例如：用户在提交一份统计型，等待凌晨 0 点后开始运行，第二天早上上班前收取报告。

从不同业务的运行时特性分析，我们可以发现，在线型业务和离线型业务，具备业务压力错峰和资源错峰的条件。

另一方面，在线业务明显具备更高的优先级和资源抢占能力，与此同时，离线业务表现出一定的资源不足时的容忍度。这些因素，成为在线、离线业务混部技术的可行性要素。

阿里巴巴在做混部探索的历程

在展开技术介绍前，简述下阿里巴巴混部技术探索的历程：

• 2014 年提出混部技术。
• 2015 年做线下测试和原形模拟。
• 2016 年大概上 200 台机器到生产环境，公司内用户作为第一批吃螃蟹的人，运行了一年的时间;在内部用户适用，线上落地后有效。
• 2017 年生产环境小规模混部，达到数千台物理机级别，直接面向外部用户，并且支撑了 2017 年的双十一大促。
• 2018 年，我们希望是规模化铺开的一年，我们希望混部能在规模化效应下带来客观的技术红利，打造万台体量的混部集群。

阿里巴巴规模化混部成果

阿里巴巴规模化混部成果如下：

• 混部规模达数千台，经历双 11 交易核心场景验证;在线集群上引入离线计算任务(在离线)：日常 CPU 利用率从 10% 提升到 40%。
• 离线集群上部署在线业务(离在线)，支撑双 11 大促数 W 笔/s 交易创建能力。
• 混部环境下对在线业务服务干扰影响小于 5%。

当前初做混部，存在两种场景：

• 由在线集群提供资源做混部，用在线的资源提供额外的离线计算力，供离线业务运行。
• 由离线集群提供资源做混部，用离线的资源创造在线业务交易能力(主要应对大促等在线流量洪峰)。

在我们内部有个简单的约定，在线和离线，谁提供机器，谁就排在前面，因此有在离线混部和离在线混部的叫法。

2017 年双 11，我司官方发布的秒级创建量是 37.5 万笔每秒，离在线混部集群做到万笔每秒的交易体量，使用离线的资源支撑在线高峰，节约了一定量的大促资源开销。

同时，在离线混部集群上线后，将在线原生集群的日均资源利用率从 10% 提升到了 40%，给离线提供了额外的日常计算力。

如下图所示：

这是真实监控系统的数据：

• 右图这个代表非混部场景，时间点大概是 7 点到 11 点左右，在线中心利用率是 10%。
• 左图这个代表混部场景的数据，平均利用率在 40% 左右，抖动性比较大，因为离线业务本身具有比较大的波动性。

节约了这么多资源，业务(尤其在线业务)的服务质量是不是变得很差呢?

以下是负责交易处理的在线核心服务的 RT 曲线图，其中绿色曲线代表混部集群中的 RT 表现，黄色曲线为非混部集群的 RT 表现。

可以看出，两条曲线基本重合，混部场景中的平均 RT 较普通集群差 5% 以内，符合服务质量要求：

混部方案及架构

由于混部技术跟公司的业务体系、运维体系存在一定的关联性，因此文中可能会提及不同的技术背景，由于篇幅关系只做了简单引述，未做详细介绍。

下面将简单介绍混部方案，包括：整体架构、混部场景业务部署策略、混部集群资源管理及分配机制、混部场景下的业务运行策略等。

混部整体架构

混部技术抽象来说，分为三个层面：

• 合并资源，整合资源池。既可以给 A 业务用，也可以给 B 业务用。
• 我们要做到很好的资源调度与分配。在做混部技术之前，阿里巴巴集团已有多个资源调度平台，其中在线侧资源调度系统称之为 Sigma，离线侧资源调度系统称为 Fuxi。
• 混部技术的挑战在于做好资源不同业务资源分配，统一多个资源调度系统，并进行决策仲裁。

运行时做好资源竞争时的隔离与优先抢占。

上图的架构表现为一定的层次性：最底层，是基础设施层，整个集团的数据中心是统一的，不管上层怎么用，机器、网络、等等的硬件设施及配套都是同一套。

往上一层，是资源层，我们要做混部，必须打通池子，把资源放在一起管控。

再往上一层，是调度层，分为服务端和客户端。在线是 Sigma，离线是 Fuxi，我们把各业务自己的资源调度平台称为一层调度器。

在混部架构中，引入“0 层”调度器，主要负责协调两个一层调度器的资源管控和资源分配决策，它也有自己的 Agent。

最上面一层，是面向业务的资源调度与管控层，有些经一层调度器直接交付资源给业务，有些还会涉及二层，例如：Hippo 等。

而在混部架构中还有一个特殊混部管控层，其主要负责混部模式下业务运行的机制的编排与执行，以及对物理资源的配置管控、业务监控和决策判断。

以上是资源分配的体系架构，由此可以将机器和资源分配给不同的业务，然而在分配完后，运行时的业优先级和 SLA 如何保障?在线业务和离线业务同时跑在一个物理机上，如果业务间发生资源争抢怎么办?

我们通过内核隔离来做到运行时资源保障，我们开发了很多内核特性，支持不同类型资源隔离、切换和降级。内核相关机制将在第三章中介绍。

混部场景在线业务部署策略

本小节将介绍如何将混部技术运用于在线业务场景，为电商平台提供交易创建能力。

首先，混部技术由于其新颖性及包含较多的技术改造点，为了规避风险，我们希望能够在有限的、可控的范围内进行小规模试验。

因此我们基于我司电商(在线)单元化部署架构进行了业务部署策略，将混部集群构建出独立的交易单元，一方面确保混部技术在局部范围内收敛不影响全局，另一方面可以到单元的业务闭环和独立的资源调配管控。

在电商在线型体系中，我们把买家购买行为相关的全链条服务，闭环到一个服务集合中，将这个服务集合定义为交易单元。

交易单元可以做到：买家交易行为相关的所有请求与指令，都在这个单元内闭环完成，这就是异地多活-单元化部署架构。

混部技术实施中的另外一项约束，来自于硬件资源限制。由于离线在线业务对硬件资源的诉求不一，而各自的存量资源都不一定适配另一方的业务，在实施中我们遇到了存量资源的适配问题，最为强烈的体现在磁盘。

离线业务的原生资源中，有大批低成本的 HDD 盘资源，并且离线在运行中几乎会将 HDD 盘用满。这样对在线业务来说基本就不可用了。

为了屏蔽磁盘 IOPS 性能问题，我们引入了计算存储分离技术。计算存储分离技术是我们集团内在演进的另一项技术。

它提供中心式的计算与存储服务，计算节点通过网络连接存储中心，可以屏蔽计算节点对本地磁盘的依赖。

存储集群可以提供不同的存储能力。在线业务对存储性能要求高，吞吐量却不大，因此我们通过计算存储分离技术，获得了有 IOPS 保障的远程存储服务。

混部集群资源分配

说完整体架构，我们再从资源的角度来看看混部集群的资源分配，是如何做到无中生有的。

首先是单机角度的资源，主要是 CPU、MEM、Disk、Net，下文将陈述如何实现额外资源的获得。

先来看看 CPU，纯在线集群的日常资源利用差不多在 10% 左右，可以说在线业务无法在日常状况下将 CPU 充分地利用起来，而当大促等促销场景时，在线将会在瞬间达到一个 CPU 使用高峰。

离线任务则更像是吸水的海绵，其业务体量巨大，对于 CPU 计算能力，有多少就能用多少。有了以上业务对资源使用的背景，促成了混部技术中让 CPU 一生为二。

CPU 资源在内核运行机制中，以时间片轮询分配给不同的进程，我们将 1 个 CPU 核，同时分配给在线业务和离线任务，并确保在线有高的优先级。

当在线闲时，离线可以使用该 CPU，而当在线需要使用时，将离线任务抢占并挂起。

上文有提到两个资源调度器(在线调度器 Sigma 和离线调度器 Fuxi)，在线业务以 Pouch 容器做为资源单元，Pouch 容器会绑定一定的 CPU 核，供某个在线业务使用。Sigma 会认为整台物理机都属于在线。

同时候，离线 Fuxi 调度器认为这台机器属于离线，它会把整体机器的 CPU 资源作为可分配资源分配给离线任务。通过这种方式，就做到 Double CPU 资源的效果。

将同一份 CPU 分配给两个业务运行，一定会存在竞争的风险，这就依赖核心内核技术来进行 CPU 隔离和调度，这些会在下文中提到。

CPU 可以被多进程分享时间片，但 MEM 和 Disk 资源就比较棘手，其作为消耗型资源，分给一方使用，就不能被另外的进程使用了，否则就会被新进程给覆盖。如何进行内存层面的复用就成为另一个研究重点。

如图(右上)所示，介绍了混部技术中内存超卖使用的机制，图上侧的括弧表示在线内存分配额(蓝色)和离线内存分配额(红色)，而图下侧的括弧表示在线内存使用额(蓝色)和离线内存使用额(红色)。

图中可见，离线在使用内存时，多用了分配给在线的内存额度，通过这种机制，实现内存超卖使用。

为何在线内存允许被超卖使用，由于我们公司在线业务以 Java 语言为主，分配到容器的内存一方面用于 Java 堆内存开销，剩余的内存作为 Cache 使用。

这就造成在线容器内存在一定量的空闲内存，我们通过精细地内存使用量监听，并结合一定的防护机制，把在线容器分配的空闲内存分配给离线使用。

但由于这部分内存属于在线，对离线而言无法强保障，因此离线会把相对低等级可降级的业务调度到这些资源上。

Disk 方面，磁盘容量对于双方业务还是比较充分的，故未做过多约束。而磁盘 IO 方面，做了一系列带宽限速，以约束离线任务使用的最大 IO 小于一定数量，避免完全挤占在线及系统的 IO。

另外，单机 Net 层面，由于当前容量较为富余，当前不是瓶颈点，不做过多介绍。

大促资源退让机制：站点快上快下

以上谈了单机层面的资源如何做到共享与竞争隔离，再让我们一起看看从整个资源集群层面，如果通过整体的运维管控，实现资源的迁移和最大化利用。

混部技术中，我们追求资源利用的极致，让不该用的业务场景不要浪费每一份资源。

于是我们提出了站点快上快下的概念，其面向在线业务而言，如前文所述，每个混部集群即为一个在线交易单元，其独立支撑一小部分用户的交易行为。

因此我们也将其称为“站点”，我们把在线站点的整体容量做伸缩变换，就是快上快下的过程。

如下图所示：

在线型业务在日常运行和特殊促销活动时的业务压力表现出巨大的偏差，双 11 期间有可能是日常流量的百倍以上，这个特性奠定了快上快下方案的可行性基础。

如上图所示，把两个大的方块图，比作是在线站点整个容量，每一个小方块代表某个在线服务的容器数量，每一行代表一个在线服务的容量储备(容器总数)。

我们通过对整个站点的容量规划，实现日常状态和大促状态的容量模型切换，从而使得精细化地使用资源。

我们电商业务通常以一个业务目标，比如秒级交易创建笔数，作为站点容量评估的基准。

通常而言，在日常态，单个站点保留 K 笔/s 的容量已经足够，而等到大促临近，我们会将站点切换至大促态，通常是 W 笔/s 容量级别。

通过以上模式，从整个站点的维度，把不必要的在线容量进行整体缩容，以达到充分释放资源，如此就可以让离线业务拿到更多的物理资源，这就是快上快下机制。

站点快上过程(从低容量到高容量)，执行效率在一小时内。站点快下过程(从高容量到低容量)，执行效率在半小时内。

在日常状态下，混部站点以最小容量模型支持日常在线流量，而当大型促销或全链路压测前夕，将把混部站点迅速拉起到比较高的容量状态，并持续运行几个小时后，进行站点快下。

通过这个机制，我们确保绝大部分地时间，在线仅占用极少的资源，而 90% 以上的资源均被离线充分使用。

下图展示了快上快下各阶段的资源分配细节：

上图资源分布的情况，左、中、右三个矩形框分别代表：日常态、压测态、大促态混部集群的资源分配状况。

其中，红色代表离线，绿色代表在线。而每个矩形框中，又分为上、中、下三层，上层表示业务运行及量级;中层代表资源(宿主机)分布，其中蓝色小方块代表混部资源;下层代表集群层面资源的分配比例及运行模式。

在日常态(左矩形框)，离线占用绝大部分资源，一部分通过分配获得，小部分通过运行时争抢获得(在线不使用即会被离线使用)。

而等到压测态(中)和大促态(右)，离线会进行资源退让，基本达到离线、在线各 50% 的分配比例，在线高压力时，离线不进行超卖争抢，而在准备期内(大促态但非高压力时间)，离线仍然可以争抢在线空闲资源。

在双 11 大促当天，我们为了更确定地保障在线业务稳定，离线会做一定程度的业务降级。

日常资源退让机制：分时复用

上文呈述的快上快下机制是在线站点容量在大促态和日常态的切换过程，除此之外，在线业务在白天和凌晨也表现出一种规律性极强地流量高峰和低谷现象。

为了更进一步提升资源利用率，我们还提出了日常情况下的资源退让机制：分时复用。

上图是在线业务日常表现出的一天的流量周期曲线，凌晨会比较低，白天比较高，我们针对每一个在线服务，做到以天为周期的容量精细化伸缩，以最小化在线业务的资源使用，从而出让资源给离线使用。

混部核心技术

混部核心技术主要分为两方面：

• 内核隔离技术
• 资源调度技术

由于涉及内容均涉及专业领域，考虑到当前文章篇幅，下文仅罗列了一系列技术点，并不做细节展开。

内核隔离技术简介

我们在内核各资源类型层面均做了较强地隔离特性开发，包括：CPU 维度、IO 维度、内存维度、网络维度。

整体上基于 CGroup 进行在线、离线业务组别划分，以区分两类业务的内核优先级。

在 CPU 维度，我们实现了超线程对、调度器、三级缓存等的隔离特性。在内存维度，实现了内存带宽隔离和 OOM kill 优先级。

磁盘维度实现了 IO 带宽限速。网络维度，单机层面流量控制，还做了网络全链条层的分等级 QoS 保障。

混部内核隔离技术的详细介绍大家可以自行搜索获取，下文仅展开有关内存超卖机制的介绍。

Memory 动态超卖机制：

如上图中实线括弧所示，红色、蓝色分别代表离线、在线 CGroup 的内存分配额，其和值代表整机可分配的内存(已去除系统开销内存)。

其下还有一个紫色实线括弧，代表离线的超卖内存配额，其大小值因运行时变化，是通过监听运行时发现在线未使用的空闲内存大小来决定的。

如图中上侧虚线括弧，代表离线、在线实际使用内存，其中，在线业务通常而言不会将内存用满，其剩余的内存，离线作为其超卖配额进行使用。

为了防止在线突发性内存需求，在机制中预留了一定的内存作为 buffer。通过以上机制，实现了离线超卖使用内存。

资源调度技术

混部技术的第二大核心技术为资源调度技术，混部场景中的资源调度，又可分为原生的一层资源调度(在线资源调度技术 Sigma 和离线资源调度技术Fuxi)和混部 0 层调度。

在线资源调度：Sigma

在线资源调度器主要基于应用资源画像，进行合理地资源调度与分配，包括一系列装箱问题、亲和/互斥规则、全局最优解等，并从全局维度进行应用容量自动伸缩、分时复用以及战斗维度快上快下。

上图是在线一级调度 Sigma 的架构图，其兼容 Kubernetes API，基于阿里 Pouch 容器技术进行调度，并且进过多年阿里大规模流量及双 11 大促验证。

离线资源调度：Fuxi

离线集群调度器主要实现分等级任务调度、动态内存超卖、无损/有损离线降级方案等。

这是离线资源调度 Fuxi 的运行机制图，其基于 Job 进行调度，面向海量数据处理和大规模计算类型的复杂应用，提供了一个数据驱动的多级流水线并行计算框架。

其在表述能力上兼容 MapReduce，Map-Reduce-Merge，Cascading，FlumeJava 等多种编程模式，高可扩展性，支持十万以上级的并行任务调度，并能根据数据分布优化网络开销。

统一资源调度：0 层

混部场景中，离线和在线业务通过各自的一层资源调度器进行资源调度和分配，但在一层调度器下面，还有一个统一资源调度层—0 层，其职能为双方资源的协调与仲裁，通过监听与决策，合理分配资源。

以下为混部资源调度的整体架构图：

未来展望

混部技术的未来发展，将往三个方向演进，分别是：规模化、多元化和精细化方向。

规模化：在 2018 年，将会做到万台级别的混部，这将是一次量级的飞跃，我们希望把混部作为集团内部资源交付的基础能力，更大规模地节约资源成本。

多元化：未来希望能支持更多的业务类型、更多的硬件资源类型，以及更复杂的环境，甚至希望可以打通云上资源，阿里云和公司内部资源混部互通。

精细化：未来希望能将业务的资源画像刻画得更加细致，调度层面时效更实时、调度精度更细致，内核隔离更加精细，监控及运维管控更加实时精准。