云化的背景

思路 1：通過云的彈性

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

多單元的架構(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ò)間的隔離性問題。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• 在線優(yōu)先級高：就像是石塊，且延時敏感，利用率不高，不可重跑。

• 離線優(yōu)先級低：就像水和沙子，且延時不敏感，利用率高， 可重跑。

• 低優(yōu)先級犧牲：當(dāng)在線不忙時，離線就搶占，反之則返還，甚至反哺。

• 優(yōu)先級互補(bǔ)性：是可以進(jìn)行混部，并帶來成本收益的兩個前提條件。

上圖是 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ù)一方面是調(diào)度。通過資源畫像，在競爭之前，盡量減少資源競爭的可能性。但競爭永遠(yuǎn)會發(fā)生，因為調(diào)度是宏觀的數(shù)據(jù)。

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

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

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

其實在混部中，競爭最大的并不是 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)用需要的磁盤很小。

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

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

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

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

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