阿里系統軟件迎戰「雙11」超高流量峯值全紀錄

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

剛剛過去的 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%以上。

原文連接

相關文章
相關標籤/搜索