《阿里巴巴運維中臺的演進與建設》要點：
本文介紹了阿里巴巴運維中臺的演進與建設，希望對您有用。如果有疑問，可以聯系我們。

作者簡介：

毛茂德

阿里巴巴 基礎架構事業群運維中臺負責人

花名如柏,現任阿里巴巴集團基礎架構事業群－運維中臺負責人, 主導架構設計高可靠、高并發、大規模的基礎運維平臺和應用運維平臺, 致力于打造行業級的基礎運維無人值守解決方案以及數據化、智能化運維解決方案,推動 DevOps 生態.

前言

本文來自于 GOPS 2017 深圳站的演講“阿里巴巴運維中臺的演進與建設”.

我所在的部門是阿里基礎架構事業群,負責阿里巴巴的 IDC 建設、網絡建設、基礎數據庫的運維,大數據運維,研發協同,應用運維等等都在我們這個部門里面.

我的團隊主要負責運維平臺和工具的建設,旨在提升業務交付的效率和運維的自動化、智能化.在去年我們團隊名字改成了“運維中臺”,名字的改變很重要,他讓我們的定位更加清晰,做事更聚焦和專注.

運維平臺建設已經很多年,產品比較多,下面我將介紹幾個比較重要的產品來呈現阿里運維中臺建設的過程.

一、運維基礎平臺——StarAgent

StarAgent 在阿里已經有五六年,甚至更早的時間.阿里所有的物理機、虛擬機以及容器都會裝這個 agent,StarAgent 是管理所有 agent 的系統,基本上要和機器交互都需要通過這個平臺.

StarAgent 是一個生態平臺,實際上不會做具體的業務,具體的業務還是通過各個業務平臺去實現的.它們要和服務器進行交互必須通過我們這個平臺.

例如,應用運維平臺——諾曼底也是通過 StarAgent 在機器上進行部署發布的.我們希望將 StarAgent 建設成一個平臺,而不是所有的業務都是我們來做的.

平臺化的項目是2015年底啟動的,在此之前機器上運行的?agent?所有的功能整個打包成一個可執行的程序,這導致了研發迭代速度非常緩慢,問題非常多.

我們曾經有一個功能花了一個多月時間開發了一個功能,開始上線,全網做灰度,將近一個時間等快灰度結束的時候,突然發現某些環境下這個功能有?bug,結果又用了一個月的時間回滾.

這個對我們士氣是非常傷的,三個月過去了什么業務結果都沒拿到.

平臺化的改造中,我們把各個業務的功能都變成一個個插件,可以插到這個平臺上來.平臺只負責最基本的插件維護的功能,以及命令執行的功能,僅此而已.監控、日志采集等功能都變成插件,而不需要都打包在一起.

目前我們平臺上已經有了將近90個插件,比如說監控、日志、安全、調度、采集、P2P?文件分發、配置管理類似?puppet,?saltstack?等等插件.

而且平臺化之前我們必須全網發布,插件化之后,我們可以選擇插件的發布范圍,開發迭代的速度也有了大幅度提升.

• 平臺化之前整個?agent?都需要放到裝機鏡像里,裝機鏡像測試也需要一個月時間,所以更新鏡像也非常繁瑣.
• 平臺化之后裝機鏡像里也只要裝基本的?agent core?就可以了,核心插件都可以裝機后第一次啟動時自動更新即可,這樣也不需要頻繁的更新裝機鏡像,core?的功能因為非常純粹簡單,core?穩定之后,更新的頻率自然就低到了極致.

StarAgent 平臺化之后的架構比較簡單,整個 agent 最核心的東西就是管理和運行這些插件,基于一個非常簡單的交互協議與插件通訊.只要實現這些接口就可以作為一個插件讓 agent 幫你去運維.

所以除了之前 StarAgent 的功能插件化外,我們收斂了機器上眾多的 agent,在這之前插件都是自己做一個運維系統,要管理自己的狀態,要進行版本的更新和迭代.

現在在統一的平臺上統一的進行管理、統一做變更的升級.除了節省運維資源外,同時也能收斂重復功能的 agent,從另外一個角度保證了服務器運維的安全.

1.1 StarAgent核心功能

StarAgent 核心功能就是一個命令的通道,它既可以同步執行任務又可以異步執行任務,還可以查詢任務狀態和插件管理.插件分為兩種,一種是靜態的,靜態的實際上就是腳本、命令之類的.

另一種動態的是一個常駐進程,必須常駐在系統里面.我們會守護這個進程,如果它掛了會重新拉起來,如果其占用內存、CPU 超過設定的范圍會刪掉它.整個協議是比較簡單的,使用起來耦合度也是比較低的.

1.2 StarAgent特性

StarAgent 系統從功能上來講是比較簡單的,我們其實是花了大量時間在做一些非功能上的東西.

例如,高可用、高并發、安全,還有自運維能力,即使是百萬級服務器的場景下,我們的運維人力投入可能幾乎為0,我們追求的就是無人值守的運維.

目前這套系統的執行成功率差不多有 99.995% 左右,由于執行量非常大,0.005% 失敗率的運維成本還是挺高的.我們花了大量的時間做容災和自恢復的工作.

前兩年支付寶官網癱瘓,經過這個事件我們開始做容災的演練.把網線拔了,看所有系統的反應,過兩個小時再把網線插上去,看這個系統是不是能自動恢復.

以前我們都是半夜三點起來去重啟服務器,經過自動化的運維,所有的系統斷網都可以自動恢復、服務器可以自動進行擴容,保證系統持續的可用性.

1.3 StarAgent 場景

現在的場景會貫穿整個物理機的生命周期,阿里巴巴在物理機裝機的過程中就會用到 StarAgent,從生產到下線整個過程都離不開.

應用運維方面,我們在做重啟、發布恢復等等,同時還有監控、數據采集及數據庫等方面.

StarAgent 是三層的架構,中央的一層,第二層是每個機房都有管控服務器,最下面一層就是每臺服務器安裝的 agent 及其插件.

agent 會先注冊到管控服務器然后上報自己的信息并且每隔一段時間上報自己的心跳.命令是從上往下的,是通過 API 去下發的.

例如,下發一萬臺服務器執行命令,所有的命令都是同樣的中央服務器,所以它是中央式的架構.

阿里現在有很多走國際化,在俄羅斯、美國、印尼等地收購很多公司,它們的機房也需要我們做運維.目前我們在做的就是去單中心走向多中心的架構.

比如說,在印度尼西亞的一個機房還需要回到中央服務器來再下發,這個路徑會非常曲折,我們需要做個多組型.

在國外的我們會多布一個中心,這樣的話在單元內可以自制,不需要跑到杭州或上海來再下發到國外機房.

1.4 StarAgent 指標

目前內部訪問量每天在一億多次,但是阿里的服務器還在不斷增長,而且隨著阿里云的業務逐步擴大,以及阿里本身業務的不斷壯大,我們不得不提前考慮未來三年的發展會不會成為瓶頸.

所以去年我們花了半年的時間在架構上做了比較大的升級,目前集群的QPS已經達到55萬次/分鐘,這個量實際上已經差不多可以支撐未來3年服務器的發展和業務的發展.

以前這些數據都沒有,我覺得做運維系統需要把度量這個事情做起來.

?

在架構里面有句話叫沒有度量就沒有改善,度量是非常重要的.如果產品的核心指標(穩定性、性能、內存占用等)沒有定出來,或者無法度量,怎樣去架構和優化系統就比較困難,無從下手.

產品的亮點、競爭力、差異性也無從談起.

實際上系統穩定性以前根本就沒有.一個系統指令發過去了就告訴你失敗了,不知道什么原因,根本沒有錯誤的分類.然后一堆人開始查問題,查半天發現這臺機器磁盤滿了.

對于這種方式,我們覺得是不可持續的.我們需要從日志和標準化等方面一定要說清楚系統本身到底有沒有問題.

對于第三方依賴,可能是數據庫、也可能是一個配置等等,一定要搞清楚第三方依賴的穩定性到底怎么樣.對于環境的問題,網絡是不是斷了,磁盤是不是滿了.

這些也都需要在錯誤碼日志里面體現出來,這樣才能從各個方面逐步完善系統的指標,否則是沒有辦法完成的.系統的穩定性非常重要,有了這些數據,系統就可以進行數據化運維.

1.5 StarAgent 插件系統

StarAgent 插件系統,協議很簡單.可實現啟動、停止,配置如何重新加載等.我們對 CPU 會做一些守護,同時會做一些一鍵部署的事情.

原來我們升級插件是非常多的,服務器數據很大,再加上插件數量和插件各種版本,這個量是非常巨大的.

以前全網升級插件差不多要六個小時,經過優化之后現在大約10分鐘就可以了.

二、文件分發系統——蜻蜓

對于全網都需要用到的,這些就不是一個個性化的需求,這些這插件是我們自己來開發.比如蜻蜓(P2P文件分發系統)就是我們自己開發的.

文件分發其實是我們做部署系統的優化時候去做的,當時比較糾結,是自己開發還是用現成的系統.我們對比了業界很多類似的技術.

比如?Facebook?的?wdt (https://github.com/facebook/wdt),Twitter?的 (?https://github.com/lg/murder?),百度的?Ginko?等等,還有包括亞馬遜?Apollo?里面的文件分發系統,它們那個和我們的有點不太一樣,他們的是基于 S3 做的.

我們發現他們各自或多或少的都有些問題,無法滿足我們多種場景下應用需求.這個產品可以不夸張的說已經做到行業第一.

蜻蜓系統是純碎的 P2P 的文件分發系統.在做?Docker?過程中,如果沒有系統解決這些問題,整個?Docker?化的進程就會受到影響.當到了一定量以后根本就支撐不了,所以直接把鏡像倉庫的協議全部都實現了一遍.

2.1 蜻蜓核心功能

P2P 的文件分發我們做了很多特性,包括多線程下載、一致性校驗以及白名單控制等.

有些業務對磁盤是非常敏感的,例如搜索類的業務,所以會要求在寫這個智能 IO 的時候會有些控制,我們會把這個參數調出來通過這個參數對磁盤進行管理.

一個 200M 的文件在傳輸的時候會變得比較小,網絡和傳輸速度都會得到優化.

2.2 蜻蜓業務指標

蜻蜓系統目前是一萬個客戶端同時下載 500M 的文件平均耗時 5s.阿里集團大部分的文件分發都統一用了這套系統.下載次數是 12萬/月到 3億/月.系統穩定性達6個9.也是自運維的系統.

使用蜻蜓系統和不用該系統進行對比可知,這個模式下載速度會快很多而且不會隨著并發數量上升而嚴重延時.

三、應用運維平臺——Normandy

Normandy 是運維整個阿里巴巴業務的 PaaS 平臺.這個平臺實際上提供三大功能,分別是基礎設施即代碼(Infrastructure as Code)、部署和應用運維支撐.

我們希望能夠通過代碼描述文件的形式把一個應用需要用到的所有資源,包括機載資源、服務器、網絡還有數據庫等都描述出來,這樣就可以能夠快速構建一個應用.

應用已經有了,如何把代碼部署到線上,讓其能夠對外提供服務,這就需要部署發布了.在發布部署方面我們做了無人監守的發布,我們和中間件等部分做了整合,只要代碼沒有出現線上的故障就可以自動發完.

如果出現故障發布就會停下來,此時需要人介入去判斷要不要作維穩.亞馬遜的發布系統阿波羅,一年的發布量差不多是五千萬,據說現在一天的發布量已經能達到50萬.

去年在這方面我們也做了很多工作,至少說這個發布系統不會因為業務發布次數比較大導致發布系統掛掉.

另外,現在整套系統已經將阿里巴巴的測試環境和線上環境全部打通,解決了線上系統和測試不統一的情況.

目前業務方有很多的平臺使用應用運維平臺和運維基礎平臺 StarAgent.從應用數量上來講,實際上也是最多的,大概 80% 的應用都基本集中在交易.

阿里云稍微有點特殊,有一半對 ECS 的運維,ECS 也是要做發布與運維,ECS 今年努力的方向要盡量做到不影響用戶.

以上的產品都是服務于整個阿里巴巴集團的,這些服務都是最基礎的,我們的核心能力基本都是通用的,不帶業務的特殊性,特殊性的功能可以在我們的平臺化上進行擴展.

這就是中臺的原義,中臺的好處就是讓業務能根據自己的特性在中臺上快速的發展,而不需要一桿子桶到最底層,同時中臺也沒有能力去幫助每個業務去實現所有的特性功能.

這個是整個做事方式的轉變,每層都想清楚自己的核心能力,做什么,不做什么同樣重要.

在滿足了集團業務運維的同時,我們這些產品也真正的在打磨極致產品特性,極致的穩定性、極致的性能、極致的體驗.

這樣能提升產品的競爭力,拉高進入門檻,光是一堆運維功能堆砌的產品是咩有靈魂的,也非常容易被復制.

我們的產品在今年就會完成單元化,國際化,云化,希望能成為云上有競爭力的運維產品.

文章來自微信公眾號：高效運維

轉載請注明本頁網址：
http://www.snjht.com/jiaocheng/2711.html