作者|阿里資源管理技術專家楊儀

剛剛過去的 2018 年天貓“雙11”，創下了全天 2135 億 GMV 的數字奇蹟，零點交易峰值比往年提升 50%，各項指標均創下歷史新高。

2018 年是“雙11”的第十年，也是阿里系統軟體事業部參與的第二個“雙11”，系統軟體是介於業務應用和 IDC、網路、伺服器之間的核心關鍵層，為阿里巴巴集團線上業務提供基礎的作業系統、資源排程、SRE、JVM 等領域重要的基礎設施。

經過兩年“雙11”的精心淬鍊，系統軟體事業部與其他兄弟 BU 並肩作戰，逐步提升了阿里巴巴在基礎軟體領域的技術深度。阿里系統軟體是如何應對“雙11”流量峰值的呢？以下為大家一一揭曉。

“雙11”面臨的挑戰

雙11的核心是穩定壓倒一切，如何確保各個系統在峰值流量下的穩定性成為重中之重，系統軟體作為阿里巴巴的基礎設施底盤，今年主要面臨如下挑戰：

• 在去年雙11的完美表現的基礎上，今年雙11的穩定性不容有失，從核心到業務層保障，所有基礎設施必須保障絕對穩定；
• 大量新技術如規模化混部演進給集團帶來技術進步的同時，給系統和業務帶來不確定的技術風險；
• 如何在保障業務穩定性的同時，確保成本最低，是業務給系統軟體提出的更高要求；

系統軟體雙11備戰回顧

雙11備戰之資源交付

面向終態的站點交付

眾所周知，阿里巴巴的交易系統採用了異地多活的災容架構，當大促來臨前，需要在多個地域快速交付多個站點，通過全鏈路壓測平臺進行站點能力驗證。藉助於阿里巴巴資源快速彈性的能力，從交付使用到站點壓測，需要在短短10多天時間內完成多個站點的快速交付，無疑是一個巨大的挑戰。

為了提升整體建站的效率，確保站點高質量交付，系統軟體建站團隊對建站鏈路進行了全面的方案優化和升級如下：

• 全生命週期業務叢集管控

  包括 0->1（建站）、1->N/N->1（彈性伸縮/快上快下）、1->0（站點下線）；彈性伸縮範圍包括接入層、中介軟體、Tair 及應用全鏈路。
• 無縫對接容量模型

  單元化應用分組自動識別，應用彈性結合預算產出容量模型，對接中介軟體等容量模型，交易筆數->建站範圍及資源需求。
• 規模化資源編排
  
基於 Sigma 的規模化場景資源編排，最小化資源碎片，節省資源，通過實際驗證，資源分配率達到 98%。
• 自動化業務迴歸
  各 BU 自動化業務迴歸，例如基於天啟/doom、全鏈路壓測、軍刀等。

資源運營降低大促成本

根據準確測算，2018年大促每萬筆交易成本比去年下降20%；這裡面除了混部技術的大規模運用、雲化等因素外，還需要在資源運營層面進行一系列優化，其中的重點就是打造一套資源全生命週期管理的資源運營平臺，實現資源快速交付和資源最大化利用。

• 資源交付體系建設
  在資源交付鏈路上，資源運營團隊對額度系統進行重構升級，將面向時間的額度系統升級為面向當前賬戶的額度體系，應用負責人可以自由地在應用之間進行額度轉移，極大地提升了資源交付效率；此外，我們基於一系列的容量規劃和演算法預測，實現了大量業務的分時複用，將大量不參與大促的業務的資源提前釋放，用於支撐大促需求。

基於系統化的資源運營方式，集團資源運營的效率和利用率大幅提升，有效地防止了資源洩露和資源閒置，真正實現了大促成本不增加，為阿里集團節省了億級別採購成本。

雙11備戰之排程備戰

大規模混部技術應用

2017年雙11，阿里巴巴的混部技術在大促零點成功得到驗證，今年雙11混部的量級擴大到去年的3倍；在這個大目標下，混部團隊對現有架構進行了升級，在離線排程器伏羲和線上排程器sigma之上演化出一個總體的資源協調者0層，主要承載離線和線上資源記賬、區分優先順序的資源分配和總體協調的作用，可以把它形象的看成是一個大的賬本，上面的每一條記錄便是某臺機器上cpu/mem/io資源如何劃分給線上和離線業務，從而解決混部環境線上和離混資源的資源分配問題。

在混部業務穩定性保障方面，通過對兩類資源（CPU和MEM）按優先順序劃分的策略進行使用，其中以CPU資源為例劃分為三個級別，分別為金牌，CPU採用綁核模式具有最高優排程搶佔優先順序；銀牌，線上和離線高優先順序任務使用，離線銀牌資源不會被線上任務驅趕，保障排程優先順序和穩定性；銅牌，離線大部分worker申請銅牌資源使用。線上S10和S20需要使用CPU時可以驅趕離線銅牌對CPU核的佔用，實現資源充足時離線成分用滿，資源緊張時線上能及時搶佔的效果。

得益於前文所述的新混部排程框架，0層和1層排程間的資源配合有了一個明顯提升，去年的混部方案中，0層只保留靜態的叢集或單機資源配比，並且比例生效都是通過外部人為設定，而今年0層精細化單機賬本之後，每臺單機的配比則交給fuxi和sigma自動調整，按照容器所需資源比例進行設定。藉助於資源配比的按需調整功能，快上快下也實現了完全自動化的流程驅動。

混部快上快下是指在大促過程中，離線快速地資源釋放給線上或線上快速給歸還資源給離線的過程；自動化流程完美的實現了規模化混部目標，通過完整鏈路優化，最終實現了快上2小時，快下1小時的時間目標，也正是如此快速的資源伸縮操作保障了離線業務在資源相對緊缺的情況下安全順滑支援規模性壓測及雙11大促的完整支援。

今年雙11，有超過50%的流量執行在混部叢集；其中離線上混部（即離線提供資源給線上交易使用）支撐了40%的交易流量；在離線混部（即線上出讓部分資源用於離線任務執行）一共部署約了數千臺機器資源，為離線業務團隊減少數千臺機器採購。

Sigma排程能力升級

sigma是阿里巴巴自研的資源排程器，排程引擎是Sigma排程的核心，排程引擎的優劣，直接決定了其排程的業務的穩定性。今年排程能力升級主要做了以下幾方面工作：

• 業務執行時保障
  今年排程引擎團隊首次提出了資源確定性的SLO目標，將業務方關心的資源爭搶、超賣、CPU核重疊等容器執行時的穩定作為第一優先順序任務解決，在確保核心應用CPU邏輯核不堆疊的前提下，滿足了同應用不同容器和同容器對端核爭搶的需求，從而提升了資源穩定性。
• 引擎升級
  新版Sigma 排程器在原有基礎上進行了重新設計和架構升級，相容開源kubernetes框架，在數萬筆交易容量叢集上得到了大規模驗證。
• Pouch容器
  今年雙11，超過10%的物理機上線了pouch開源回遷版本，為探索阿里內外使用同一個容器打下基礎。同時，容器團隊還在Containerd-1.0 方面做了大量的效能優化/鎖優化/定時任務CPU優化，確保容器執行時穩定。
• CpuShare精細化資源分配
  CpuShare是一種基於linux cgroup對應用的cpu和記憶體進行精細化的控制和使用的技術，雙11前線上資源池整體share容器數佔比10%，其中核⼼應⽤5%，次核⼼應⽤10%，非核⼼應⽤20%+。

大促雲化

大促雲化是指大促時通過短時間使用阿里雲的計算能力，大促峰值過後將資源釋放歸還給公共雲繼續售賣的一種資源使用方式。

大促雲化的本質是資源的雲化，包括計算資源、網路、IDC、伺服器全部基於阿里雲的底層技術，從2014年提出大促雲化後，大促雲化方案經過了多次升級改進，通過vpc網路打通雲上雲下互訪，實現大促過後直接釋放資源即可直接售賣，從而減少資源佔用時長和改造成本。

• 全量使用公共雲方案，網路層通過VPC方案實現公共雲環境與彈內環境互通；通過使用阿里雲的ECS buffer，減少交易的資源採購；
• 計算儲存分離，使用阿里雲的盤古做為遠端盤儲存，大大減小物理機本盤，降低了大促資源成本；
• 此外，在應用、中介軟體、資料庫層面大規模部署神龍雲伺服器，總體效果良好。

大規模計算儲存分離

2018年是計算儲存分離破局之年，基於盤古遠端盤，部署了數千臺線上宿主機，超過50%的叢集使用了儲存計算分離技術，這項技術有望大幅減少未來阿里集團在伺服器SSD盤的硬體成本投入。

雙11備戰之核心備戰

核心是系統執行的基礎，今年核心團隊的備戰主要集中在以下兩個方面：

• 4.9 版本核心部署
  Linus Torvalds在2016年12月11日釋出了Linux核心4.9的正式版本，由於4.9新核心修復了大量老核心已知bug，4.9版本的作業系統比目前版本相比穩定性更高，宕機率也有明顯下降；目前裝機量達到數十萬臺級別，雙11交易叢集約90%的交易部署在4.9核心環境，未來將繼續擴大新核心的升級。
• 混部環境核心調優
  離線和線上混部的叢集中，由於宿主機整體資源有限，如何避免離線任務的執行對線上任務造成影響，成為業界難題；今年混部實施以來，發現混部任務排程到線上宿主機後線上業務頻繁反饋容器及宿主機load高或CPU sys高的情況；經過核心團隊介入排查，釋出宿主機記憶體檔案快取過大，申請新記憶體時觸發整機記憶體直接回收，導致系統開銷大；優化思路：調整整機記憶體後臺回收值（調整記憶體水線，提高記憶體Normal Zone的LOW/HIGH水線），提前回收檔案快取頁面，避免核心進入直接回收流程。

補丁前：MIN=8G, LOW=10G, HIGH=12G，LOW與MIN之間只有2G,當應用分配大量記憶體時，kswap還沒來得及後臺回收，系統記憶體就低於8G,這時應用只能進入direct reclaim，直接去回收。

補丁後：MIN=8G,LOW=25G,HIGH=27G

雙11備戰之JVM備戰

JVM協程(wisp)

JVM協程今年部署範圍交易核心應用擴大到導購，大促期間整體某導購核心應用水位從去年30%提升到今年的60%，業務沒有新增機器。

ZenGC

• TenureAlloc

部分核心應用預設開啟ZenGC，GC暫停改善50%；

• GCIH2.0

核心應用部署GCIH2.0，在安全性和效能上進行了改進，GC暫停時間最多改進20+%。

• ElasticHeap動態堆記憶體

雙十一0點之前低流量時降低Java程序記憶體20%+，雙十一0點迅速恢復Java堆全量使用，峰值過後，繼續縮小Java堆，減少程序記憶體20%+，99%和最大暫停大幅好於CMS，CMS為G1的150%~5X。

• EarlyOldScavenge

在Lindorm Velocity證，大幅減少Concurrent GC從1天30+次，減少為1天1次，推算堆增長率減少95%以上。

未來展望

系統軟體為打造阿里巴巴高效能、低成本的基礎設施，在賦能業務發展、降低阿里巴巴資源執行成本方面實現了初步的技術積累，展望未來，系統軟體仍有巨大的發展空間，歡迎各路技術牛人加入系統軟體，一起打造阿里巴巴商業作業系統的核心軟體。