云化的背景

思路 1：通過云的彈性

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

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

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

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

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

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

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

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

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

因?yàn)槊恳粋€(gè)單元的集群能力不一樣，流量不一樣，所以這里面還有很多的策略。

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

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

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

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

2013 年的時(shí)候，杭州做了 2 個(gè)同城單元的驗(yàn)證；2014 年的時(shí)候，我們?cè)谏虾：秃贾葜g做了 2 個(gè)單元。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

其實(shí)在混部中，競(jìng)爭(zhēng)最大的并不是 CPU，因?yàn)?CPU 實(shí)際上是一個(gè)可壓縮資源，是有彈性的，但內(nèi)存是沒有彈性的，內(nèi)存一旦不足，就會(huì) OOM。

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

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

存儲(chǔ)計(jì)算分離是我們做混部時(shí)遇到的第一個(gè)問題，因?yàn)榇髷?shù)據(jù)需要很大的計(jì)算資源、需要很大的磁盤，而在線應(yīng)用需要的磁盤很小。

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

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

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

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

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