淘寶雙 11 在近十年的時間，業(yè)務(wù)交易額增長 360 倍，交易峰值增長 1200 倍，流量的高速增長也給阿里的整個基礎(chǔ)設(shè)施帶來了巨大的壓力。

[[270848]]

圖片來自 Pexels

本文為阿里巴巴高級技術(shù)專家呂奇分享的《阿里巴巴集團基礎(chǔ)設(shè)施的云化演進》案例實錄，將按照如下幾個部分展開分享：

• 云化的背景
• 云化的業(yè)務(wù)基礎(chǔ)
• 云化的資源基礎(chǔ)
• 云化的控制引擎
• 云化的未來展望

云化的背景

雙 11 帶來的挑戰(zhàn)

淘寶雙 11 在近十年的時間，業(yè)務(wù)交易額增長 360 倍，交易峰值增長 1200 倍，從最初的 400 筆/秒，到今年的 49.1 萬筆/秒，這是相當大的跨越。流量的高速增長也給阿里的整個基礎(chǔ)設(shè)施帶來了巨大的壓力。

上圖是雙 11 的一個典型流量表現(xiàn)，零點附近因為有限流，所以看起來是一條平線，零點瞬間飆升到***，并維持在這條線上。

阿里開源了一款 Sentinel 產(chǎn)品，是服務(wù)治理限流降級工作的，就是它干的“好事”，雖然有了它能夠?qū)α髁窟M行限制，以***程度保障系統(tǒng)不被洪流所壓垮，但它也會對業(yè)務(wù)體驗有很大的損失。

于是我們想盡可能的減少這種限制，讓大家購物更爽快一些，但這其中遇到了諸多難題，其中包括資源有限的問題。

阿里不僅是只有電商，還包括金融、物流、視頻、票務(wù)等等，要支撐的基礎(chǔ)設(shè)施需要的資源是非常龐大的。

巨大的成本壓力給我們帶來了挑戰(zhàn)。如何用有限的成本***化的提升用戶體驗和集群的吞吐能力，用合理的代價解決峰值?如何持續(xù)降低單筆交易成本以提升峰值能力，為用戶提供“絲般潤滑”的瀏覽和購物體驗?

思路 1：通過云的彈性

我們認為利用云的彈性可以極大緩解短時間使用資源的成本壓力。

上圖截取了幾個月中交易集群的峰值線，***的峰值線是雙 11 產(chǎn)生的，第二根是雙 12 的峰值線，我們發(fā)現(xiàn)雙 11 只有一天，過后資源利用率不高，隔年會形成較長時間的低效運行。

因此，我們想到通過公有云的彈性能力來對這一部分的資源進行削峰填谷。大促開始時，借用云，當大促結(jié)束后，把過剩的資源還給云。

思路 2：離線混部

由于在線業(yè)務(wù)需要做容災(zāi)，例如建立多個集群等，容量一般都是冗余比較大的，平時電商或者在線服務(wù)，CPU 利用率在 10% 左右，除了雙 11 或者其他大促之外，流量更多是集中在白天。

目前，進入數(shù)據(jù)時代的整個離線業(yè)務(wù)或是大數(shù)據(jù)計算的增長規(guī)模遠遠快過在線業(yè)務(wù)。但離線業(yè)務(wù)資源十分緊缺且資源利用率非常高。

于是，我們考慮平時把一部分的計算任務(wù)放到在線這邊，就可以極大提高資源利用率;而雙 11 時，讓離線短暫的降級，便可以借用到大量的資源進行削峰。

云化演進

云化就是讓基礎(chǔ)設(shè)施能夠像云一樣聚集極高的資源使用彈性能力。思路上主要是上云和自身云化建設(shè)這兩部分。

達到的成果

我們很多年前就開始做這件事情，這些年下來主要的成果包括：雙 11 每萬筆交易每年以 50% 的成本下降;核心的混部集群日均利用率可以達到 45% 以上，高峰期可以維持在 60%-70%。

阿里的業(yè)務(wù)技術(shù)演進

在 1.0-2.0 時代，阿里是從 PHP 時代遷移到 Java 的時代，主要面向的是真正的企業(yè)級生產(chǎn)。

當它達到了一定規(guī)模后，我們開始做了 2.0 向 3.0 時代的升級，主要是單體應(yīng)用向大型分布式架構(gòu)的演進。那個時候比較重要的開源項目 Double，就是代表產(chǎn)物。

在飛速發(fā)展下，我們現(xiàn)在面臨的端口是 3.0 向 4.0 時代的演進，它主要是從單 IDC 架構(gòu)向多 IDC 架構(gòu)的云化架構(gòu)的演進，解決的是成本穩(wěn)定的問題。

它的體量非常大，線上需要很大規(guī)模的資源，如何做好這方面的協(xié)同，是我們研究的一個方向。

云化的業(yè)務(wù)基礎(chǔ)

異地多活

多單元化或者云上的方法叫多 Region 化，我們要將其業(yè)務(wù)部署在多個集群中，但這個工作并不簡單，其中存在很多內(nèi)在關(guān)系，我主要從三個方面來敘述為何做這件事情。

***，我們的規(guī)模變得極大。例如我們內(nèi)部一個容器規(guī)模在 8 核 16G，在外部大規(guī)格的容器下，一個應(yīng)用可能會達到 1.4 萬-1.5 萬，甚至是更高的規(guī)模體量。

這么大的體量如果放在一個集群規(guī)模下，是非常難以管理，并且所有支撐的基礎(chǔ)組件，如調(diào)度系統(tǒng)、中間件都會出現(xiàn)瓶頸。

第二，容災(zāi)。任何程序都有可能出問題，但是如何***程度的在發(fā)生線上故障的時候，讓損失降到***呢?

最簡單的做法就是不要把雞蛋放到一個籃子里，所以我們做了多單元，當一個單元出問題的時候，就把整個單元下掉，而流量切到其他的單元上。

第三，上云。此外，我們要用云上的資源，而且要用得比較迅速，這時候就需要有一個能力很快把業(yè)務(wù)完整的搬到云上，用完后再快速的下掉，也就是業(yè)界常說的混合云能力，而這個技術(shù)就是基礎(chǔ)。

異地多活的業(yè)務(wù)架構(gòu)

上圖是典型的交易單元異地多活的架構(gòu)。這里面包含普通單元以及中心單元兩部分。

通過我們的規(guī)?；\維平臺，可以做到一鍵建站，一天內(nèi)就可以去異地搭建一個新的淘寶、天貓等。

以交易單元為例，現(xiàn)在交易的普通單元，主要處理的一個數(shù)據(jù)是買家維度。因為賣家的數(shù)量在雙 11 當天不會突然增加，所以簡單來講，從業(yè)務(wù)劃分、流量切分，主要也是按照買家的 ID 做一個哈希，然后切分。

因為每一個單元的集群能力不一樣，流量不一樣，所以這里面還有很多的策略。

普通單元主要處理的是買家維度，但商品及庫存是需要統(tǒng)一處理的，舉些簡單的例子，如庫存扣減我們目前也是統(tǒng)一到中心單元中進行扣除來防止超賣的情況。

并且賣家維度也是需要一個集群來承擔，而中心單元就是承擔了這樣的責任。

另外中心單元也承擔著所有單元交易數(shù)據(jù)同步的能力，中心單元包涵了所有的數(shù)據(jù)。

當某個單元出現(xiàn)問題的時候，流量就會先切到中心單元，等單元數(shù)據(jù)同步完成之后，再切到其余單元。

2013 年的時候，杭州做了 2 個同城單元的驗證;2014 年的時候，我們在上海和杭州之間做了 2 個單元。

2015 年的時候，我們建了 4 個單元，另外 1 個單元就是在千里之外的地方。2018 年雙 11 有 7 個單元，大家的距離就更遠了。

做單元化架構(gòu)，并不是單元越多越好，這其中是有成本問題的，大家可以看到對于普通單元，也會存在一份全量的庫存，賣家等的數(shù)據(jù)，單元數(shù)越多，冗余也越多，同心同步壓力也會隨之增大。

異地多活的技術(shù)架構(gòu)

異地多活的技術(shù)架構(gòu)，在外部流量過來的時候會有一個統(tǒng)一接入層，這一層會按照用戶 ID 標識來進行流量分流。其實我們做的很重要的一件事情就是單元的自閉性。

單元自閉性顧名思義就是一次調(diào)用，流量進入到一個單元后，我們希望把所有的服務(wù)調(diào)用都在這一個單元內(nèi)處理掉，但這并不完全能做到，有些服務(wù)還是需要跨到中心單元調(diào)用的，所以***個問題就是路由的一致性。

第二個問題是數(shù)據(jù)延時，跨城異地多活必然會有延時，網(wǎng)絡(luò)延時來回就幾十毫秒過去了，但這其中涉及到很多的數(shù)據(jù)同步。

比如中間件的消息同步問題，都可能會產(chǎn)生數(shù)據(jù)變更不及時的問題，嚴重了可能引發(fā)資損。

***一個問題是數(shù)據(jù)正確性問題，很多全量數(shù)據(jù)在數(shù)據(jù)同步的時候，會發(fā)生數(shù)據(jù)冗余，一旦有數(shù)據(jù)冗余，數(shù)據(jù)在便會不一致。我們以前也有一些相關(guān)的內(nèi)部產(chǎn)品 BCP，是專門做數(shù)據(jù)校驗的。

網(wǎng)絡(luò)虛擬化

多單元的架構(gòu)后，我們有能力把業(yè)務(wù)搬上云了，但是網(wǎng)絡(luò)上如何來互通呢?我們用網(wǎng)絡(luò)虛擬化來解決數(shù)據(jù)通信以及隔離的問題。

阿里的絕大部分應(yīng)用都是跑在 Pouch 容器上的，Pouch 相關(guān)的技術(shù)也已經(jīng)開源，而所有容器都是跑在這個層虛擬網(wǎng)絡(luò)上的，這樣既解決了網(wǎng)絡(luò)互通問題，也解決了網(wǎng)絡(luò)間的隔離性問題。

初步的混合云架構(gòu)

2015 年我們完成了混合云架構(gòu)，當本地保有云無法支撐時，我們就快速在公有云上擴建新的單元，當流量過去后，再還資源給公有云。

我們在集團內(nèi)部保有云部分，在線服務(wù)調(diào)度是 Pouch，還有一部分是離線計算任務(wù)，目前還是用物理機的模式。

另外一部分是公有云的，我們采用的是 Pouch On Ecs 的方案，打通云上云下的整個運維體系。

對于業(yè)務(wù)方來說，1.5 萬個容器，又分 7 個單元，公有云，保有云運維模式都不相同的話，業(yè)務(wù)方式肯定要崩潰，所以我們實際上是做了一體化的處理。

云化的資源基礎(chǔ)

PouchContainer 容器

上圖我們真正建立了組部的混合云 Pouch，Pouch 是云化資源的標準，是云化資源的基礎(chǔ)，如果不打通，整個運維復(fù)雜性會非常大，在演進之初我們就開始極力推行容器化。

PouchContainer 容器 2011 年就開始建設(shè)了，2017 年的時候，PouchContainer 已經(jīng)開源出來，并達到了百萬容器的規(guī)模。

2011 年，我們基于 LXC 開始做的時候，只考慮了 Runtime，那個時候覺得物理機比較大，在物理機上部很多應(yīng)用會比較麻煩，而用虛擬機的模式，Overhead 又比較高。

我們就想到了用容器來解決，當時阿里主要的語言是 Java，Java 語言在運維上是有一些標準的，所以我們沒有按照容器即服務(wù)的方式建立這個標準。

但是這兩年阿里也收購了很多公司，各種語言都會進入到整個的研發(fā)體系中，運維復(fù)雜度就大大提升了，效率瓶項非常明顯。

在 Docker 興起之后，2015 開始做 Docker 的兼容，把 Docker 好的部分兼容進來，形成了我們的 PouchContainer。

大家知道 Docker 里最重要的一個組件是鏡像，但鏡像有一個很大的問題就是比代碼包的模式要大得多，分發(fā)的速度也就慢下來了，而且對于鏡像源的壓力也是一個大問題。

我們一個應(yīng)用可能會大到 1.5 萬余個容器，如果它的鏡像是在同一個源上，這個源馬上就會被打掛，再大的帶寬都不夠。

于是我們采用了開源項目 Dragonfly，它也是剛剛進入 CNCF 項目，通過 P2P 網(wǎng)絡(luò)來解決這個問題。

Pouch 的演進

對于大公司來說，容器化***的阻礙是歷史包袱。我們 2011 年開始做了 T4 容器，那個時候是基于 LXC 做的，但當時為了能夠把物理機很好的遷移到 T4 上，我們做了兼容。

T4 上有獨立的 IP，能夠讓 SSH 登陸進去，可以跑多進程，有 SystemD，甚至我們做了可見性的隔離，對于用戶來說使用容器還是虛擬機，體驗是一致的。

這樣的話，我們的升級可以在下層做掉，而對用戶來說付出的成本是比較小的，我們把這個稱之為富容器技術(shù)。

云化的控制引擎

統(tǒng)一調(diào)度

只有把容器管理好，整個效率才會高，整個云化才能有更好的效率。于是我們做了統(tǒng)一調(diào)度，內(nèi)部我們在線服務(wù)資源調(diào)度器稱之為 Sigma，離線的計算任務(wù)資源調(diào)度器稱為 FUXI。

FUXI 是我們飛天架構(gòu)體系當中非常重要的一環(huán)。此外，又通過 0 層打通兩個調(diào)度器，提供一個統(tǒng)一的資源視圖和管理器。

Sigma：

• 始于 2011 年，以調(diào)度為中心的集群管理體系。
• 面向終態(tài)的架構(gòu)設(shè)計;三層大腦合作聯(lián)動管理。
• 基于 K8S 和開源社區(qū)共同發(fā)展。

FUXI：

• 面向海量數(shù)據(jù)處理和大規(guī)模計算類型的復(fù)雜應(yīng)用。
• 提供了一個數(shù)據(jù)驅(qū)動的多級流水線并行計算框架，在表述能力上兼容 MapReduce，Map-Reduce-Merge，Cascading，F(xiàn)lumeJava 等多種編程模式。
• 高可擴展性，支持十萬以上級的并行任務(wù)調(diào)度，能根據(jù)數(shù)據(jù)分布優(yōu)化網(wǎng)絡(luò)開銷。自動檢測故障和系統(tǒng)熱點，重試失敗任務(wù)，保證作業(yè)穩(wěn)定可靠運行完成。

什么是混部

把集群混合起來，將不同類型的任務(wù)調(diào)度到相同的物理資源上，通過調(diào)度，資源隔離等控制手段，保障 SLO，極大降低成本，這樣的技術(shù)我們稱之為混部。

在線離線混部：

• 在線優(yōu)先級高：就像是石塊，且延時敏感，利用率不高，不可重跑。
• 離線優(yōu)先級低：就像水和沙子，且延時不敏感，利用率高， 可重跑。
• 低優(yōu)先級犧牲：當在線不忙時，離線就搶占，反之則返還，甚至反哺。
• 優(yōu)先級互補性：是可以進行混部，并帶來成本收益的兩個前提條件。

混部架構(gòu)：

• 混部始于 2014 年，2017 在阿里大規(guī)模鋪開。
• 在線服務(wù)長生命周期，定制化策略復(fù)雜，時延敏感;計算任務(wù)短生命周期，大并發(fā)高吞吐，時延不敏感。兩邊正好產(chǎn)生互補。
• 通過 Sigma 和 FUXI 完成在線服務(wù)、計算任務(wù)各自的調(diào)度，計算共享超賣。
• 通過零層相互協(xié)調(diào)資源配比做混部決策，通過內(nèi)核解決資源競爭隔離問題。
• 架構(gòu)非常靈活，一層之間是共享狀態(tài)調(diào)度，一層之上定制二層調(diào)度。

混部的日常效果如下圖：

上圖是 2017 年的混部日常效果圖。2017 年我們做到整個集群混部 45%，非混部大概是 10%，中間有 30% 的提升，2018 年我們已經(jīng)做到了 45% 以上，峰值可以拉到 60%-70% 以上。

混部肯定是有犧牲的，它對優(yōu)先級高的業(yè)務(wù)肯定會有影響，我們把影響做到了 5% 以內(nèi)，我們可以看到這兩條線，一個是混部集群，一個是非混部集，它的 RT 表現(xiàn)影響在 5% 以內(nèi)。

混部的核心技術(shù)

混部的核心技術(shù)一方面是調(diào)度。通過資源畫像，在競爭之前，盡量減少資源競爭的可能性。但競爭永遠會發(fā)生，因為調(diào)度是宏觀的數(shù)據(jù)。

微觀上，資源的使用其實是有局部競爭的，所以另一方面，我們在內(nèi)核上面做了很多的保障，在資源發(fā)生極端競爭的情況下，會優(yōu)先保障高優(yōu)先級任務(wù)，它被動但是延時非常低，毫秒級就可以做出反應(yīng)。

基于統(tǒng)一 QOS 的調(diào)度體系：

• 調(diào)度自身 SLO：在線，離線定義自身 SLO 以及和 0 層資源優(yōu)先級對應(yīng)映射。
• 資源優(yōu)先級定義：共同制定 0 層資源優(yōu)先級等級定義。
• 資源度量及控制：統(tǒng)一度量標準作為 0 層資源控制，調(diào)度本身不管是哪種使用資源的策略，但***必須能轉(zhuǎn)換成 0 層的標準度量單位。

日常的分時復(fù)用

我們很早就做了彈性的容量托管，但我們發(fā)現(xiàn)，只有真正把資源都混合在一起了，才可以把這個資源分時復(fù)用的價值放大出來，而這一部分主要節(jié)省的是內(nèi)存資源瓶頸問題。

大促分時復(fù)用

上圖中上面是我們的日常態(tài)，在大促的時候，1 小時之內(nèi)我們會直接切換成下面的狀態(tài)，直接把在線的業(yè)務(wù)、流量都放上來，部署起來形成 1 個大促狀態(tài)。這個大促支撐了 12 萬的交易。

實時的內(nèi)存超賣

其實在混部中，競爭***的并不是 CPU，因為 CPU 實際上是一個可壓縮資源，是有彈性的，但內(nèi)存是沒有彈性的，內(nèi)存一旦不足，就會 OOM。

這兩年大家為了性能的問題，以空間換性能，在內(nèi)存里放了很多東西，內(nèi)存資源非常緊張，所以我們會根據(jù)實時的內(nèi)存使用來調(diào)整內(nèi)存的使用水位，我們把這個叫內(nèi)存超賣技術(shù)。

在內(nèi)存這塊，目前還有一些***的研究方向，比如如何更好的管理 Pagecache 等。

存儲計算分離

存儲計算分離是我們做混部時遇到的***個問題，因為大數(shù)據(jù)需要很大的計算資源、需要很大的磁盤，而在線應(yīng)用需要的磁盤很小。

原先的時候我們都在一個物理機上，根本沒有辦法調(diào)度，所以我們把計算和存儲做了分離，把原來統(tǒng)一的資源拆分成了計算節(jié)點與存儲節(jié)點。

這樣就能更好的控制存儲的性能與容量問題，讓成本保持***，不過這個方法會對網(wǎng)絡(luò)有較大的依賴。

內(nèi)核隔離

我們最終形成了一整套混合云的體系。我們將所有的業(yè)務(wù)在上層進行混合部署，下層既可以是在線的獨立集群，也可以是混合部署的集群。

還可以是計算業(yè)務(wù)獨立的集群，甚至也可以是 ESC 上面的集群，公有云的這些集群，形成上圖的架構(gòu)體系，所有資源層都可以打通，形成混合云模式，共同來支撐起阿里巴巴的業(yè)務(wù)。當然最終的目標是完全轉(zhuǎn)化到公有云上。

云化的未來展望

目前我們研究的方向很多也很雜，文章上述提到了幾個階段：

• 微服務(wù)化，主要解決的是人與服務(wù)的協(xié)同。而最復(fù)雜的是服務(wù)與服務(wù)的協(xié)同，也就是我們常說的服務(wù)治理。
• 云化架構(gòu)我們認為是人與資源的協(xié)同，而最難的是資源和資源的協(xié)同，比如像單元化，混部等。
• 我個人認為未來的一個方向是業(yè)務(wù)與資源的協(xié)同，也就是用戶不再需要關(guān)注資源，關(guān)注運維，只要把業(yè)務(wù)要求以標準形式輸入就可以了，系統(tǒng)自動會以***的策略進行部署。要做到這些，可以采用業(yè)界炒得比較火的 Serverless 的模式，其中的關(guān)鍵是打通業(yè)務(wù)與資源中間的標準。

[[270859]]

呂奇，花名瀟謙，阿里高級技術(shù)專家。10 多年的老程序員，2014 年加入阿里巴巴，是阿里巴巴大規(guī)模混部及容器化的項目負責人，4 次參與雙 11 大促，目前主要負責阿里巴巴集團內(nèi)的規(guī)?；觳俊⑻摂M化、存儲與日志中心等。