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