將雙11新增IT成本降低一半 阿里是咋做的？

  有人做過計算，當10萬臺伺服器，利用率從28%提升到40%，就能節省出3萬臺機器。假設一臺機器的成本為2萬元，那麼節約的成本就有6個億。這是個驚人的數字，意味著在龐大的資料中心伺服器規模下，平均利用率每提高一點，就會帶來非常可觀的成本節約。

　　有人說，技術是商業需求倒逼出來的。其實，不論怎麼說，技術創新的目的雖然不全是，但有幾個方面是確定的，那就是滿足業務需要，同時提升效率和降低成本，這方面，阿里巴巴就是一個典型的案例。

　　早期的阿里巴巴去IOE，不僅是成本問題，同時還是因為Oracle解決不了每秒十幾萬TPS的業務需求，如何做到更高的TPS，怎樣實現低成本，這是擺在當時阿里巴巴眾多工程師面前的問題。

　　最近剛結束的天貓2017雙11，資料顯示，成交總額1682億，交易峰值32.5萬筆/秒，支付峰值25.6萬筆/秒，比去年增長超1.1倍，再次重新整理全球紀錄。

　　但鮮為人知的是，今年的雙11，雖然資料再度重新整理全球記錄，但對阿里巴巴而言，新增IT資源需求卻實打實的削減了一半。這是如何做到的?一番探究下來，在阿里巴巴雲化戰略中，基於阿里雲混合雲彈效能力之上的幾項重大技術點突破，包括資源Pouch容器化、統一排程、儲存計算分離和混部技術功不可沒。

　　正是這些技術點上的突破讓阿里巴巴整體雲的彈效能力升級，資源利用率大幅提升，從而做到成本不斷下降。如通過混部技術，阿里巴巴可以在1個小時內，將離線計算任務的叢集拉起，投入到線上服務上支撐數萬筆的交易，整體節省30%的成本。

　　阿里巴巴雲化戰略，是阿里集團基礎設施近年來一直在努力的方向，其目的就是為了解決資源投入問題，在解決資源彈性投入基礎上，進一步提升彈性資源投入後的使用效率，從而可以帶來資源投入本身的節省。

　　其實不僅是阿里巴巴這麼幹，微軟，華為也都在推動全面雲化戰略，但阿里巴巴顯然在這方面走的要更快。

　　阿里巴巴雲化戰略歷史及相關技術點邏輯

　　據老魚瞭解，阿里巴巴雲化戰略大致分為三個階段：

　　第一階段，以往的雙11，沒有阿里雲時，每次都會要採購大量的機器，資源比較浪費;

　　第二階段，有了阿里雲後，每次雙11的前兩個月左右，在做容量規劃時就要考慮採用阿里雲的彈性資源，但資源佔用週期長，這個階段主要是依靠阿里雲的彈性資源來應付洪峰流量;

　　第三階段，即在現在有的混合雲架構下，利用阿里雲彈效能力的升級，快速排程用於計算任務的離線叢集彈性資源投入線上服務，多種任務混合部署，這意味著需要將資源使用和任務運維標準化，即全面Pouch容器化，彈性資源佔用週期大幅縮短;

　　在阿里巴巴集團業務全面雲化戰略中，排程技術是非常重要的一環，而其中的混部技術更是降低資料中心資源成本的核心祕密武器。但要想實現便捷排程，線上資源的Pouch容器化改造就在所難免。而混部技術的前提，必須是在線上資源Pouch容器化改造及Sigma排程系統的日趨完善下才能成為可能。

　　據瞭解，今年，阿里巴巴各BU線上系統都陸續進行Pouch化改造和接入到Sigma統一排程系統中來，數以萬計的線上業務伺服器不斷加入到Sigma資源池中，統一管理，資源共享，對業務遮蔽基礎設施複雜的細節，從而大幅提升效率和節省成本;為保證接入Sigma的業務能夠穩定高效，Sigma做了不少的優化。

　　細說阿里sigma排程系統

　　眾所周知，無論是什麼自動化排程的叢集管理系統都有一個共同的目標，那就是提高資料中心的機器利用率。

　　據Gartner的統計顯示，全球的伺服器利用率只有6%-12%。即使通過虛擬化技術優化，利用率還是隻有7%-17%。通過資源的精細化排程以及虛擬化的手段，讓不同服務共享資源，堆疊高密度部署，可以有效的提升資源利用率。

　　但上述基於資源和虛擬化技術的排程模式用在線上業務系統上存在問題。因為資源共享和高密部署會帶來各個層面的資源使用競爭，從而增加線上服務的延遲，尤其是長尾請求的延遲，這對時延要求較高的線上業務是無法接受的。但另一方面，近年來隨著大資料的普及，對實時性要求並不高的批量離線作業規模越來越大，在資源使用上，逐漸和線上業務的體量相當，甚至超過了線上業務。

　　於是阿里巴巴的工程師們很自然想到，將離線業務和線上業務混合部署在一起執行會怎樣?能否在犧牲一些離線作業延遲的情況下，充分利用機器資源，又不影響線上的響應時間?

　　阿里巴巴從2015年開始做了這個嘗試。在這之前，阿里內部針對離線和線上場景，分別各有一套排程系統： 從2010年開始建設的基於程式的離線資源排程系統Fuxi(伏羲)，和從2011年開始建設的基於Pouch容器的線上資源排程系統Sigma。

　　從2015年開始，阿里巴巴嘗試將延遲不敏感的批量離線計算任務和延遲敏感的線上服務部署到同一批機器上執行，讓線上服務用不完的資源充分被離線使用以提高機器的整體利用率。

　　據瞭解，這個方案經過2年多的試驗論證、架構調整和資源隔離優化，目前已經走向大規模生產，並已服務於電商核心應用和大資料計算服務ODPS業務。混布之後線上機器的平均資源利用率從之前的10%左右提高到了現在的40%以上，並且同時保證了線上服務的SLO目標。

　　而作為可以便捷進行排程的基礎，線上資源的容器化改造在所難免。

　　自研Pouch 資源全面容器化改造

　　阿里巴巴作為全球業務場景最複雜的網際網路服務提供商之一，其背後自然少不了容器技術的支撐。只不過阿里巴巴並沒有採用市面上的容器技術，而是選擇了自研。

　　Pouch，到過今年雲棲大會的人都不陌生，它就阿里巴巴自研並開源的容器技術。相比Docker、Rkt等容器技術， Pouch在容器生態中並不是一個創新者，但是阿里認為“只有Pouch更懂應用，更貼近場景”，專案名稱Pouch本意為育兒袋，也隱喻貼身呵護應用的意義。

　　關於容器技術的價值和在雲化戰略中的作用，相信不用多說也都瞭解，關於Pouch，此前已經有很多文章介紹，這裡就不在細說。重點說下可能大部分人不知道的，阿里巴巴資源Pouch容器化改造現狀。據老魚瞭解，目前在阿里的資料中心執行有數十萬個Pouch容器，且100%電商核心業務已通過Pouch容器化對外服務。

　　同時，老魚還了解到，Pouch團隊計劃在雙11後的《中國開源年會》上現場開放原始碼，同時將在2018年3月底釋出第一個大版本。

　　而正是在線上資源Pouch容器化改造及Sigma排程系統的日趨完善下， 混部技術在阿里巴巴的可能性才越來越大。

　　阿里混部技術克服的難點及成效

　　為了便於理解，這裡需要簡單介紹一下兩種常見的任務型別：離線計算和線上業務。通常來說離線的大部分是計算密集型業務，離線叢集的壓力水位較高，對延時不敏感，而線上業務恰恰相反，特別是電商金融類業務，平時壓力水位較低，但對延遲極為敏感。

　　在平時可以極大地提升伺服器資源利用率，在大促活動需要突增線上伺服器的時候，又可以通過線上服務佔用離線計算任務資源的方式，來頂住短暫的超高峰值壓力。阿里巴巴把這樣的技術稱之為混部。從阿里巴巴目前的進展來看，基本上也能達到節省30%以上的機器數。

　　2015年，阿里巴巴通過混部排程技術，嘗試將前文提到的大資料計算資源排程系統Fuxi(伏羲)， 和基於Pouch容器的線上服務資源排程系統Sigma，兩者無縫串接在了一起。而要實現全面的混部，需要克服諸如CPU、記憶體頻寬和IO等的資源隔離，儲存計算分離等技術難點。

　　面對這些技術難點，阿里巴巴的工程師又是如何做的?先說資源隔離，阿里巴巴首先從伺服器的核心層面，對CPU，記憶體，IO，網路等多方面進行優先順序的劃分，做到對相關任務的毫秒級自適性排程或限制，以保證高優先順序的任務不受影響。而對於儲存計算分離，則把資源分為計算節點和儲存節點兩大類，完全統一了異構機型。

　　在無數次的試驗論證、架構調整和技術優化，阿里巴巴混部技術通過了嚴格的落地驗證，並在2017年大規模走向生產，並服務於企業最核心的交易鏈路。

　　據老魚多方瞭解到的資料，在混部技術實施前的阿里業務情況是線上叢集的伺服器CPU利用率低，日常利用率10%。而在混部技術實施後， CPU利用率提升，試驗叢集可以達到40%以上。

　　在剛剛過去的雙11中，阿里巴巴成功地把線上服務叢集和計算任務叢集執行在了一起，約有1/5的流量跑在了這個混合叢集上面，線上服務的伺服器日均CPU利用率提升至40%以上，峰值更是超過60%，整體節省成本30%以上。當然CPU利用率僅僅是一項引數的提升，更多資料本文就不一一列舉。

　　最後，老魚還了解到，混部技術將是阿里巴巴未來的叢集常態，以後不再會有離線/線上叢集之分。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/11310314/viewspace-2154100/，如需轉載，請註明出處，否則將追究法律責任。