阿里巴巴黑科技調度系統揭祕 - 何劍 | JTalk 第六期

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

相關文章
相關標籤/搜索