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

作者簡介：

毛茂德

阿里巴巴 基礎(chǔ)架構(gòu)事業(yè)群運維中臺負(fù)責(zé)人

花名如柏,現(xiàn)任阿里巴巴集團(tuán)基礎(chǔ)架構(gòu)事業(yè)群－運維中臺負(fù)責(zé)人, 主導(dǎo)架構(gòu)設(shè)計高可靠、高并發(fā)、大規(guī)模的基礎(chǔ)運維平臺和應(yīng)用運維平臺, 致力于打造行業(yè)級的基礎(chǔ)運維無人值守解決方案以及數(shù)據(jù)化、智能化運維解決方案,推動 DevOps 生態(tài).

前言

本文來自于 GOPS 2017 深圳站的演講“阿里巴巴運維中臺的演進(jìn)與建設(shè)”.

我所在的部門是阿里基礎(chǔ)架構(gòu)事業(yè)群,負(fù)責(zé)阿里巴巴的 IDC 建設(shè)、網(wǎng)絡(luò)建設(shè)、基礎(chǔ)數(shù)據(jù)庫的運維,大數(shù)據(jù)運維,研發(fā)協(xié)同,應(yīng)用運維等等都在我們這個部門里面.

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

運維平臺建設(shè)已經(jīng)很多年,產(chǎn)品比較多,下面我將介紹幾個比較重要的產(chǎn)品來呈現(xiàn)阿里運維中臺建設(shè)的過程.

一、運維基礎(chǔ)平臺——StarAgent

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

StarAgent 是一個生態(tài)平臺,實際上不會做具體的業(yè)務(wù),具體的業(yè)務(wù)還是通過各個業(yè)務(wù)平臺去實現(xiàn)的.它們要和服務(wù)器進(jìn)行交互必須通過我們這個平臺.

例如,應(yīng)用運維平臺——諾曼底也是通過 StarAgent 在機器上進(jìn)行部署發(fā)布的.我們希望將 StarAgent 建設(shè)成一個平臺,而不是所有的業(yè)務(wù)都是我們來做的.

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

我們曾經(jīng)有一個功能花了一個多月時間開發(fā)了一個功能,開始上線,全網(wǎng)做灰度,將近一個時間等快灰度結(jié)束的時候,突然發(fā)現(xiàn)某些環(huán)境下這個功能有?bug,結(jié)果又用了一個月的時間回滾.

這個對我們士氣是非常傷的,三個月過去了什么業(yè)務(wù)結(jié)果都沒拿到.

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

目前我們平臺上已經(jīng)有了將近90個插件,比如說監(jiān)控、日志、安全、調(diào)度、采集、P2P?文件分發(fā)、配置管理類似?puppet,?saltstack?等等插件.

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

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

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

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

現(xiàn)在在統(tǒng)一的平臺上統(tǒng)一的進(jìn)行管理、統(tǒng)一做變更的升級.除了節(jié)省運維資源外,同時也能收斂重復(fù)功能的 agent,從另外一個角度保證了服務(wù)器運維的安全.

1.1 StarAgent核心功能

StarAgent 核心功能就是一個命令的通道,它既可以同步執(zhí)行任務(wù)又可以異步執(zhí)行任務(wù),還可以查詢?nèi)蝿?wù)狀態(tài)和插件管理.插件分為兩種,一種是靜態(tài)的,靜態(tài)的實際上就是腳本、命令之類的.

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

1.2 StarAgent特性

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

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

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

前兩年支付寶官網(wǎng)癱瘓,經(jīng)過這個事件我們開始做容災(zāi)的演練.把網(wǎng)線拔了,看所有系統(tǒng)的反應(yīng),過兩個小時再把網(wǎng)線插上去,看這個系統(tǒng)是不是能自動恢復(fù).

以前我們都是半夜三點起來去重啟服務(wù)器,經(jīng)過自動化的運維,所有的系統(tǒng)斷網(wǎng)都可以自動恢復(fù)、服務(wù)器可以自動進(jìn)行擴(kuò)容,保證系統(tǒng)持續(xù)的可用性.

1.3 StarAgent 場景

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

應(yīng)用運維方面,我們在做重啟、發(fā)布恢復(fù)等等,同時還有監(jiān)控、數(shù)據(jù)采集及數(shù)據(jù)庫等方面.

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

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

例如,下發(fā)一萬臺服務(wù)器執(zhí)行命令,所有的命令都是同樣的中央服務(wù)器,所以它是中央式的架構(gòu).

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

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

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

1.4 StarAgent 指標(biāo)

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

所以去年我們花了半年的時間在架構(gòu)上做了比較大的升級,目前集群的QPS已經(jīng)達(dá)到55萬次/分鐘,這個量實際上已經(jīng)差不多可以支撐未來3年服務(wù)器的發(fā)展和業(yè)務(wù)的發(fā)展.

以前這些數(shù)據(jù)都沒有,我覺得做運維系統(tǒng)需要把度量這個事情做起來.

?

在架構(gòu)里面有句話叫沒有度量就沒有改善,度量是非常重要的.如果產(chǎn)品的核心指標(biāo)(穩(wěn)定性、性能、內(nèi)存占用等)沒有定出來,或者無法度量,怎樣去架構(gòu)和優(yōu)化系統(tǒng)就比較困難,無從下手.

產(chǎn)品的亮點、競爭力、差異性也無從談起.

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

對于這種方式,我們覺得是不可持續(xù)的.我們需要從日志和標(biāo)準(zhǔn)化等方面一定要說清楚系統(tǒng)本身到底有沒有問題.

對于第三方依賴,可能是數(shù)據(jù)庫、也可能是一個配置等等,一定要搞清楚第三方依賴的穩(wěn)定性到底怎么樣.對于環(huán)境的問題,網(wǎng)絡(luò)是不是斷了,磁盤是不是滿了.

這些也都需要在錯誤碼日志里面體現(xiàn)出來,這樣才能從各個方面逐步完善系統(tǒng)的指標(biāo),否則是沒有辦法完成的.系統(tǒng)的穩(wěn)定性非常重要,有了這些數(shù)據(jù),系統(tǒng)就可以進(jìn)行數(shù)據(jù)化運維.

1.5 StarAgent 插件系統(tǒng)

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

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

以前全網(wǎng)升級插件差不多要六個小時,經(jīng)過優(yōu)化之后現(xiàn)在大約10分鐘就可以了.

二、文件分發(fā)系統(tǒng)——蜻蜓

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

文件分發(fā)其實是我們做部署系統(tǒng)的優(yōu)化時候去做的,當(dāng)時比較糾結(jié),是自己開發(fā)還是用現(xiàn)成的系統(tǒng).我們對比了業(yè)界很多類似的技術(shù).

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

我們發(fā)現(xiàn)他們各自或多或少的都有些問題,無法滿足我們多種場景下應(yīng)用需求.這個產(chǎn)品可以不夸張的說已經(jīng)做到行業(yè)第一.

蜻蜓系統(tǒng)是純碎的 P2P 的文件分發(fā)系統(tǒng).在做?Docker?過程中,如果沒有系統(tǒng)解決這些問題,整個?Docker?化的進(jìn)程就會受到影響.當(dāng)?shù)搅艘欢恳院蟾揪椭尾涣?所以直接把鏡像倉庫的協(xié)議全部都實現(xiàn)了一遍.

2.1 蜻蜓核心功能

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

有些業(yè)務(wù)對磁盤是非常敏感的,例如搜索類的業(yè)務(wù),所以會要求在寫這個智能 IO 的時候會有些控制,我們會把這個參數(shù)調(diào)出來通過這個參數(shù)對磁盤進(jìn)行管理.

一個 200M 的文件在傳輸?shù)臅r候會變得比較小,網(wǎng)絡(luò)和傳輸速度都會得到優(yōu)化.

2.2 蜻蜓業(yè)務(wù)指標(biāo)

蜻蜓系統(tǒng)目前是一萬個客戶端同時下載 500M 的文件平均耗時 5s.阿里集團(tuán)大部分的文件分發(fā)都統(tǒng)一用了這套系統(tǒng).下載次數(shù)是 12萬/月到 3億/月.系統(tǒng)穩(wěn)定性達(dá)6個9.也是自運維的系統(tǒng).

使用蜻蜓系統(tǒng)和不用該系統(tǒng)進(jìn)行對比可知,這個模式下載速度會快很多而且不會隨著并發(fā)數(shù)量上升而嚴(yán)重延時.

三、應(yīng)用運維平臺——Normandy

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

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

應(yīng)用已經(jīng)有了,如何把代碼部署到線上,讓其能夠?qū)ν馓峁┓?wù),這就需要部署發(fā)布了.在發(fā)布部署方面我們做了無人監(jiān)守的發(fā)布,我們和中間件等部分做了整合,只要代碼沒有出現(xiàn)線上的故障就可以自動發(fā)完.

如果出現(xiàn)故障發(fā)布就會停下來,此時需要人介入去判斷要不要作維穩(wěn).亞馬遜的發(fā)布系統(tǒng)阿波羅,一年的發(fā)布量差不多是五千萬,據(jù)說現(xiàn)在一天的發(fā)布量已經(jīng)能達(dá)到50萬.

去年在這方面我們也做了很多工作,至少說這個發(fā)布系統(tǒng)不會因為業(yè)務(wù)發(fā)布次數(shù)比較大導(dǎo)致發(fā)布系統(tǒng)掛掉.

另外,現(xiàn)在整套系統(tǒng)已經(jīng)將阿里巴巴的測試環(huán)境和線上環(huán)境全部打通,解決了線上系統(tǒng)和測試不統(tǒng)一的情況.

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

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

以上的產(chǎn)品都是服務(wù)于整個阿里巴巴集團(tuán)的,這些服務(wù)都是最基礎(chǔ)的,我們的核心能力基本都是通用的,不帶業(yè)務(wù)的特殊性,特殊性的功能可以在我們的平臺化上進(jìn)行擴(kuò)展.

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

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

在滿足了集團(tuán)業(yè)務(wù)運維的同時,我們這些產(chǎn)品也真正的在打磨極致產(chǎn)品特性,極致的穩(wěn)定性、極致的性能、極致的體驗.

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

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

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

轉(zhuǎn)載請注明本頁網(wǎng)址：
http://www.fzlkiss.com/jiaocheng/2711.html