每年双十一创造奇迹的背后，是巨大的成本投入。为了完成对流量峰值的支撑，我们需要大量的计算资源，而在平时，这些资源往往又是空闲的。另一方面，为了在极端情况下，如机房整体断电等还能保障阿里巴巴的业务不受损失，也需要在全国各地建立冗余资源。而且就算是一天当中，在线服务的负载也是不一样的，白天一般情况下要比凌晨高得多。根据盖特纳和麦肯锡前几年的调研数据，全球的服务器的CPU 利用率只有 6% 到 12%。即使通过虚拟化技术优化，利用率还是只有 7% -17%，而阿里巴巴的在线服务整体日均利用率也在 10% 左右。
另一方面，全球从 IT时代全面走向了 DT时代，现在又在向更深入的 AI 时代迈进。各各样的大数据处理框架不断涌现，从 Hadoop 到 Spark，从 JStorm 到 Flink，甚至包括深度学习框架 Tensorflow 的出现，成千上万的数据分析背后是大量的计算任务，占用了大量的计算资源。由于计算任务占用的计算量很高，CPU 水位通常在50%-60% 以上，不同于在线服务，计算任务的峰值通常出现在凌晨，水位甚至能达到 70% 以上。所以我们往往就会建立独立的计算任务集群。
很多人都被车堵过，而堵车的时候，并不是所有的车道都在堵车。有一个比较有趣的情况，我们称之为潮汐现象，而它造成的问题是在早高峰的时候是进城方向堵车，而晚高峰是出城方向堵。而为了缓解这个问题，我们使用了潮汐车道的方式。
那么同样的原理，是否如果能让这两个集群混合起来部署，让计算任务的一部分任务跑到在线服务的资源之上，把在线服务空闲的资源利用起来呢?答案是肯定的。
混部技术简介
混部技术示意图
把集群混合起来，将不同类型的任务调度到相同的物理资源上，通过调度，资源隔离等控制手段 , 在保障 SLO 的基础上，充分使用资源能力，极大降低成本，我们称这样的技术为混部(Co-loaction)。
打个比方，跑在容器里的在线服务就像石块;而计算任务我们把它比喻成沙子和水。当在线压力小的时候，计算任务就占住那些空隙，把空闲的资源都使用起来，而当在线忙的时候，计算任务就立即退出那些空隙，把资源还给在线业务。这样的技术一方面在平时，我们可以极大地提升资源的利用率;另一方面，在大促活动需要突增在线服务器的时候，又可以通过在线业务占用计算任务资源的方式，来顶住那短暂的峰值压力。
从原理中我们可以看到可以混部在一起的任务有两个比较重要的特征：
1.可以划分优先级：一定需要优先级比较低的任务，它们能像水和沙子一样，随时能被赶走，而不会受到不可承受的影响，让优先级高的任务不受干扰。在线的特点是：峰值压力时间不长，对延时比较敏感，业务的压力抖动比较厉害，典型的如早上 10 点的聚划算活动，就会在非常短的时间内，造成交易集群的压力瞬间上升 10 几倍，对于稳定的要求非常高，在混部的时候，必须要保证在线的通畅，需要有极强的抗干扰能力。而计算任务的特点是：平时的压力比较高，相对来说计算量可控，并且延迟不敏感，失败后也可以重跑。至少需要几分钟跑完的计算任务，相对于几秒甚至几十秒的延迟，并不会产生严重的问题，正好可以承提起水和沙子的角色。
2.资源占用互补性：两种任务在不同的时间点对水位的占用不一样。如在线服务是，平时比较低，大促时比较高;凌晨比较低，白天比较高。而计算任务则反过来，平时比较高，大促时可以降级;凌晨非常高，白天却要低一些。
这种方式带来的成本节省是非常巨大的：假设数据中心有 N 台服务器，利用率从R1 提高到 R2，不考虑其他实际制约因素的情况下，节约 X 台，那么理想的公式是：
N*R1 = (N-X)*R2
=> X*R2 = N*R2 – N*R1
=> X = N*(R2-R1)/R2
也就是说如果企业有 10 万台服务器，利用率从 28% 提升到 40%，代入上述公式，就能节省出 3 万台机器。假设一台机器的成本为 2 万元，那么节约成本就有6 个亿。
2015 年，Google 发表了 Borg 论文，其中就提到了在线服务与计算任务之间的混合运行，也就是我们说的混部技术。Borg 论文中描述了 Google 由于采用了这项技术，为 Google 节省了 20%-30% 的机器规模。
混部技术的历程
阿里巴巴早期混合云架构
大家都知道这今年阿里巴巴双十一的交易峰值是每秒 32.5 万比，相比去年几乎增加了 1 倍，但是这样的高峰却只有 1 小时左右。为了让交易的成本降低，从 2014年开始，我们一方面通过阿里云的公有弹性云资源降低成本，另一方面也开始研究混部相关的技术。
混部能产生这么大的帮助，可是业界能使用在生产的没有几家公司，其原因也非常简单，第一个是规模，第二个是技术门槛。当你机器规模不够大的时候，显然意义不大。而在技术上，计算型任务通常都可以把利用率跑到很高，如果计算型任务和在线型业务运行在同一台机器上，怎么避免计算型任务的运行不会对在线型业务的响应时间等关键指标不产生太大的影响呢，这个需要在技术上有全方位的突破，而阿里巴巴从无到有，花了 4 年多的时间才让这项技术在电商域得以大规模落地。
2014 年，我们最主要的工作是进行技术论证，方案设计，以及相关的一些实验性研究
2015 年，我们开始了日常测试环境的测试工作。这一期间让我们总结了相当多的问题：如调度融合问题、资源争抢隔离问题、存储依赖问题、内存不足问题等等
2016 年，当我们把大部分问题都解决掉时，我们开启了线上 200 台左右的小规模验证。由于电商的金融属性，对于抗干扰要求特别高，在不断的业务考验下，我们不停地修正着技术方案
2017 年，经过一年的磨合，混部的整体技术终于走向了成熟和大规模生产。阿巴巴双十一当中，约有 1/5 的流量是跑在混部集群之上
混部非混部集群资源使用对比图
在日常情况下，我们可以把在线服务的集群的 CPU 利用率从非混部的 10%提升到混部的 40% 以上，整体的成本节省在 30% 以上。而在线受到的干扰在 5%以内。
混部非混部集群平均服务响应时间对比图
混部调度的架构
混部调度的架构示意图
在混部集群中，我们的两个调度平台同时自主运行，sigma 管理在线服务容器的调度，而 Fuxi 管理 ODPS 上的的计算任务。为了让这两个调度器能一起进行工作，在中间我们使用了零层与零层管控来协调两者之间的资源分配。
1. 在线服务容器调度器 Sigma 的特点是：
● 兼容 Kubernetes 的 API，和开源社区共建
● 采用阿里兼容 OCI 标准的 Pouch 容器
● 经历过阿里多年的大规模使用和双十一的验证
2. 计算任务调度器 Fuxi 的特点是：
● 面向海量数据处理和大规模计算类型的复杂应用
● 提供了一个数据驱动的多级流水线并行计算框架，在表述能力上兼容 MapReduce，Map-Reduce-Merge，Cascading，FlumeJava 等多种编程模式
● 高可扩展性，支持十万以上级的并行任务调度，能根据数据分布优化网络开销。自动检测故障和系统热点，重试失败任务，保证作业稳定可靠运行完成
3. 通过零层的资源协调机制，让整个集群平稳地管理并运行进来：
● 混部集群管理
● 各调度租户之间的资源配比
● 日常与压测大促等时段的策略
● 异常检测与处理