淘寶雙 11 在近十年的時間，業(yè)務交易額增長 360 倍，交易峰值增長 1200 倍，流量的高速增長也給阿里的整個基礎設施帶來了巨大的壓力。
圖片來自 Pexels
本文為阿里巴巴高級技術專家呂奇分享的《阿里巴巴集團基礎設施的云化演進》案例實錄，將按照如下幾個部分展開分享：
云化的背景
云化的業(yè)務基礎
云化的資源基礎
云化的控制引擎
云化的未來展望
云化的背景
雙 11 帶來的挑戰(zhàn)
淘寶雙 11 在近十年的時間，業(yè)務交易額增長 360 倍，交易峰值增長 1200 倍，從最初的 400 筆/秒，到今年的 49.1 萬筆/秒，這是相當大的跨越。流量的高速增長也給阿里的整個基礎設施帶來了巨大的壓力。
上圖是雙 11 的一個典型流量表現(xiàn)，零點附近因為有限流，所以看起來是一條平線，零點瞬間飆升到最高，并維持在這條線上。
阿里開源了一款 Sentinel 產(chǎn)品，是服務治理限流降級工作的，就是它干的“好事”，雖然有了它能夠對流量進行限制，以最大程度保障系統(tǒng)不被洪流所壓垮，但它也會對業(yè)務體驗有很大的損失。
于是我們想盡可能的減少這種限制，讓大家購物更爽快一些，但這其中遇到了諸多難題，其中包括資源有限的問題。
阿里不僅是只有電商，還包括金融、物流、視頻、票務等等，要支撐的基礎設施需要的資源是非常龐大的。
巨大的成本壓力給我們帶來了挑戰(zhàn)。如何用有限的成本最大化的提升用戶體驗和集群的吞吐能力，用合理的代價解決峰值？如何持續(xù)降低單筆交易成本以提升峰值能力，為用戶提供“絲般潤滑”的瀏覽和購物體驗？
思路 1：通過云的彈性
我們認為利用云的彈性可以極大緩解短時間使用資源的成本壓力。
上圖截取了幾個月中交易集群的峰值線，最高的峰值線是雙 11 產(chǎn)生的，第二根是雙 12 的峰值線，我們發(fā)現(xiàn)雙 11 只有一天，過后資源利用率不高，隔年會形成較長時間的低效運行。
因此，我們想到通過公有云的彈性能力來對這一部分的資源進行削峰填谷。大促開始時，借用云，當大促結束后，把過剩的資源還給云。
思路 2：離線混部
由于在線業(yè)務需要做容災，例如建立多個集群等，容量一般都是冗余比較大的，平時電商或者在線服務，CPU 利用率在 10% 左右，除了雙 11 或者其他大促之外，流量更多是集中在白天。
目前，進入數(shù)據(jù)時代的整個離線業(yè)務或是大數(shù)據(jù)計算的增長規(guī)模遠遠快過在線業(yè)務。但離線業(yè)務資源十分緊缺且資源利用率非常高。
于是，我們考慮平時把一部分的計算任務放到在線這邊，就可以極大提高資源利用率；而雙 11 時，讓離線短暫的降級，便可以借用到大量的資源進行削峰。
云化演進
云化就是讓基礎設施能夠像云一樣聚集極高的資源使用彈性能力。思路上主要是上云和自身云化建設這兩部分。
達到的成果
我們很多年前就開始做這件事情，這些年下來主要的成果包括：雙 11 每萬筆交易每年以 50% 的成本下降；核心的混部集群日均利用率可以達到 45% 以上，高峰期可以維持在 60%-70%。
阿里的業(yè)務技術演進
在 1.0-2.0 時代，阿里是從 PHP 時代遷移到 Java 的時代，主要面向的是真正的企業(yè)級生產(chǎn)。
當它達到了一定規(guī)模后，我們開始做了 2.0 向 3.0 時代的升級，主要是單體應用向大型分布式架構的演進。那個時候比較重要的開源項目 Double，就是代表產(chǎn)物。
在飛速發(fā)展下，我們現(xiàn)在面臨的端口是 3.0 向 4.0 時代的演進，它主要是從單 IDC 架構向多 IDC 架構的云化架構的演進，解決的是成本穩(wěn)定的問題。
它的體量非常大，線上需要很大規(guī)模的資源，如何做好這方面的協(xié)同，是我們研究的一個方向。
云化的業(yè)務基礎
異地多活
多單元化或者云上的方法叫多 Region 化，我們要將其業(yè)務部署在多個集群中，但這個工作并不簡單，其中存在很多內在關系，我主要從三個方面來敘述為何做這件事情。
第一，我們的規(guī)模變得極大。例如我們內部一個容器規(guī)模在 8 核 16G，在外部大規(guī)格的容器下，一個應用可能會達到 1.4 萬-1.5 萬，甚至是更高的規(guī)模體量。
這么大的體量如果放在一個集群規(guī)模下，是非常難以管理，并且所有支撐的基礎組件，如調度系統(tǒng)、中間件都會出現(xiàn)瓶頸。
第二，容災。任何程序都有可能出問題，但是如何最大程度的在發(fā)生線上故障的時候，讓損失降到最低呢？
最簡單的做法就是不要把雞蛋放到一個籃子里，所以我們做了多單元，當一個單元出問題的時候，就把整個單元下掉，而流量切到其他的單元上。
第三，上云。此外，我們要用云上的資源，而且要用得比較迅速，這時候就需要有一個能力很快把業(yè)務完整的搬到云上，用完后再快速的下掉，也就是業(yè)界常說的混合云能力，而這個技術就是基礎。
異地多活的業(yè)務架構
上圖是典型的交易單元異地多活的架構。這里面包含普通單元以及中心單元兩部分。
通過我們的規(guī)模化運維平臺，可以做到一鍵建站，一天內就可以去異地搭建一個新的淘寶、天貓等。
以交易單元為例，現(xiàn)在交易的普通單元，主要處理的一個數(shù)據(jù)是買家維度。因為賣家的數(shù)量在雙 11 當天不會突然增加，所以簡單來講，從業(yè)務劃分、流量切分，主要也是按照買家的 ID 做一個哈希，然后切分。
因為每一個單元的集群能力不一樣，流量不一樣，所以這里面還有很多的策略。
普通單元主要處理的是買家維度，但商品及庫存是需要統(tǒng)一處理的，舉些簡單的例子，如庫存扣減我們目前也是統(tǒng)一到中心單元中進行扣除來防止超賣的情況。
并且賣家維度也是需要一個集群來承擔，而中心單元就是承擔了這樣的責任。
另外中心單元也承擔著所有單元交易數(shù)據(jù)同步的能力，中心單元包涵了所有的數(shù)據(jù)。
當某個單元出現(xiàn)問題的時候，流量就會先切到中心單元，等單元數(shù)據(jù)同步完成之后，再切到其余單元。
2013 年的時候，杭州做了 2 個同城單元的驗證；2014 年的時候，我們在上海和杭州之間做了 2 個單元。
2015 年的時候，我們建了 4 個單元，另外 1 個單元就是在千里之外的地方。2018 年雙 11 有 7 個單元，大家的距離就更遠了。
做單元化架構，并不是單元越多越好，這其中是有成本問題的，大家可以看到對于普通單元，也會存在一份全量的庫存，賣家等的數(shù)據(jù)，單元數(shù)越多，冗余也越多，同心同步壓力也會隨之增大。
異地多活的技術架構
異地多活的技術架構，在外部流量過來的時候會有一個統(tǒng)一接入層，這一層會按照用戶 ID 標識來進行流量分流。其實我們做的很重要的一件事情就是單元的自閉性。
單元自閉性顧名思義就是一次調用，流量進入到一個單元后，我們希望把所有的服務調用都在這一個單元內處理掉，但這并不完全能做到，有些服務還是需要跨到中心單元調用的，所以第一個問題就是路由的一致性。
第二個問題是數(shù)據(jù)延時，跨城異地多活必然會有延時，網(wǎng)絡延時來回就幾十毫秒過去了，但這其中涉及到很多的數(shù)據(jù)同步。
比如中間件的消息同步問題，都可能會產(chǎn)生數(shù)據(jù)變更不及時的問題，嚴重了可能引發(fā)資損。
最后一個問題是數(shù)據(jù)正確性問題，很多全量數(shù)據(jù)在數(shù)據(jù)同步的時候，會發(fā)生數(shù)據(jù)冗余，一旦有數(shù)據(jù)冗余，數(shù)據(jù)在便會不一致。我們以前也有一些相關的內部產(chǎn)品 BCP，是專門做數(shù)據(jù)校驗的。
網(wǎng)絡虛擬化
多單元的架構后，我們有能力把業(yè)務搬上云了，但是網(wǎng)絡上如何來互通呢？我們用網(wǎng)絡虛擬化來解決數(shù)據(jù)通信以及隔離的問題。
阿里的絕大部分應用都是跑在 Pouch 容器上的，Pouch 相關的技術也已經(jīng)開源，而所有容器都是跑在這個層虛擬網(wǎng)絡上的，這樣既解決了網(wǎng)絡互通問題，也解決了網(wǎng)絡間的隔離性問題。
初步的混合云架構
2015 年我們完成了混合云架構，當本地保有云無法支撐時，我們就快速在公有云上擴建新的單元，當流量過去后，再還資源給公有云。
我們在集團內部保有云部分，在線服務調度是 Pouch，還有一部分是離線計算任務，目前還是用物理機的模式。
另外一部分是公有云的，我們采用的是 Pouch On Ecs 的方案，打通云上云下的整個運維體系。
對于業(yè)務方來說，1.5 萬個容器，又分 7 個單元，公有云，保有云運維模式都不相同的話，業(yè)務方式肯定要崩潰，所以我們實際上是做了一體化的處理。
云化的資源基礎
PouchContainer 容器
上圖我們真正建立了組部的混合云 Pouch，Pouch 是云化資源的標準，是云化資源的基礎，如果不打通，整個運維復雜性會非常大，在演進之初我們就開始極力推行容器化。
PouchContainer 容器 2011 年就開始建設了，2017 年的時候，PouchContainer 已經(jīng)開源出來，并達到了百萬容器的規(guī)模。
2011 年，我們基于 LXC 開始做的時候，只考慮了 Runtime，那個時候覺得物理機比較大，在物理機上部很多應用會比較麻煩，而用虛擬機的模式，Overhead 又比較高。
我們就想到了用容器來解決，當時阿里主要的語言是 Java，Java 語言在運維上是有一些標準的，所以我們沒有按照容器即服務的方式建立這個標準。
但是這兩年阿里也收購了很多公司，各種語言都會進入到整個的研發(fā)體系中，運維復雜度就大大提升了，效率瓶項非常明顯。
在 Docker 興起之后，2015 開始做 Docker 的兼容，把 Docker 好的部分兼容進來，形成了我們的 PouchContainer。
大家知道 Docker 里最重要的一個組件是鏡像，但鏡像有一個很大的問題就是比代碼包的模式要大得多，分發(fā)的速度也就慢下來了，而且對于鏡像源的壓力也是一個大問題。
我們一個應用可能會大到 1.5 萬余個容器，如果它的鏡像是在同一個源上，這個源馬上就會被打掛，再大的帶寬都不夠。
于是我們采用了開源項目 Dragonfly，它也是剛剛進入 CNCF 項目，通過 P2P 網(wǎng)絡來解決這個問題。
Pouch 的演進
對于大公司來說，容器化最大的阻礙是歷史包袱。我們 2011 年開始做了 T4 容器，那個時候是基于 LXC 做的，但當時為了能夠把物理機很好的遷移到 T4 上，我們做了兼容。
T4 上有獨立的 IP，能夠讓 SSH 登陸進去，可以跑多進程，有 SystemD，甚至我們做了可見性的隔離，對于用戶來說使用容器還是虛擬機，體驗是一致的。
這樣的話，我們的升級可以在下層做掉，而對用戶來說付出的成本是比較小的，我們把這個稱之為富容器技術。
云化的控制引擎
統(tǒng)一調度
只有把容器管理好，整個效率才會高，整個云化才能有更好的效率。于是我們做了統(tǒng)一調度，內部我們在線服務資源調度器稱之為 Sigma，離線的計算任務資源調度器稱為 FUXI。
FUXI 是我們飛天架構體系當中非常重要的一環(huán)。此外，又通過 0 層打通兩個調度器，提供一個統(tǒng)一的資源視圖和管理器。
Sigma：
始于 2011 年，以調度為中心的集群管理體系。
面向終態(tài)的架構設計；三層大腦合作聯(lián)動管理。
基于 K8S 和開源社區(qū)共同發(fā)展。
FUXI：
面向海量數(shù)據(jù)處理和大規(guī)模計算類型的復雜應用。
提供了一個數(shù)據(jù)驅動的多級流水線并行計算框架，在表述能力上兼容 MapReduce，Map-Reduce-Merge，Cascading，F(xiàn)lumeJava 等多種編程模式。
高可擴展性，支持十萬以上級的并行任務調度，能根據(jù)數(shù)據(jù)分布優(yōu)化網(wǎng)絡開銷。自動檢測故障和系統(tǒng)熱點，重試失敗任務，保證作業(yè)穩(wěn)定可靠運行完成。
什么是混部
把集群混合起來，將不同類型的任務調度到相同的物理資源上，通過調度，資源隔離等控制手段，保障 SLO，極大降低成本，這樣的技術我們稱之為混部。
在線離線混部：
在線優(yōu)先級高：就像是石塊，且延時敏感，利用率不高，不可重跑。
離線優(yōu)先級低：就像水和沙子，且延時不敏感，利用率高， 可重跑。
低優(yōu)先級犧牲：當在線不忙時，離線就搶占，反之則返還，甚至反哺。
優(yōu)先級互補性：是可以進行混部，并帶來成本收益的兩個前提條件。
混部架構：
混部始于 2014 年，2017 在阿里大規(guī)模鋪開。
在線服務長生命周期，定制化策略復雜，時延敏感；計算任務短生命周期，大并發(fā)高吞吐，時延不敏感。兩邊正好產(chǎn)生互補。
通過 Sigma 和 FUXI 完成在線服務、計算任務各自的調度，計算共享超賣。
通過零層相互協(xié)調資源配比做混部決策，通過內核解決資源競爭隔離問題。
架構非常靈活，一層之間是共享狀態(tài)調度，一層之上定制二層調度。
混部的日常效果如下圖：
上圖是 2017 年的混部日常效果圖。2017 年我們做到整個集群混部 45%，非混部大概是 10%，中間有 30% 的提升，2018 年我們已經(jīng)做到了 45% 以上，峰值可以拉到 60%-70% 以上。
混部肯定是有犧牲的，它對優(yōu)先級高的業(yè)務肯定會有影響，我們把影響做到了 5% 以內，我們可以看到這兩條線，一個是混部集群，一個是非混部集，它的 RT 表現(xiàn)影響在 5% 以內。
混部的核心技術
混部的核心技術一方面是調度。通過資源畫像，在競爭之前，盡量減少資源競爭的可能性。但競爭永遠會發(fā)生，因為調度是宏觀的數(shù)據(jù)。
微觀上，資源的使用其實是有局部競爭的，所以另一方面，我們在內核上面做了很多的保障，在資源發(fā)生極端競爭的情況下，會優(yōu)先保障高優(yōu)先級任務，它被動但是延時非常低，毫秒級就可以做出反應。
基于統(tǒng)一 QOS 的調度體系：
調度自身 SLO：在線，離線定義自身 SLO 以及和 0 層資源優(yōu)先級對應映射。
資源優(yōu)先級定義：共同制定 0 層資源優(yōu)先級等級定義。
資源度量及控制：統(tǒng)一度量標準作為 0 層資源控制，調度本身不管是哪種使用資源的策略，但最后必須能轉換成 0 層的標準度量單位。
日常的分時復用
我們很早就做了彈性的容量托管，但我們發(fā)現(xiàn)，只有真正把資源都混合在一起了，才可以把這個資源分時復用的價值放大出來，而這一部分主要節(jié)省的是內存資源瓶頸問題。
大促分時復用
上圖中上面是我們的日常態(tài)，在大促的時候，1 小時之內我們會直接切換成下面的狀態(tài)，直接把在線的業(yè)務、流量都放上來，部署起來形成 1 個大促狀態(tài)。這個大促支撐了 12 萬的交易。
實時的內存超賣
其實在混部中，競爭最大的并不是 CPU，因為 CPU 實際上是一個可壓縮資源，是有彈性的，但內存是沒有彈性的，內存一旦不足，就會 OOM。
這兩年大家為了性能的問題，以空間換性能，在內存里放了很多東西，內存資源非常緊張，所以我們會根據(jù)實時的內存使用來調整內存的使用水位，我們把這個叫內存超賣技術。
在內存這塊，目前還有一些最新的研究方向，比如如何更好的管理 Pagecache 等。
存儲計算分離
存儲計算分離是我們做混部時遇到的第一個問題，因為大數(shù)據(jù)需要很大的計算資源、需要很大的磁盤，而在線應用需要的磁盤很小。
原先的時候我們都在一個物理機上，根本沒有辦法調度，所以我們把計算和存儲做了分離，把原來統(tǒng)一的資源拆分成了計算節(jié)點與存儲節(jié)點。
這樣就能更好的控制存儲的性能與容量問題，讓成本保持最優(yōu)，不過這個方法會對網(wǎng)絡有較大的依賴。
內核隔離
我們最終形成了一整套混合云的體系。我們將所有的業(yè)務在上層進行混合部署，下層既可以是在線的獨立集群，也可以是混合部署的集群。
還可以是計算業(yè)務獨立的集群，甚至也可以是 ESC 上面的集群，公有云的這些集群，形成上圖的架構體系，所有資源層都可以打通，形成混合云模式，共同來支撐起阿里巴巴的業(yè)務。當然最終的目標是完全轉化到公有云上。
云化的未來展望
目前我們研究的方向很多也很雜，文章上述提到了幾個階段：
微服務化，主要解決的是人與服務的協(xié)同。而最復雜的是服務與服務的協(xié)同，也就是我們常說的服務治理。
云化架構我們認為是人與資源的協(xié)同，而最難的是資源和資源的協(xié)同，比如像單元化，混部等。
我個人認為未來的一個方向是業(yè)務與資源的協(xié)同，也就是用戶不再需要關注資源，關注運維，只要把業(yè)務要求以標準形式輸入就可以了，系統(tǒng)自動會以最佳的策略進行部署。要做到這些，可以采用業(yè)界炒得比較火的 Serverless 的模式，其中的關鍵是打通業(yè)務與資源中間的標準。
作者：呂奇
