阿里巴巴黑科技调度系统揭秘 - 何剑 | JTalk 第六期

编者按：本文系阿里巴巴的何剑讲师，在掘金技术社区主办的《中美技术人才硅谷大讲堂 | JTalk 掘金线下活动第六期》 活动上的分享整理。掘金 JTalk 目前已举办6期，每期 JTalk 会邀请垂直行业的优秀工程师来分享优秀的实践经验，技巧方法。旨在为开发者提供线下技术交流互动机会，帮助开发者成长。

何剑，阿里巴巴高级技术专家，就职 Sigma 调度系统组。此前就职于 Hortonworks，YARN team 早期开发成员，曾负责多个重要 feature 在Hadoop YARN社区的开发，Hadoop Committer and PMC, 专注于资源管理系统，调度系统研究，于布朗大学硕士毕业。

很多人也许听到这些名词很多：Kubernetes, YARN, Mesos, Docker Swarm, Borg, Sigma。这些是当下业界最流行的资源调度系统。他们到底是做什么且他们之间又有什么区别呢？这一次演讲，我会介绍一下这些调度系统，也会展示一下阿里巴巴的调度系统 Sigma 是如何支撑住双11这种巨大的体量。 今天我先给大家概述一下什么是调度系统，以及调度系统的应用场景。调度系统相对来讲还是一个比较偏底层的领域。 介绍一下我自己，我现在在阿里巴巴的Sigma组，Sigma是我们组的一个产品，它负责阿里巴巴所有的集群和调度。我之前在一家叫做Hortonworks的大数据公司，我已经做了5年的Hadoop。

什么是容器

容器有点像虚拟机Virtual Machine(VM)，但容器比VM更轻量化，比起VM搭建的速度更快。容器能把你的代码、Runtime和Libraries打包成一个Bundle再做成镜像(image)，你可以把这个镜像想象成存放在磁盘上的一个文件。你可以通过Docker把镜像运行起来。容器提供了隔离的功能，即跑在容器内的应用，看不到容器外的应用的信息。

什么是Dokcer

我简单介绍一下Docker，Docker始于2013年，它基于Linux核心中的cgroups资源隔离机制，以及Linux核心名字空间来创建独立的软件容器。如图可以看到容器包含了一些不同的应用，像是Tomcat、Java的一些Runtime和Debian这样的小型OS，如此打包起来就是一个Container。类似的这边还有一个PHP+MySQL+Ubuntu的Container，它们两个容器的底层都是OS Kernel 这张图是容器和VM的对比，最大的区别在于VM有一个Hypervisor，它的分量比较重；而在容器上相对应的则是Docker Daemon，当用户提交请求时，Docker Daemon 会帮用户转化用户的请求，比方说你告诉Docker你需要一个容器，Docker Daemon负责接受请求并帮你把Docker container run起来。 ##什么是调度

• 调度可以将容器快速放置在集群的机器上
• 根据用户请求将容器分配到不同的机器上
• 限制容器容量和保证容器公平
• 通过将空闲的机器分配到有需求的地方来提升资源利用率
• 帮助出错挂掉的服务器重启 业界流行的调度系统中最古老的就是Google Borg，在上面跑了大部分Google的任务，以及一些后端的服务。Kubernetes也是来自于Google，Docker Swarm是Docker公司自己写的一套调度系统，Yarn是Hadoop的一个子项目。阿里巴巴内部的调度系统是Sigma和Fuxi。 我先简单介绍一下什么是Kubernetes，它最早是由Google开源出来的，过去两年它做了很多宣传，越来越多的人了解了它。现在Kubernetes接手了大部分的containerized workloads和服务。 这是Kubernetes的一个大致架构，用户提交一个请求给API Server，API Sever会把请求转交给Kubernetes Master，即做了一个调度逻辑。每个大公司的集群肯定会有一个task，它会在Nodes上分配一些容器给用户。 Kubernetes有一个好的地方就是它把多个容器抽象成了Pod，方便用户管理。 这里介绍一个例子，这是用户部署一个Web Application时的流程。如动图所示，比方说用户想在网页上部署一段“Hello World”的Web App，用户指定说要一个Replica，调度器会在Node 1上分配一个Pod出来，Pod里跑了一个Hello World的Container。调度接收到这个请求后，会把这个Web Server的容器复制三份，在Node1/2/3上都跑同一份Replica。假如有一天一个Node挂掉了，那么调度器就不能满足原来三份Replica的请求。这样调度器会在现有的Node中再申请出一个Pod出来满足用户请求。

现在我介绍一下Hadoop，Hadoop内也有一个调度器，叫做Yarn。最早的Big data jobs其实就是MadReduce，它可以分割成一个Mapper task和一个Reducer task。 它的过程也类似，Resource Manager扮演Master的角色，会把task分配到不同的机器上面，我们用容器做一个分装，让它们在不同的机器上一起跑。 Kubernetes和Yarn的最大区别是前者主要负责long running service 任务，后者则是跑一些batch jobs Google有一个成熟的调度器叫做Borg，他把前面两者的特性都支持了，它可以既跑batch jobs又可以跑long running service。 这些调度系统，架构都比较类似 ， 无非都是从client端发 出一个请求，中间会有一个master接受请求，然后有一个调度器来根据现有的nodes的情况来把请求分给节点。

Sigma

刚才主要介绍了一些当前业内的开源项目和，下面我介绍一下Sigma。Sigma在阿里巴巴开发了也有几年时间，它经过了一系列升级和改动，也吸收了一些业界内先进的想法。 我先介绍一下阿里原来的调度系统存在的一些问题。 T4是我们原来一个阿里内部开发的容器，一个T4分组就是一个小集群。在过去，阿里有着很多个小集群，每个小集群各自为政，只能跑在单独每个小集群里面，不能跑在其他集群上面，这就导致了资源碎片化。当你部署一个应用时，你的应用受限于一个固定的小集群，没法利用其他空闲出来的集群的资源。在双十一的时候，我们发现某些跟双十一业务相关的集群的利用率会非常高，能达到45 - 50%；但一些跑简单任务的集群，非常空闲，整体看来这就是一种资源的浪费。 造成这种资源浪费的状况，跟阿里的历史有关。最早阿里内部每个Business Unit（简称BU）会独立研发一套专属的调度系统，这会造成资源浪费。假如有一个BU购置了10000台机器，现在只跑了一半，另一半处在闲置状态而无法被其他BU调用；而另一个BU，可能由于资金不够，购置的服务器资源比较少，但因为调度器的不统一，它无法借用到其他BU的资源。 因此，我们做的最重要的事是打通BU资源池，把所有机器连接到同一个资源池下面，这样的好处就是我们可以借助一个调度器来调度所有资源池的资源。比方说我要跑一个应用，过去我可能受限于我自己的资源池的资源，而现在我可以用到整个阿里集团的所有资源。特别是在双十一期间，这会非常有效，因为双十一只是那一天或者那一周使用的资源特别多，过了那段时间资源使用率会迅速降低。我们不可能为了双十一活动的那一个星期而购买很多机器，然后等双十一活动结束这些机器就闲置着。 图上就是我刚才提到的双十一服务器资源使用的情况，如果采购了大量机器，那么在图上的非高峰期，资源几乎全部都浪费掉了。所以在这个时间点的情况下，我们会从阿里云上动态地借用一些虚拟机，在高峰期那一天或者那一周，来部署一些新的应用。等时间一过，我们再把资源还给阿里云。这样做的好处就是，我们不用再为了那几天去买全年都不怎么用得到的机器资源 Sigma 的架构主要分四个层面：最底层是基础设施，包括IDC建设和网络架构等。Sigma 是以大脑的形式存在并完成一些功能，比如我刚才提的调度和智能规划。它会根据你的历史资源使用率来预测以后需要购买多少台机器并制定策略；而业务场景就会比较复杂。比如当用户部署一个应用时，这个月用户可能只需要部署100个资源，等下个月需求增加时，它会动态扩容至200个资源，这就是Sigma所支持的弹性扩容/缩容.此外有一些业务逻辑，比如阿里巴巴的数据库和交易、蚂蚁金融以及所有的搜索引擎和调度都是跑在我们Sigma调度平台上。 阿里巴巴有两个资源调度器，一个叫Sigma另一个叫Fuxi，它们的逻辑还是有点不太一样。Sigma是负责电商，交易、搜索相关类似long running service的事业部门，而Fuxi这边负责计算相关的业务逻辑，目前这两个业务池仍处于分割的状态。现在我们在做一些努力，要把这两个调度器的资源打通，为此我们在中间增加了一个“决裁者”，它可以把Sigma 上的资源借用给Fuxi，当Fuxi这边有空闲的资源时它也可以借用给Sigma，我们可以把这两个调度器实现一种弹性的资源复用。 如图是一个Sigma没有跟Fuxi一起跑时的简单实例，可以看到晚上的时候Sigma比较空闲，因为半夜买东西的用户比较少；而从白天到晚上8点，淘宝和天猫的流量都比较高，Sigma也跟着保持高资源利用率。 这张图上也比较类似，在双十一那天Sigma利用率特别高，但在双十一之前和之后资源利用率比较低。我们的想法是把其他时间段Sigma空闲的资源借用给Fuxi，因为Fuxi并不是跑交易相关的逻辑，它主要跑一些离线的job。 上面这张图就显示了Sigma 和 Fuxi 在不同的时间段共享资源来实现资源来用率的最大化 刚才主要讲了调度器相关的，现在来介绍一下阿里内部的容器发展方向。阿里也开发了类似Docker的容器，叫作Pouch。Pouch始于2017年，基于Linux Containers 开发的，到了2017年所有的Web应用和跟电商，搜索等等相关的逻辑应用全部Pouch化，即容器化(Containerize)，把所有的在线应用打包成一个容器，并用容器的概念来部署这些应用。 Pouch是2017年10月份的时候开始孵化，到了同年11月份的时候正式把Pouch项目开源，2018年3月我们发布了Pouch的第一个正式版本。 这里简单介绍一下Pouch在阿里内部的应用场景，在2017年11月份1682亿交易额的背后，100%的在线业务都是拿Pouch来跑的。而“容器规模达到百万级”，指的是在我们有将近百万个Pouch容器在支撑着各种电商，搜索场景。基本上阿里集团所有的日常应用场景都用Pouch来部署，除了电商应用以外它还覆盖了部署数据库等等。 这幅图表明的是阿里的Pouch跟整个容器生态圈是兼容的，它兼容了社区一些通用的接口，比如Container Network Interface(CNI)、Container Storage Interface(CSI)。 刚才我提到一个容器所对应的镜像可以想象成一个在磁盘上的镜像文件，我们在阿里这个巨大场景下分发文件本身就是一个特别复杂的过程，我们开发有一个叫Dragonfly的镜像分发项目，就像我们用BitTorrent来下载一些文件，用P2P的模式把文件下放到不同的Host/节点上面. Pouch目前在和国内也是有一些关注者，在GitHub上有2000多个Stars，和50多个来自不同公司的Contributors。

《中美技术人才硅谷大讲堂 | JTalk 掘金线下活动第六期》 分享整理合集

Android P 新特性大起底 - 李寄超 | JTalk 第六期

阿里巴巴黑科技调度系统揭秘 - 何剑 | JTalk 第六期

如何玩转新技术 - 潘阳 | JTalk 第六期

转载于:https://juejin.im/post/5b023337518825426539be30