第四章 電商雲化，4.2 集團AliDocker化雙11總結(做者： 林軒、白慕、瀟謙)

4.2 集團AliDocker化雙11總結

前言

在基礎設施方面，今年雙11最大的變化是支撐雙11的全部交易核心應用都跑在了Docker容器中。幾十萬Docker容器撐起了雙11交易17.5萬筆每秒的下單峯值。衆所周知Docker技術這幾年大熱，但若是指望阿里這麼大致量的應用所有使用Docker，這可不是一朝一夕就能完成的事情。阿里的應用數量龐大，種類衆多，光兼容性的驗證沒個一、2年的時間沒人敢把核心應用放上去。所以雖然Docker能給研發和運維帶來的好處，做爲技術人員你們都心照不宣，可是想直接去使用，那面對Docker浪潮卻只能是坐觀弄潮者，徒有羨魚情。

 

1. T4和Docker的融合

所幸的是，這個情況在去年7月份有了改變，這事要從阿里內部的容器技術產品T4提及。T4是阿里在2011年的時候基於Linux Container(LXC)開發的容器技術基礎設施。從12年到15年3年時間裏用的應用愈來愈多，實際上已經覆蓋了電商領域大部分App。相比Docker的模式和理念，T4其實更適合阿里內部的運維現狀。T4是從阿里內部的資源管理和平常運維中土生土長出來的產品，在誕生的第一天就針對內部基礎設施、運維工具甚至是運維習慣作了不少特別的設計。T4在LXC容器的基礎上，對容器資源和各類統計的可見性作了不少卓有成效的隔離，使得在容器內部看到的資源就是分配給這個容器的資源，內部看到的負載就是這個容器的負載等等。同時在LXC以外還作了容器的磁盤空間配額限制和隔離，容器內看到的那塊磁盤大小就是建立容器時分配給他的磁盤配額大小。這樣在CPU、網絡、內存、磁盤等資源使用和統計監控上作到了容器內和物理機上基本沒有區別。原來跑在物理機，或者KVM、Xen中的應用，可以平滑無感知的遷移到T4中。當年從Xen、Kvm遷移到T4的過程當中，不少應用的開發者和Owner確實不知道何時完成遷移的，可能在某次常規的應用發佈中，後臺工具系統已經自動作完遷移了。甚至直到去年在和一個應用研發的溝通中，他堅信本身的應用是跑在KVM中的，咱們到後臺查了一下，其實已經在T4上了。

咱們在去年5月份接手了T4的整個維護工做，發現T4的功能和Docker很是類似，可是T4和Docker相比有一塊很大的短板就是沒有鏡像機制，再加上T4這種對人工運維的友好性，在長期使用中就出現了一個問題，就是應用的容器裏面遺留了愈來愈多的不一致，對運維的標準化形成了阻礙。好比有至關一部分應用，在遷移到另一臺物理機上後就無法運行了。由於從第一次上線到存活期間作的各類環境變動、軟件升級等，很難嚴格的記錄到發佈系統裏。另一個發現是T4的技術棧和Docker很是類似，都是基於linux內核的cgroup、namespace、chroot、bridge等機制運做起來的。T4使用了LXC，Docker的執行引擎也支持LXC，但神奇的是T4卻可以在阿里內部老版本的OS和內核上跑起來。所以直覺告訴我將T4和Docker結合起來應該是可行的。因而從去年6月份開始對這個方向作了探索，終於找到一個恰當的模式，對Docker和T4都作了一些修改整合後，將二者融合爲了一個產品，至關於既讓T4具有了Docker的鏡像能力，又讓Docker具有了T4對內部運維體系的友好性，而且可以運行在內部早期的AliOS5u和2.6內核上。這個產品在內部稱爲AliDocker，在去年8月份推出了第一個雛形版本。另外這個版本還解決了Docker當時很嚴重的一個問題，就是Daemon退出其上全部的容器都會退出，這一點在真正生產環境大規模部署時是沒法接受的。Docker官方直到1.10版本纔開始部分解決這個問題。咱們當時的Docker版本從1.5一直跟進到後來大規模部署的1.9版本，經過Docker的Daemon管控進程和容器的解耦，Daemon重啓後對以前運行容器的自動識別和從新接管，解決了這個問題。這樣Docker在阿里內部大規模應用就有了可能。

從這個版本發佈到可以替換T4大規模部署還走了很長的路，首先T4和Docker畢竟是兩個不一樣的產品，除了你們耳熟能詳的容器機制以外，其實還有很是多的細節和特性。爲了讓應用在遷移中無感知，AliDocker對原先T4容器的細節功能作了全面的兼容，同時對上層的運維繫統作了大量改造，使其支持Docker場景下的發佈和運維模式，從Docker鏡像構建到分發啓停、擴容遷移都作了完備的工具和流程支持。其次在T4到AliDocker切換的過程當中，咱們作了2者混跑的支持，也就是說同一臺物理機上能夠同時跑原來的T4容器和新的AliDocker容器，互不干擾而且能統一運維。由於衆多應用的實例是交錯部署在衆多物理機上的，同一個物理機上每每有十幾個不一樣應用的實例混跑。這種兼容機制就保證了不一樣應用能夠按各自的節奏逐步完成Docker化，而不須要在某個時間和空間作一刀切，避免了大規模升級Docker的過程當中沒必要要的應用騰挪和遷移。而後在咱們將AliDocker和T4功能徹底對齊，從實例級別到應用級別作了足夠的灰度後，推送了一個開關，使得從那一刻開始建立新T4實例時會自動建立爲AliDocker實例，從而完成了增量實例的切換。對於存量的T4實例，咱們選擇了一個完整的深圳交易單元，分批次作了批量切換，在切換期間若是發生大的問題，能夠把深圳單元的流量所有切換到上海。這一保障要得益於阿里的異地多活災備架構，對於這類底層基礎設施的升級可以提供理想的兜底方案，使咱們勇於放開手腳去作，而又能有效的控制風險。所幸在整個升級洗牌的過程當中，沒有動用到這個大殺器的功能，雖然出了一些小問題但都能及時修復，影響不大，也讓咱們的系統更加健壯，讓各個部門的人對交易核心流量切換到AliDocker這件事情更有信心。

 

2. 核心應用鏡像化

可是僅僅將運行容器從T4切換到Docker其實對咱們帶來的改變並不大。Docker真正的核心價值在於鏡像機制，以及鏡像機制帶來的研發與運維模式的變革。應用鏡像化大體來講有2種方式，一種是比較保守的方式，鏡像中只包含基礎環境，容器起來後，再登陸到容器中部署應用包。這種方式和原先的T4相似，鏡像化上不夠完全。爲了完全根治環境不一致的沉痾，從機制上杜絕非標準變動，讓每一個環境改變都沉澱下來，咱們採起了另外一種更激進的方式：鏡像中除了包含基礎環境外，還包含應用程序。應用新版本發佈時，直接銷燬原有的容器，用新版本的鏡像啓動新的容器提供服務。這樣任何在上一個容器中作的小動做都會隨着下一次發佈所有清洗掉，若是想要保留下來，就必須固化到應用的Dockerfile中。一個應用鏡像就表明了應用的全部依賴環境和當前版本。任什麼時候間任何地點將應用最新鏡像拉起，都能獲得和線上其餘實例一致的服務和行爲。咱們在推廣AliDocker的過程當中，一直和全部的應用方強調這個理念，也得到了你們的認同。

因而在今年5月底，咱們成立了專門的項目組，快速推動這個事情，目標是把雙11流量覆蓋的核心應用所有升級爲鏡像化模式的Docker應用。因爲咱們作到了運行態與T4保持一致，改造過程比較順利，但實際上線中也遇到了許多問題，其中最大的問題就是發佈與擴容速度。在鏡像化以前，應用新版本發佈時只須要分發應用包自己，而應用包通常只有幾百M的大小；切換到鏡像化模式以後，因爲鏡像包含了一個完整OS的lib庫以及應用依賴的rpm包，每每有幾個G的大小。應用一下感受發佈過程變得很是慢了，有時慢到難以忍受。同時這個變化對分發網絡和Docker鏡像倉庫也形成了很是大的壓力。在大規模發佈或擴容時，很容易把倉庫的下載源打掛，發佈失敗率居高不下，嚴重影響了整個發佈速度和體驗。爲了解決這個問題，咱們成立了緊急攻堅小組，集中精力對發佈擴容鏈條的各個環節作了大力優化。

首先，在存儲上，AliDocker鏡像倉庫的存儲直接使用了阿里雲的分佈式文件存儲產品OSS。阿里內部的線下開發測試環境和線上正式生產環境在網絡上是隔離的，而OSS產品在服務端作了線上和線下的打通。AliDocker除了用OSS解決了鏡像存儲的高可用問題之外，也藉助OSS的這個特性實現了線下push鏡像線上pull鏡像的功能。

其次，在分發架構上，因爲阿里在全球各地都有機房，大規模擴容時除了異地機房延遲增長以外，還有可能把長傳帶寬打滿，因此咱們在每一個地區搭建了鏡像mirror和超級緩存中心。在節點上下載鏡像的單個層時採用了相似BT(BitTorrent)的P2P鏈式分發技術，P2P分發中超級緩存中心做爲默認回源節點。這樣鏡像倉庫mirror加鏈式分發組成的多級細粒度分佈式分發網絡大大加快了分發速度，完全解決了服務端網絡和存儲的壓力。

最後，在發佈流程上，咱們針對內部發布系統作了多項優化。好比採起了預熱模式，線下構建好鏡像後就直接異步分發到線上各地域的mirror中，分批發布中第一批機器在執行時，第二批機器就提早去pull鏡像。另外把以前固定的分批發布策略改爲了智能滾動分批。每一個批次的機器發佈執行過程當中，每每總有幾臺長尾機器比較慢，若是等這些最慢的機器都執行完纔去執行下一批，在實例不少的時候會拖慢整個發佈的過程。改爲智能滾動分批後，在第一批發布完成應用owner確認沒有問題以後，後面批次的發佈不會等待長尾實例結束就會直接執行下一批，這樣大大提升了並行度，減小了發佈自動執行過程當中沒必要要的等待時間。

在全部這些優化以後，實例最多(近8千個實例)，發佈最慢的那個應用，總體發佈時間縮短到了原來的1/5，而且發佈成功率也大大提升，因分發問題帶來的穩定性也隨之消失。

 

3. 對Swarm的定製和優化

今年雙11的另一個變化是，65%的流量都跑在了雲上；交易主鏈路的核心應用在雲上和雲下都有實例。在AliDocker出現以前，雲上和非雲是兩套徹底不一樣的虛擬化機制，雲上是ECS中直接跑應用，雲下是物理機的T4容器中跑應用，應用下層的虛擬化機制不一樣也形成雲上和雲下只能採用兩套不一樣的運維發佈系統，讓整個運維體系比較痛苦和臃腫。AliDocker出現後，將這2者統一了起來，雲下在物理機上跑AliDocker容器，雲上在ECS上跑AliDocker容器，應用及上層運維繫統看到的都是AliDocker容器。統一的機制帶來更簡單的實現。咱們在這個時間點引入了Swarm來作Docker容器的管控。Swarm協議基本兼容daemon協議，只在很小的幾個點作了改動，能夠將一個物理機集羣當作一臺宿主機來操做，爲集羣背景下的測試和運維帶來了很是大的便捷。咱們對Swarm作了一些改造，使Swarm支持批量建立容器，功能相似後來Docker1.12版本的swarm模式引進的replica概念。由於咱們絕大多數應用最小化的部署實體都是對等部署的，多個容器中跑的是徹底相同的鏡像和配置，所以只是將Swarm中一次建立容器的請求處理過程，並行在多個物理機上執行就達到了目的。至於這多個物理機如何選出來，咱們現有的資源管理平臺有一套本身的調度系統，所以咱們修改了Swarm的調度部分直接對接到了咱們本身的調度系統上，同時對接了咱們內部的集中式ip資源管理系統。每一個容器的ip獨立於宿主機的ip，不須要端口映射，就能夠直接發佈到服務註冊中心，供其餘應用直接調用。

這個定製化的Swarm產品在內部稱爲爲AliSwarm，除了調度以外的基礎功能都與官方Swarm相同。可是隨着AliSwarm接入的節點愈來愈多，官方Swarm的實現部分暴露出了諸多性能問題。好比Swarm內部存在系統線程會隨鏈接數增加的問題，當node達到必定量時大批量增刪node很容易形成Swarm實例直接crash；在node節點數變多的狀況下，總會有那麼一部分node節點不那麼健康，在這種網絡頻繁時斷時續的極端狀況下，Swarm的內部處理存在鏈接泄露問題，會使系統資源消耗愈來愈大；每次大規模節點上下線時node列表會發生頻繁變化刷新，內部識別哪些是新增node哪些是刪除node時作的diff操做會大量消耗cpu；另外對單個容器的查詢須要遍歷全集羣的容器信息，當節點規模在1W以上時，這種遍歷也會消耗大量cpu，等等；AliSwarm在逐漸接入整個電商規模節點的過程當中逐步發現這些性能問題，並一一作了解決。官方Swarm單實例可以平穩運行的最大集羣規模，按以前官方公佈的數字是1000臺宿主機。AliSwarm在雙11以前實際線上運行的單實例集羣規模已經在3萬以上，而且32核機器cpu的load在5如下，在雙11建站期間可以支持併發3千個以上的實例同時擴容。

節點規模變大以後，每次swarm自身發佈初始化過程會持續幾分鐘，系統可用性下降。同時咱們有部分業務須要獨佔的隔離資源池，若是爲每一個資源池都搭建一套Swarm維護成本比較高。所以咱們開發了SwarmProxy系統，作了基於TLS證書管理多個集羣的功能。同時每一個集羣運行2個對等的實例，一主一備，同一時間，只有主實例提供服務。主實例發生故障時能夠自動切換到熱備實例。這樣AliSwarm自身版本升級時，就不須要等待新實例初始化完成才能提供服務，而是先讓舊實例繼續提供服務，新實例啓動初始化完成後替換原來的熱備實例，成爲新的熱備，而後再作一次主備切換完成升級。這個主備切換過程會根據版本號大小和新版本初始化完成狀況自動執行，毫秒級完成。

 

4. 阿里中間件（Aliware）Docker化

除了交易應用外，今年咱們還推動了阿里中間件(Aliware)的Docker化，中間件相對於應用來講主要區別是有狀態、性能敏感、資源需求差別大、有個性化的運維標準等。中間件的狀態通過分析主要分爲三類：數據狀態、配置狀態、運行時狀態。針對數據狀態，咱們經過掛載Volume的方式，讓全部須要持久化的數據，所有直接落到宿主機的指定目錄中，以保證容器升級或變動後，數據可以不丟失；針對配置狀態，咱們採用了鏡像和配置分離的方式，容器啓動時，會根據啓動參數或環境變量去配置中心動態獲取運行時配置，經過這種方式能夠實如今任何環境下均使用相同的鏡像，以減小鏡像構建和傳輸的成本；針對運行時狀態，咱們制定了中間件鏡像標準和運行時管控標準，對容器進行操做的時候容器管控平臺會按照既定標準和流程進行，以保證整個過程平滑和可以被容器內應用感知並進行相關前置操做。

阿里中間件(Aliware)做爲集團內的P0級基礎服務，對性能的要求近乎苛刻，咱們在Docker化之初就定下目標，性能損失須要控制在3~5%以內。影響中間件性能的因素主要有網絡、CPU、內存、磁盤、內核、依賴包等，因此在實施過程當中，咱們對每一款中間件均進行了詳細的性能測試，測試場景涵蓋物理機+Docker、物理機+VM+Docker、物理機+T4，通過測試、內核、網絡、容器、中間件等多個團隊的通力合做，最終全部中間件Docker化後的性能均達到預期，並沉澱出了Docker化場景下針對不一樣性能影響因素的調優方案和策略。

阿里中間件(Aliware)對資源的訴求也比較多樣，好比消息中間件對網絡、磁盤需求較大；緩存中間件對內存需求較大；數據中間件強依賴CPU性能等，針對這種狀況咱們在資源調度上會均衡各產品需求，讓有不一樣資源訴求的中間件共享宿主機資源，以保證宿主機的資源使用率保持在合理的範圍，既節約了成本，又提高了中間件的穩定性和性能表現。在雙11大促備戰期間，咱們還對Docker化的中間件進行了資源的精細化調整，測試並評估了超線程（HT）帶來的影響，並對強依賴CPU的中間件進行了調核，以規避資源爭搶風險，進一步提升了中間件的穩定性，此外，咱們還具有Docker化中間件資源動態調整的能力，好比雙11大促前，咱們能夠動態爲數據中間件增長CPU配額、爲消息中間件增長磁盤配額。

在阿里集團內部，中間件(Aliware)每一款產品都有本身的個性化運維需求和流程，在這樣的背景下，咱們以AliDocker爲推手，完成了中間件統一運維標準和體系的創建，併產出了中間件Caas平臺和場景化運維平臺，中間件運維效率、資源管理效率均獲得了極大提高，雙11前咱們實現了全部中間件的Docker化改造，並承擔了線上20%-100%的流量，按計劃到財年末咱們將實現中間件的100%Docker化。

在今年剛剛過去的雙11中，從AliDocker引擎到上層運維部署體系都經歷了一次大考，最終交易全鏈路全部核心應用所有在AliDocker容器中圓滿完成了1207億成交額的答卷，也證實了AliDocker技術體系在電商交易級別的大規模應用中可以擔負重任！