編者按：本文系阿里巴巴的何劍講師，在掘金技術社群主辦的《中美技術人才矽谷大講堂 | 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 第六期