【IT168 技术】有人做过计算，当10万台服务器，利用率从28%提升到40%，就能节省出3万台机器。假设一台机器的成本为2万元，那么节约的成本就有6个亿。这是个惊人的数字，意味着在庞大的数据中心服务器规模下，平均利用率每提高一点，就会带来非常可观的成本节约。

　　有人说，技术是商业需求倒逼出来的。其实，不论怎么说，技术创新的目的虽然不全是，但有几个方面是确定的，那就是满足业务需要，同时提升效率和降低成本，这方面，阿里巴巴就是一个典型的案例。

　　早期的阿里巴巴去IOE，不仅是成本问题，同时还是因为Oracle解决不了每秒十几万TPS的业务需求，如何做到更高的TPS，怎样实现低成本，这是摆在当时阿里巴巴众多工程师面前的问题。

　　最近刚结束的天猫2017双11，数据显示，成交总额1682亿，交易峰值32.5万笔/秒，支付峰值25.6万笔/秒，比去年增长超1.1倍，再次刷新全球纪录。

　　但鲜为人知的是，今年的双11，虽然数据再度刷新全球记录，但对阿里巴巴而言，新增IT资源需求却实打实的削减了一半。这是如何做到的?一番探究下来，在阿里巴巴云化战略中，基于阿里云混合云弹性能力之上的几项重大技术点突破，包括资源Pouch容器化、统一调度、存储计算分离和混部技术功不可没。

　　正是这些技术点上的突破让阿里巴巴整体云的弹性能力升级，资源利用率大幅提升，从而做到成本不断下降。如通过混部技术，阿里巴巴可以在1个小时内，将离线计算任务的集群拉起，投入到在线服务上支撑数万笔的交易，整体节省30%的成本。

　　阿里巴巴云化战略，是阿里集团基础设施近年来一直在努力的方向，其目的就是为了解决资源投入问题，在解决资源弹性投入基础上，进一步提升弹性资源投入后的使用效率，从而可以带来资源投入本身的节省。

　　其实不仅是阿里巴巴这么干，微软，华为也都在推动全面云化战略，但阿里巴巴显然在这方面走的要更快。

　　阿里巴巴云化战略历史及相关技术点逻辑

　　据老鱼了解，阿里巴巴云化战略大致分为三个阶段：

　　第一阶段，以往的双11，没有阿里云时，每次都会要采购大量的机器，资源比较浪费;

　　第二阶段，有了阿里云后，每次双11的前两个月左右，在做容量规划时就要考虑采用阿里云的弹性资源，但资源占用周期长，这个阶段主要是依靠阿里云的弹性资源来应付洪峰流量;

　　第三阶段，即在现在有的混合云架构下，利用阿里云弹性能力的升级，快速调度用于计算任务的离线集群弹性资源投入在线服务，多种任务混合部署，这意味着需要将资源使用和任务运维标准化，即全面Pouch容器化，弹性资源占用周期大幅缩短;

　　在阿里巴巴集团业务全面云化战略中，调度技术是非常重要的一环，而其中的混部技术更是降低数据中心资源成本的核心秘密武器。但要想实现便捷调度，在线资源的Pouch容器化改造就在所难免。而混部技术的前提，必须是在在线资源Pouch容器化改造及Sigma调度系统的日趋完善下才能成为可能。

　　据了解，今年，阿里巴巴各BU在线系统都陆续进行Pouch化改造和接入到Sigma统一调度系统中来，数以万计的在线业务服务器不断加入到Sigma资源池中，统一管理，资源共享，对业务屏蔽基础设施复杂的细节，从而大幅提升效率和节省成本;为保证接入Sigma的业务能够稳定高效，Sigma做了不少的优化。

　　细说阿里sigma调度系统

　　众所周知，无论是什么自动化调度的集群管理系统都有一个共同的目标，那就是提高数据中心的机器利用率。

　　据Gartner的统计显示，全球的服务器利用率只有6%-12%。即使通过虚拟化技术优化，利用率还是只有7%-17%。通过资源的精细化调度以及虚拟化的手段，让不同服务共享资源，堆叠高密度部署，可以有效的提升资源利用率。

　　但上述基于资源和虚拟化技术的调度模式用在在线业务系统上存在问题。因为资源共享和高密部署会带来各个层面的资源使用竞争，从而增加在线服务的延迟，尤其是长尾请求的延迟，这对时延要求较高的在线业务是无法接受的。但另一方面，近年来随着大数据的普及，对实时性要求并不高的批量离线作业规模越来越大，在资源使用上，逐渐和在线业务的体量相当，甚至超过了在线业务。

　　于是阿里巴巴的工程师们很自然想到，将离线业务和在线业务混合部署在一起运行会怎样?能否在牺牲一些离线作业延迟的情况下，充分利用机器资源，又不影响在线的响应时间?

　　阿里巴巴从2015年开始做了这个尝试。在这之前，阿里内部针对离线和在线场景，分别各有一套调度系统： 从2010年开始建设的基于进程的离线资源调度系统Fuxi(伏羲)，和从2011年开始建设的基于Pouch容器的在线资源调度系统Sigma。

　　从2015年开始，阿里巴巴尝试将延迟不敏感的批量离线计算任务和延迟敏感的在线服务部署到同一批机器上运行，让在线服务用不完的资源充分被离线使用以提高机器的整体利用率。

　　据了解，这个方案经过2年多的试验论证、架构调整和资源隔离优化，目前已经走向大规模生产，并已服务于电商核心应用和大数据计算服务ODPS业务。混布之后在线机器的平均资源利用率从之前的10%左右提高到了现在的40%以上，并且同时保证了在线服务的SLO目标。

　　而作为可以便捷进行调度的基础，在线资源的容器化改造在所难免。

　　自研Pouch 资源全面容器化改造

　　阿里巴巴作为全球业务场景最复杂的互联网服务提供商之一，其背后自然少不了容器技术的支撑。只不过阿里巴巴并没有采用市面上的容器技术，而是选择了自研。

　　Pouch，到过今年云栖大会的人都不陌生，它就阿里巴巴自研并开源的容器技术。相比Docker、Rkt等容器技术， Pouch在容器生态中并不是一个创新者，但是阿里认为“只有Pouch更懂应用，更贴近场景”，项目名称Pouch本意为育儿袋，也隐喻贴身呵护应用的意义。

　　关于容器技术的价值和在云化战略中的作用，相信不用多说也都了解，关于Pouch，此前已经有很多文章介绍，这里就不在细说。重点说下可能大部分人不知道的，阿里巴巴资源Pouch容器化改造现状。据老鱼了解，目前在阿里的数据中心运行有数十万个Pouch容器，且100%电商核心业务已通过Pouch容器化对外服务。

　　同时，老鱼还了解到，Pouch团队计划在双11后的《中国开源年会》上现场开放源代码，同时将在2018年3月底发布第一个大版本。

　　而正是在在线资源Pouch容器化改造及Sigma调度系统的日趋完善下， 混部技术在阿里巴巴的可能性才越来越大。

　　阿里混部技术克服的难点及成效

　　为了便于理解，这里需要简单介绍一下两种常见的任务类型：离线计算和在线业务。通常来说离线的大部分是计算密集型业务，离线集群的压力水位较高，对延时不敏感，而在线业务恰恰相反，特别是电商金融类业务，平时压力水位较低，但对延迟极为敏感。

　　在平时可以极大地提升服务器资源利用率，在大促活动需要突增在线服务器的时候，又可以通过在线服务占用离线计算任务资源的方式，来顶住短暂的超高峰值压力。阿里巴巴把这样的技术称之为混部。从阿里巴巴目前的进展来看，基本上也能达到节省30%以上的机器数。

　　2015年，阿里巴巴通过混部调度技术，尝试将前文提到的大数据计算资源调度系统Fuxi(伏羲)， 和基于Pouch容器的在线服务资源调度系统Sigma，两者无缝串接在了一起。而要实现全面的混部，需要克服诸如CPU、内存带宽和IO等的资源隔离，存储计算分离等技术难点。

　　面对这些技术难点，阿里巴巴的工程师又是如何做的?先说资源隔离，阿里巴巴首先从服务器的内核层面，对CPU，内存，IO，网络等多方面进行优先级的划分，做到对相关任务的毫秒级自适性调度或限制，以保证高优先级的任务不受影响。而对于存储计算分离，则把资源分为计算节点和存储节点两大类，完全统一了异构机型。

　　在无数次的试验论证、架构调整和技术优化，阿里巴巴混部技术通过了严格的落地验证，并在2017年大规模走向生产，并服务于企业最核心的交易链路。

　　据老鱼多方了解到的数据，在混部技术实施前的阿里业务情况是在线集群的服务器CPU利用率低，日常利用率10%。而在混部技术实施后， CPU利用率提升，试验集群可以达到40%以上。

　　在刚刚过去的双11中，阿里巴巴成功地把在线服务集群和计算任务集群运行在了一起，约有1/5的流量跑在了这个混合集群上面，在线服务的服务器日均CPU利用率提升至40%以上，峰值更是超过60%，整体节省成本30%以上。当然CPU利用率仅仅是一项参数的提升，更多数据本文就不一一列举。

　　最后，老鱼还了解到，混部技术将是阿里巴巴未来的集群常态，以后不再会有离线/在线集群之分。