2020年，機(jī)器上線需要在八個(gè)服務(wù)間反復(fù)橫跳，而且全程手動(dòng)操作。伴隨滴滴業(yè)務(wù)規(guī)模上云，彈性云新增大量物理機(jī)，上線操作至少有百次，這時(shí)暴露了一個(gè)問題：如果按這個(gè)速度上線機(jī)器，需要大量人力投入到上機(jī)器中。因此，彈性云急需一個(gè)平臺(tái)來管理宿主的上下線。

圖片

從無到有

DevOps，標(biāo)準(zhǔn)先行

在 DevOps 實(shí)踐中，標(biāo)準(zhǔn)化是非常重要的一環(huán)。彈性云的所有機(jī)器都是圍繞服務(wù)樹管理的。由于之前是由人工管理，彈性云機(jī)器在服務(wù)樹上的掛載情況非常混亂。因此，為了機(jī)器管理更標(biāo)準(zhǔn)，彈性云首先定義了服務(wù)樹節(jié)點(diǎn)標(biāo)準(zhǔn)和規(guī)范，將宿主機(jī)生命周期與服務(wù)樹節(jié)點(diǎn)進(jìn)行關(guān)聯(lián)。具體而言：

• 機(jī)器上線：機(jī)器由 backup 節(jié)點(diǎn)掛載到 kube-node-init 節(jié)點(diǎn)初始化，然后掛載到線上 kube-node 節(jié)點(diǎn)進(jìn)行報(bào)警關(guān)聯(lián)；
• 機(jī)器維修：線上機(jī)器掛載到 maintain 節(jié)點(diǎn)進(jìn)行維修，維修完成掛載 kube-node-init 節(jié)點(diǎn)進(jìn)行上線；
• 機(jī)器下線：容器漂移后，線上機(jī)器掛載到 pre-offline.backup 節(jié)點(diǎn)進(jìn)行關(guān)機(jī)退換。 

圖片

流程拆解，需求分析

標(biāo)準(zhǔn)定義好后，就是對(duì)平臺(tái)需求進(jìn)行分析，我們首先將宿主機(jī)上線、下線和維修的流程進(jìn)行拆解，如下圖所示：  

圖片

通過分析拆解后的流程，我們得出機(jī)器管理平臺(tái)至少需要具備以下功能：

• 整個(gè)流程耗時(shí)較長(zhǎng)且為流式任務(wù)，所以任務(wù)需要異步執(zhí)行。
• 平臺(tái)依賴許多第三方服務(wù)，需要支持跳過、重試、暫停等功能，以靈活應(yīng)對(duì)下游異常場(chǎng)景。
• 各流程之間有重復(fù)的步驟，步驟需要能被自由組合，以提升程序的靈活性。
• 按照 double-check 原則，任務(wù)需要以工單形式展現(xiàn)。

架構(gòu)設(shè)計(jì)，代碼開發(fā)

在軟件開發(fā)中，程序分層是一種常見的軟件架構(gòu)模式，它可以使軟件系統(tǒng)更模塊化、可擴(kuò)展和易于維護(hù)。需求明確后就可以進(jìn)入開發(fā)流程，從平臺(tái)的產(chǎn)品形態(tài)來看，平臺(tái)將來的使用流程是：用戶創(chuàng)建工單，審批通過后用戶執(zhí)行工單，程序感知到執(zhí)行動(dòng)作，執(zhí)行任務(wù)，程序?qū)崟r(shí)反饋任務(wù)進(jìn)度，任務(wù)異常時(shí)通知用戶，用戶介入處理，任務(wù)執(zhí)行完成后，工單結(jié)束。因此，平臺(tái)可以分成4層：

• 準(zhǔn)入層：用戶訪問控制，機(jī)器準(zhǔn)入控制。
• 控制層：工單控制，工單創(chuàng)建、執(zhí)行、關(guān)閉等。
• 調(diào)度層：任務(wù)調(diào)度、分發(fā)。
• 執(zhí)行層：組合步驟，執(zhí)行任務(wù)，反饋狀態(tài)。

組內(nèi)服務(wù)大多由 go 語言開發(fā)，所以此次開發(fā)也選擇了 go 語言。準(zhǔn)入層、控制層可以使用常見的 web 框架，調(diào)度層和執(zhí)行層需要一個(gè)異步任務(wù)調(diào)度框架。

在 go 語言中，優(yōu)秀的 web 框架很多，但是調(diào)度框架卻少得可憐。在對(duì)比了幾個(gè)框架后，最終選擇了 star 最多的異步任務(wù)框架 machinery。但是在使用過程中發(fā)現(xiàn)，雖然 machinery 支持任務(wù)流、任務(wù)重試等功能，但是對(duì)任務(wù)暫停、跳過等功能缺乏支持，需要再封裝一些功能。在經(jīng)歷了一段時(shí)間的嘗試后，我發(fā)現(xiàn)讀代碼比寫代碼要難上許多，再加上 go 原生對(duì)并發(fā)和異步支持比較好，最終決定調(diào)度層還是自己實(shí)現(xiàn)一個(gè)。雖然最終的開發(fā)周期有所加長(zhǎng)，但是程序的可維護(hù)性和可擴(kuò)展性會(huì)更好些。就這樣，第一版宿主生命周期管理服務(wù) (mmachine) 在 2 個(gè)月后上線了。  

圖片

宿主下線，維修

在第一版宿主生命周期管理中只上線了機(jī)器上線的功能，基本上實(shí)現(xiàn)了機(jī)器上線由人工到無人值守的轉(zhuǎn)變，但是機(jī)器的下線，維修還是由人工支持。

由于歷史原因，彈性云部分服務(wù)間通過容器 IP 進(jìn)行通信，所以部分容器無法變 IP 漂移，在機(jī)器下線時(shí)很難把機(jī)器上的容器漂空。人工下線時(shí)會(huì)把可漂容器漂移走，不可漂容器在聯(lián)系業(yè)務(wù)側(cè)進(jìn)行服務(wù)遷移，從經(jīng)驗(yàn)來看，人工 push 業(yè)務(wù)服務(wù)遷移都要花費(fèi)很長(zhǎng)時(shí)間，如果通過程序來 push，那效果比人工也不會(huì)好太多。

那么一臺(tái)機(jī)器，要達(dá)到什么狀態(tài)，就認(rèn)為這個(gè)機(jī)器可以下線且不會(huì)對(duì)在線業(yè)務(wù)造成影響呢？于是我們定義了一個(gè)新的標(biāo)準(zhǔn)-1、2、10原則。在機(jī)器下線時(shí)，對(duì)于未漂移容器的集群進(jìn)行反查：

• 當(dāng)機(jī)器存在副本數(shù)小于5且非 running 容器數(shù)大于1的集群，機(jī)器不可被下線；
• 當(dāng)機(jī)器存在副本數(shù)大于5小于20且非 running 容器數(shù)大于2的集群，機(jī)器不可被下線；
• 當(dāng)機(jī)器存在副本數(shù)大于20個(gè)且非 running 容器數(shù)大于總副本數(shù)10%的集群，機(jī)器不可被下線。

機(jī)器下線時(shí)，首先對(duì)機(jī)器上的容器進(jìn)行漂移，在正式下線前對(duì)機(jī)器進(jìn)行兜底檢查，在不打破1、2、10原則的前提下，彈性云會(huì)對(duì)機(jī)器進(jìn)行關(guān)機(jī)操作。

得益于調(diào)度器設(shè)計(jì)的靈活性，將機(jī)器下線和機(jī)器上線的步驟整合后就成為了機(jī)器維修的流程（下線-報(bào)修-上線），而且機(jī)器維修需操作的機(jī)器比較明確所以自動(dòng)化程度也相對(duì)較高，幾乎不需要人工介入處理，具體策略如下：

• 報(bào)修：周一至周五每個(gè)機(jī)房報(bào)修 1 臺(tái)機(jī)器。
• 上線：每周一、三、五掃描維修完成機(jī)器，上線機(jī)器。

效率提升

在第一階段彈性云完成了宿主生命周期管理服務(wù)(mmachine)從0到1的建設(shè)，機(jī)器上線耗時(shí)也從天級(jí)別縮短到小時(shí)級(jí)別，但是在服務(wù)使用過程中我們發(fā)現(xiàn)服務(wù)還有很多可優(yōu)化點(diǎn)。

上線流程優(yōu)化

在第一版的機(jī)器上線流程中，所有機(jī)器都在一個(gè)工單中。然而，一臺(tái)機(jī)器上線失敗將會(huì)影響整個(gè)工單的進(jìn)度。例如，如果在上線 100 臺(tái)機(jī)器時(shí)，有1臺(tái)機(jī)器重裝失敗，那么其他 99 臺(tái)機(jī)器必須等失敗機(jī)器修復(fù)完成才能繼續(xù)上線。這嚴(yán)重影響了機(jī)器上線的效率。實(shí)際上，機(jī)器上線并沒有相互依賴性，因此可以將上線流程由串行改為并行，以大大縮短單臺(tái)機(jī)器的上線時(shí)間。因此，我們重新設(shè)計(jì)了上線工單，以減少機(jī)器相互影響所帶來的時(shí)間消耗。

然而，如果將上線流程改為并行，那么下游服務(wù)也需要支持并行。但在重構(gòu)過程中，我們發(fā)現(xiàn)有兩個(gè)關(guān)鍵點(diǎn)無法并行處理：

• 機(jī)器上線需要進(jìn)行重裝，而重裝操作必須在所有機(jī)器都完成后才能結(jié)單。
• 上線依賴部署系統(tǒng)來初始化腳本，而部署系統(tǒng)不支持單模塊的并發(fā)操作。

因此，我們與系統(tǒng)部門合作，將每臺(tái)機(jī)器的重裝狀態(tài)暴露出來，并將初始化腳本由部署系統(tǒng)改為使用 Zeus 執(zhí)行，解決了下游無法并行處理的問題，并將上線流程升級(jí)為每臺(tái)宿主對(duì)應(yīng)一個(gè)任務(wù)流，各個(gè)任務(wù)流之間相互獨(dú)立，經(jīng)過優(yōu)化后，彈性云的宿主上線耗時(shí)由之前的小時(shí)級(jí)縮短到分鐘級(jí)。

備機(jī)管理

雖然機(jī)器上線的流程得到了極大的縮短，但在真實(shí)機(jī)器交付的過程中，機(jī)器上線只是整個(gè)交付過程中的一步。從發(fā)現(xiàn)資源不足到機(jī)器上到線上的完整流程包括以下幾個(gè)步驟："資源不足->申請(qǐng)機(jī)器->交付機(jī)器->重裝機(jī)器->上線->調(diào)度容器"。當(dāng)線上流量突增時(shí)，通過這個(gè)流程補(bǔ)充機(jī)器無異于遠(yuǎn)水救近火。然而，從彈性云的視角來看，交付流程可以簡(jiǎn)化為"資源不足->加入資源->調(diào)度容器"，只要能提前完成"加入資源"這一步，就能實(shí)現(xiàn)分鐘級(jí)的資源交付。

通過分析，我們發(fā)現(xiàn)系統(tǒng)部門有部分用于日常資源交付的備機(jī)。同時(shí)，彈性云的離線集群計(jì)算資源相對(duì)緊缺。離線集群在彈性云中屬于隔離集群，而隔離集群和公共集群的本質(zhì)是通過 Kubernetes 的 taint 特性來控制的。如果備機(jī)一直運(yùn)行在離線隔離集群中，當(dāng)線上資源不足時(shí)，只需移除備機(jī)上的 taint，即可將其加入公共集群，從而實(shí)現(xiàn)分鐘級(jí)的資源交付。此外，離線容器對(duì)穩(wěn)定性要求不高，因此當(dāng)備機(jī)需要用于非彈性云業(yè)務(wù)線交付時(shí)也可以快速退回。因此，彈性云與系統(tǒng)部門合作開發(fā)了備機(jī)管理模塊，具體功能如下：

• 自動(dòng)上線：當(dāng)備機(jī)交付到彈性云備機(jī)池后，它們會(huì)被自動(dòng)上線到離線資源池。離線服務(wù)檢測(cè)到有空閑容量自動(dòng)擴(kuò)容服務(wù)。
• 快速補(bǔ)充：當(dāng)線上資源不足時(shí)，備機(jī)管理模塊通過修改 taint 將機(jī)器轉(zhuǎn)移到彈性云的公共資源池中。
• 快速退還：當(dāng)系統(tǒng)部門需要備機(jī)時(shí)，可以快速縮容離線服務(wù)并將機(jī)器退回。

通過這種方式，彈性云的容量得到了保障，公司的備機(jī)池得到了充分利用，備機(jī)的利用率也得到了提升。

云上管理

隨著云原生在公司的開展，彈性云機(jī)器管理也迎來了新的挑戰(zhàn)。在 IDC 內(nèi)，物理機(jī)的單次上線數(shù)量通常不超過幾百臺(tái)，而云上的彈性伸縮每天需要擴(kuò)縮數(shù)千臺(tái)虛擬機(jī)。IDC 內(nèi)物理機(jī)的上線頻率、數(shù)量與云上存在顯著差異，而且云上資源用于承載核心鏈路的流量，因此擴(kuò)容效率也需要更快。隨著云上機(jī)器數(shù)量的增加，問題也逐漸暴露出來：

• 全流程服務(wù)有 8 個(gè)下游服務(wù)，而不同的下游服務(wù)具有不同的限速策略。
• 機(jī)器初始化時(shí)間過長(zhǎng)，單次初始化耗時(shí)超過 5 分鐘。
• 單次上線超過千臺(tái)機(jī)器時(shí)，工單可能會(huì)卡死。

為了解決限速的問題，根據(jù)不同限速策略全流程做了最大限度地兼容。例如：當(dāng)掛載的機(jī)器超過 200 臺(tái)時(shí)，全流程會(huì)將機(jī)器按每組 200 臺(tái)進(jìn)行分組掛載，并確保容器的檢查頻率不超過 10 毫秒/臺(tái)。

對(duì)于耗時(shí)問題，利用云上的鏡像功能，將需要部署的服務(wù)提前打入鏡像中。這樣在上線虛擬機(jī)時(shí)，無需對(duì)機(jī)器進(jìn)行初始化，大大縮短了機(jī)器上線的時(shí)間。然而，這種情況下的機(jī)器上線流程與之前完全不同。得益于調(diào)度器最初的設(shè)計(jì)便利性，我們?yōu)樵粕咸摂M機(jī)上線單獨(dú)增加了一套任務(wù)流，并將上線流程從 23 步精簡(jiǎn)到 10 步，大幅縮短了機(jī)器上線的時(shí)間。

圖片

對(duì)工單卡死的問題，通過排查發(fā)現(xiàn)瓶頸主要出現(xiàn)在 etcd 和 MySQL 上。在調(diào)度器設(shè)計(jì)之初，為了確保步驟執(zhí)行的連貫性，調(diào)度器會(huì)持續(xù)獲取未關(guān)閉的 MySQL 任務(wù)并嘗試在 etcd 上獲取鎖。已獲取到鎖的進(jìn)程執(zhí)行任務(wù)，未獲取到鎖的任務(wù)會(huì)不斷嘗試獲取。在高并發(fā)情況下，這種模式可能導(dǎo)致鎖丟失。因此，針對(duì)任務(wù)，我們?cè)跀?shù)據(jù)庫(kù)中新增了 isRunning 字段，用于判斷任務(wù)是否已在運(yùn)行。對(duì)正在運(yùn)行的任務(wù)，調(diào)度器不再獲取任務(wù)列表，也不再嘗試搶鎖。此外，我們對(duì)數(shù)據(jù)庫(kù)關(guān)鍵字段添加了索引以減少任務(wù)查詢耗費(fèi)的時(shí)間。雖然這樣做會(huì)損失部分任務(wù)執(zhí)行的連貫性，但卻換來了穩(wěn)定性的極大提升。通過一系列優(yōu)化措施，云上虛機(jī)的上線效率也提升到了1.5分鐘/千臺(tái)，滿足了日常彈性伸縮的需求。

成本優(yōu)化

彈性云成本主要集中在三部分，即服務(wù)器費(fèi)用、定價(jià)服務(wù)費(fèi)用和人力費(fèi)用。其中，服務(wù)器費(fèi)用每個(gè)月占了總成本的大部分。為了降低成本，彈性云可以采取容器治理和宿主縮容等措施來減少服務(wù)器定價(jià)支出，并降低對(duì)彈性云平臺(tái)服務(wù)器的投入。彈性云機(jī)器資源可分為三類：線上實(shí)際使用資源、線上 buffer 資源和低負(fù)載（閑置）資源。通過對(duì)這些資源進(jìn)行優(yōu)化，有效降低了彈性云機(jī)器方面的成本。

圖片

機(jī)器下線加速

經(jīng)過之前的優(yōu)化，彈性云機(jī)器的上線耗時(shí)已基本符合預(yù)期。由于機(jī)器下線和各業(yè)務(wù)的穩(wěn)定性相關(guān)，下線耗時(shí)仍處于一個(gè)較高的水位。隨著各類成本優(yōu)化項(xiàng)目的開展，彈性云在2023年預(yù)計(jì)退還大量機(jī)器，但根據(jù)以往的經(jīng)驗(yàn)來看，完全退還這些機(jī)器可能需要約2年時(shí)間，這個(gè)速度顯然無法滿足需求。機(jī)器下線耗時(shí)較長(zhǎng)的原因主要有兩個(gè)：

• 機(jī)器下線時(shí)需要按機(jī)器串行漂移容器，每臺(tái)宿主機(jī)器漂移容器約需10分鐘，每天最多可漂移50臺(tái)機(jī)器。
• 彈性云存在一些容器無法漂移，并且還存在許多無主容器。在機(jī)器下線時(shí)，這些無主容器沒有人處理，由于不清楚其影響范圍，這些機(jī)器也不能輕易關(guān)機(jī)。

為了提升容器漂移速度，我們對(duì)下線流程進(jìn)行了優(yōu)化。將漂移方式由“按機(jī)器串行漂移”改造為“按集群并行漂移”，在不打破1、2、10原則的前提下盡可能地漂移容器。在確保穩(wěn)定性的前提下，容器漂移速度由每天50臺(tái)提升到了每小時(shí)100臺(tái)。針對(duì)無主容器，我們與 SRE 及各業(yè)務(wù)線同學(xué)合作進(jìn)行清理，并對(duì)長(zhǎng)期無人處理的容器制定了下線標(biāo)準(zhǔn)，即：

• 每天向負(fù)責(zé)人發(fā)送通知，連續(xù)三次通知后，對(duì)不符合兜底策略的集群負(fù)責(zé)人進(jìn)行拉群通知。
• 在拉群通知后觀察一天，對(duì)仍未處理的集群，關(guān)閉對(duì)應(yīng)宿主機(jī)并觀察三天。
• 如果在三天內(nèi)用戶反饋異常，我們將在一小時(shí)內(nèi)對(duì)容器進(jìn)行恢復(fù)操作。如果三天后仍然無人反饋，將進(jìn)行機(jī)器退還操作。

通過新的漂移流程和下線標(biāo)準(zhǔn)，可以有效提升彈性云機(jī)器的下線宿主，同時(shí)也能確保各優(yōu)化項(xiàng)目的穩(wěn)定推進(jìn)。

圖片

低負(fù)載資源治理

彈性云2022年低負(fù)載時(shí)間大于10天的機(jī)器存在不少，優(yōu)化低負(fù)載機(jī)器的數(shù)量能降低部分彈性云成本，低負(fù)載資源在彈性云可分為以下兩類：

• 預(yù)期內(nèi)低負(fù)載：新機(jī)房交付還未投入使用、控制面機(jī)器利用率較低等
• 預(yù)期外低負(fù)載：機(jī)器交付忘記上線、測(cè)試后忘記退還等原因?qū)е聶C(jī)器處于閑置狀態(tài)，部分機(jī)器過保、維修后無法上線且未進(jìn)行置換、退換等。

全流程為此開發(fā)了閑置資源管控模塊，自動(dòng)對(duì)閑置機(jī)器操作人進(jìn)行通知。指定用戶可對(duì)預(yù)期內(nèi)低負(fù)載機(jī)器進(jìn)行豁免，而長(zhǎng)期未豁免的機(jī)器將自動(dòng)退還。這樣可以最終消化存量的預(yù)期外低負(fù)載機(jī)器并減少新增情況。

總結(jié)

在彈性云的發(fā)展過程中，宿主機(jī)的生命周期管理是一個(gè)重要的問題。最初，機(jī)器的上線操作是手動(dòng)進(jìn)行的，導(dǎo)致上線速度緩慢。

為了解決這個(gè)問題，彈性云開發(fā)了宿主生命周期管理平臺(tái)(mmachine)。通過不斷優(yōu)化和改進(jìn)，mmachine  縮短了機(jī)器上線的耗時(shí)，提高了效率，并通過定制下線標(biāo)準(zhǔn)、并發(fā)漂移等方式，縮短了機(jī)器下線周期，在保障穩(wěn)定性的前提前下，加速退還彈性伸縮、機(jī)器置換等項(xiàng)目節(jié)省下來的資源。通過自動(dòng)報(bào)修、低負(fù)載治理等模塊，mmachine  將資源充分利用起來，提升了彈性云平臺(tái)的整體資源利用率，降低了彈性云服務(wù)器的成本。