面對節(jié)假日常規(guī)促銷、618/雙11購物節(jié)、以及去年初疫情全民線上買菜購物等配送業(yè)務(wù)訂單量的暴增時期，我們通過智能彈性伸縮架構(gòu)和精細(xì)化的容量管理，有效地做到了業(yè)務(wù)系統(tǒng)對配送全鏈路履約和服務(wù)體驗(yàn)的保駕護(hù)航和進(jìn)一步提升，同時業(yè)務(wù)低峰期的極限縮容又將彈性發(fā)揮到極致，使得我們在成本控制方面獲得了不錯的收益。

本文將分享在業(yè)務(wù)量激增和云原生技術(shù)升級改造的背景下，達(dá)達(dá)在彈性伸縮架構(gòu)方面的探索和推廣、精細(xì)化的容量管理和策略優(yōu)化、多云環(huán)境和多運(yùn)行時的適配、指標(biāo)可觀測等方面的實(shí)踐和收益。

1 彈性容量的重要性及自動擴(kuò)縮容初探

1.1從一次故障說起彈性的重要性

時間要回到2019年的某次常規(guī)促銷，鮮花業(yè)務(wù)待接單在短時間內(nèi)陡增，消息隊(duì)列有積壓告警后研發(fā)先后手動擴(kuò)容了服務(wù)A、B來增加隊(duì)列的消費(fèi)能力，之后服務(wù)A、B以高于日常N倍的量請求服務(wù)C某個接口，繼而加劇了服務(wù)C集群負(fù)載同時該服務(wù)的接口響應(yīng)在逐漸變差，服務(wù)C的集群機(jī)器開始CPU告警，研發(fā)聯(lián)系運(yùn)維擴(kuò)容，接下來等待了19分鐘后運(yùn)維介入擴(kuò)容了2臺服務(wù)C（1臺成功1臺失敗），此刻服務(wù)C集群中有一半機(jī)器CPU被打滿，另外一半機(jī)器CPU接近80%，App端請求服務(wù)C的接口超時，線上業(yè)務(wù)開始受損，接下來的11分鐘，運(yùn)維擴(kuò)容x臺機(jī)器又全部失敗，最后只能通過手動拉起上線后，業(yè)務(wù)才徹底恢復(fù)。

復(fù)盤整個故障過程，引發(fā)了更多的靈魂拷問，比如常規(guī)促銷是否也需要壓測以確保容量是足夠的、擴(kuò)容SOP及成功率和效率的保障、故障處理流程優(yōu)化、業(yè)務(wù)設(shè)置降級開關(guān)等等， 其中容量規(guī)劃及擴(kuò)容成功率、效率是運(yùn)維側(cè)首當(dāng)其沖要復(fù)盤跟進(jìn)解決的。

如果沒有壓測，那么如何解決容量規(guī)劃的問題？

我們的思考是通過彈性容量來應(yīng)對壓力的變化。

上圖中，黃線所代表的傳統(tǒng)容量規(guī)劃，在應(yīng)對時刻變化的業(yè)務(wù)需求時，要么是資源不足造成系統(tǒng)性能不足，要么是資源浪費(fèi)。而綠線所代表的彈性伸縮可以實(shí)現(xiàn) “哪些服務(wù)應(yīng)該在哪個時間點(diǎn)擴(kuò)容多少實(shí)例” 以自適應(yīng)應(yīng)對業(yè)務(wù)需求的變化， 這正是我們想要做到的彈性容量。

1.2 自動擴(kuò)縮容初探

自動擴(kuò)縮容之所以可以順利開展，得益于我們在配置管理引入Apollo、基于Consul實(shí)現(xiàn)服務(wù)注冊發(fā)現(xiàn)和數(shù)據(jù)源高可用、基于OpenResty+Consul的網(wǎng)關(guān)實(shí)現(xiàn)了upstream節(jié)點(diǎn)熱更新，并做到了節(jié)點(diǎn)無狀態(tài)。

我們給每個服務(wù)設(shè)置了一個基準(zhǔn)值（最小實(shí)例數(shù)），并借助于Falcon集群水位告警+彈性配置 實(shí)現(xiàn)了第一版的自動擴(kuò)縮容系統(tǒng)AutoScaler，具體如下：

AutoScaler彈性配置如下：

• 最小實(shí)例數(shù)：默認(rèn)2，可調(diào)整

• 擴(kuò)容：

  P0、P1核心服務(wù)：

  集群CPU水位>30%，直接擴(kuò)容線上一半實(shí)例數(shù)

  集群CPU水位>50%，直接擴(kuò)容線上一倍實(shí)例數(shù)

  P0、P1核心服務(wù)：

  集群CPU水位>50%，直接擴(kuò)容線上一半實(shí)例數(shù)

• 縮容：

  集群CPU水位<5%，告警通知，觸發(fā)StackStorm回收線上一半實(shí)例，且剩余實(shí)例數(shù)>=最小實(shí)例數(shù)

        第一版彈性擴(kuò)縮容AutoScaler上線后，主流程的頭部服務(wù)在高峰期會自動觸發(fā)擴(kuò)容，而業(yè)務(wù)低峰期時更多的服務(wù)都在縮容，這表明部分服務(wù)之前的容量是過剩的，借助于彈性似乎可以尋找到服務(wù)之間合適的比例，成本方面也可以得到一定的平衡。

然而，僅僅靠集群CPU水位指標(biāo)是無法覆蓋更多業(yè)務(wù)場景的，比如某些業(yè)務(wù)隊(duì)列積壓需要擴(kuò)容更多的消費(fèi)者、連接池打滿、單機(jī)離群（CPU使用率偏高、磁盤IO、網(wǎng)卡進(jìn)出、錯誤日志數(shù)、接口響應(yīng)超時等有明顯差異的）、單機(jī)QPS 等場景需要更多的指標(biāo)，迫使我們往更深層次考量和設(shè)計(jì)更加靈活智能的彈性架構(gòu)。

2  智能彈性架構(gòu)的思考和設(shè)計(jì)

毫無疑問，精細(xì)化的容量管理對系統(tǒng)持續(xù)穩(wěn)定運(yùn)行和云成本控制至關(guān)重要，而彈性架構(gòu)又是實(shí)現(xiàn)這一問題的核心點(diǎn)。

但是，彈性架構(gòu)和自動伸縮是一定需要結(jié)合實(shí)際業(yè)務(wù)場景來考慮，“從上至下思考，從下至上執(zhí)行”，我們對問題的分析和拆解如下圖：

我們需要面對的是，在配送業(yè)務(wù)訂單量和運(yùn)力之間的實(shí)時供需匹配關(guān)系下，為保證發(fā)單、派單、接單、取貨、路徑規(guī)劃和送達(dá)等配送全流程各環(huán)節(jié)的履約 而對業(yè)務(wù)系統(tǒng)算力和吞吐響應(yīng)提出穩(wěn)定性的要求，即底層業(yè)務(wù)系統(tǒng)和相關(guān)組件的容量 需要時刻能穩(wěn)定地承載上層各種業(yè)務(wù)。同時，又可以在業(yè)務(wù)低峰期的時候自動收回冗余資源且不影響用戶體驗(yàn)。

這就如同無人自動駕駛這樣的場景：既要感知實(shí)時路況的同時，也考慮不同時段可能遇到堵車等突發(fā)情況，又要滿足不同年齡層次的乘客對時間、費(fèi)用和舒適度的體驗(yàn)要求，還要盡可能省電省油。

自動駕駛系統(tǒng)體系架構(gòu)圖如下：

參考如上自動駕駛的架構(gòu)，且彈性系統(tǒng)需要滿足如下需求:

1.彈性覆蓋更多核心服務(wù)，且研發(fā)可以自助配置彈性策略

2.支持大促壓測鏈路服務(wù)的自動擴(kuò)容

3.支持除cpu.busy以外的指標(biāo)，比如消息隊(duì)列長隊(duì)、連接數(shù)、DiskIO、錯誤日志數(shù)、接口響應(yīng)時間、服務(wù)端不可達(dá)比例等

4.自定義縮容及極限縮容，以降低成本

5.彈性對云原生技術(shù)改造過程中多運(yùn)行時、多云的支持

于是，我們圍繞 “感知” - “決策” - “執(zhí)行” 設(shè)計(jì)了如下彈性伸縮架構(gòu)：

沒錯，以上即我們從自動駕駛獲得的靈感，彈性系統(tǒng)需觀測到每個環(huán)節(jié)涉及服務(wù)及關(guān)聯(lián)消息隊(duì)列等組件相關(guān)指標(biāo)，也就是輸入是某個metric，結(jié)合策略及時序數(shù)據(jù)分析，執(zhí)行相應(yīng)策略以保障配送全流程的履約率和體驗(yàn)。

2.1感知 - 觀測業(yè)務(wù)系統(tǒng)指標(biāo)

感知部分是為了接入更多已有的業(yè)務(wù)系統(tǒng)觀測指標(biāo)（某個metric），且能適配多種時序數(shù)據(jù)庫。

• Falcon:系統(tǒng)監(jiān)控，如cpu.busy、cpu.switches、mem.memused.percent、disk.io.util、ss.timewait、net.if.total.packets等指標(biāo)，以及集群機(jī)器這些指標(biāo)的方差來衡量是否離群

• InfluxDB：定制化的中間件將服務(wù)與服務(wù)、服務(wù)與緩存和隊(duì)列的請求及耗時統(tǒng)計(jì)均存入Influxdb中，用于monitor業(yè)務(wù)指標(biāo)監(jiān)控

• Loki：對info、error日志收集后存入Loki，并直接在granfa上形成metrics，比如error中某個class的Exception異常（對應(yīng)一類業(yè)務(wù)場景）的指標(biāo)數(shù)據(jù)

• Prometheus：支持在云原生技術(shù)升級改造過中使用到的Docker和Kubernetes的核心指標(biāo)監(jiān)控

• OpenTSDB：目前在集群指標(biāo)聚合時會把多種時序格式統(tǒng)一轉(zhuǎn)換成opentsdb格式形成metric

2.2 決策 - 彈性伸縮的核心

決策部分是彈性伸縮架構(gòu)的核心，分為如下幾個模塊：

• Configuration：彈性規(guī)則配置入口，研發(fā)可自助配置當(dāng)前服務(wù)的最小實(shí)例數(shù)、所在鏈路、所在云、擴(kuò)縮容指標(biāo)、閾值、速率和開關(guān)

• Dashboard：彈性擴(kuò)縮容運(yùn)行情況實(shí)時展示（每個服務(wù)當(dāng)前在線實(shí)例數(shù)、期望實(shí)例數(shù)、彈性擴(kuò)縮實(shí)例數(shù)、實(shí)例成本）

• Notification：擴(kuò)縮容消息通知到企業(yè)微信、發(fā)送每日擴(kuò)縮容匯總郵件

• Aggregator：計(jì)算并聚合集群指標(biāo)， 如下圖是某服務(wù)集群基礎(chǔ)分組的cpu.busy的平均水位

• Collector：時序數(shù)據(jù)統(tǒng)一轉(zhuǎn)換到opentsdb并生成metric

• Juge：決策引擎

  定時調(diào)用Collector和TSA做數(shù)據(jù)分析，Watch對應(yīng)服務(wù)的Rule，生產(chǎn)下一步?jīng)Q策（擴(kuò)容、縮容 或 保持不變），其核心邏輯參考自Kubernetes的HPA算法，如下

desiredInstances=ceil(currentInstances*(currentMetricValue/desiredMetricValue))

• Rule：彈性擴(kuò)縮總控平臺，Configuration的匯總并存入CMDB

• TSA：目前采用的是MA3、MA5并結(jié)合TP50、TP90做時序數(shù)據(jù)分析

• CMDB+Consul：服務(wù)元數(shù)據(jù)，供Aggregator和Collector計(jì)算和生產(chǎn)metric

• Cache：緩存Collector和Jude歷史數(shù)據(jù)和決策，輔助下一次決策下發(fā)和算法預(yù)測

2.3 執(zhí)行 - 彈性容量的落地保障

有效執(zhí)行是彈性容量落地的保障，為了應(yīng)對上百個服務(wù)及對應(yīng)不同的發(fā)布引擎，我們對worker設(shè)計(jì)了Dispatch和Providers模塊：

• Dispatch：并發(fā)執(zhí)行擴(kuò)縮容流程及上下線操作、重試策略、日志審計(jì)、以及縮容流程的優(yōu)化點(diǎn)（和schedulejob的對接加入防止將正在運(yùn)行的節(jié)點(diǎn)回收、跳到白名單機(jī)器等）

• Providers：抽象統(tǒng)一的擴(kuò)縮容接口，以適配多種發(fā)布系統(tǒng)（deployng、tars、k8s、serverless等）

當(dāng)前彈性擴(kuò)縮容系統(tǒng)AutoScaler僅用于生產(chǎn)環(huán)境的無狀態(tài)服務(wù)，如下圖所示，AutoScaler準(zhǔn)確捕捉到業(yè)務(wù)壓力的上升趨勢并擴(kuò)容了合適的實(shí)例數(shù)，上升曲線擬合效果達(dá)到預(yù)期。

3 彈性擴(kuò)縮容的落地實(shí)踐

在彈性伸縮系統(tǒng)AutoScaler落地和推廣過程中，我們通過在Rule加入更多的字段和開關(guān)，更好的滿足了業(yè)務(wù)研發(fā)對擴(kuò)縮容的新需求：

• 支持基礎(chǔ)鏈路base和壓測鏈路benchmark

• 支持應(yīng)用分組group

• 支持多云cloud

• 支持分時段的極限縮容

• 支持多metric協(xié)同，并且通過sql語句可適配多種metric，比如隊(duì)列長度

SELECT sum("value") FROM "*_queue_*" WHERE ("queue" = 'XXXX') AND time >= now() - 5m GROUP BY time(1m) fill(null)

彈性伸縮總控配置面板如下圖所示

這里，著重分享3點(diǎn)我們在落地彈性擴(kuò)縮容過程中遇到的問題和經(jīng)驗(yàn)。

3.1 擴(kuò)縮容定期演練

擴(kuò)縮容系統(tǒng)能不能隨時隨地正確的工作，是需要通過經(jīng)常演練才能確保的。

實(shí)際過程我們遇到的情況有如下幾點(diǎn)：

• 彈性核心功能和策略是否如期生效，metric數(shù)據(jù)聚合的準(zhǔn)確度，以及分時段縮容 及多metric協(xié)同；擴(kuò)容實(shí)例需要考慮已有節(jié)點(diǎn)的多可用區(qū)的分布情況，盡量做到多可用均分打散。

• 對下游發(fā)布系統(tǒng)、云資源、擴(kuò)縮容也需要一并驗(yàn)證，發(fā)現(xiàn)問題點(diǎn)和瓶頸點(diǎn)并及時解決。我們曾遇到過賬戶余額不足、云主機(jī)無資源、發(fā)布系統(tǒng)多任務(wù)有瓶頸、縮容了正在跑job的節(jié)點(diǎn)、縮容了不該縮容的節(jié)點(diǎn)（其他業(yè)務(wù)有寫死固定IP到/etc/hosts的情況）、縮容太多觸發(fā)了中間件的兜底策略等。

• 擴(kuò)容時刻要堅(jiān)決擴(kuò)容，縮容需要應(yīng)對流量徒增情況，我們引入速率ratio參數(shù)有效控制了縮容的速率，從2.3節(jié)的圖可以證實(shí)生產(chǎn)環(huán)境自動縮容是緩慢下降的。

• 不能無止盡無腦的擴(kuò)容，要有剎車機(jī)制：我們和每個服務(wù)的研發(fā)負(fù)責(zé)人確認(rèn)服務(wù)的實(shí)例最大上限，防止數(shù)據(jù)源連接池耗盡或者打爆。同時我們也會監(jiān)控DB的連接和負(fù)載并及時做好垂直拆分的預(yù)案。

• 觀測大規(guī)模并發(fā)擴(kuò)容時，服務(wù)依賴的緩存、隊(duì)列、DB的連接數(shù)、主從復(fù)制等是否有壓力或延時，新加節(jié)點(diǎn)是否會造成超時以及線上服務(wù)響應(yīng)有無劇烈抖動等。

• 每日跟蹤擴(kuò)縮容的核心指標(biāo)：擴(kuò)縮容成功率、效率、成本趨勢可視化。

3.2 極限縮容

為了平衡擴(kuò)容帶來的成本增加，業(yè)務(wù)低峰期或夜間的極限縮容功能可以有效平衡，畢竟業(yè)務(wù)是有明顯的時間區(qū)段。

極限縮容是精細(xì)化容量管理的關(guān)鍵點(diǎn)，同時也是彈性系統(tǒng)實(shí)現(xiàn)降本的核心點(diǎn)。

極限縮容本身并不復(fù)雜，它是把最小實(shí)例數(shù)在另外一個時段段調(diào)成了一個更為激進(jìn)的數(shù)字，難點(diǎn)在于要在這個時間段結(jié)束后有效地把最小實(shí)例數(shù)擴(kuò)容恢復(fù)到原來的數(shù)，如下圖，即要在06:00新擴(kuò)容10個實(shí)例且要確保100%擴(kuò)容成功。

如何保證100%成功率？我們一直在努力優(yōu)化擴(kuò)容流程的每個環(huán)節(jié)，包括購買VM、環(huán)境初始化步驟和一些base image內(nèi)置到主機(jī)系統(tǒng)鏡像、主機(jī)啟動后預(yù)ping全網(wǎng)節(jié)點(diǎn)以削弱流表下發(fā)延遲帶來的和其他已有主機(jī)建連的失敗概率等等。

為了實(shí)現(xiàn)更確信的擴(kuò)容成功率和效率，我們引入Container、Kubernetes和Serverless安全容器等云原生技術(shù)。

3.3 支持多運(yùn)行時

• 為了兼容并支持VM、VM+Container、Kubernetes、Serverless安全容器等多種運(yùn)行時

• 為了保持?jǐn)U縮容流程標(biāo)準(zhǔn)化的延續(xù)

• 為了實(shí)現(xiàn)擴(kuò)容優(yōu)雅上線、縮容優(yōu)雅下線，進(jìn)程中止/宕機(jī)立即停流量止血

我們選擇了單Container/Pod多進(jìn)程的方式，并自研的PID 1進(jìn)程：從基于dumb_init的shell腳本、再到借鑒systemd守護(hù)進(jìn)程方式的entrypoint，再到當(dāng)前用go重構(gòu)的dinit

通過dinit，我們很好的實(shí)現(xiàn)了以下功能

• 進(jìn)程管理：容器內(nèi)多進(jìn)程的依賴管理，實(shí)現(xiàn)進(jìn)程啟動/銷毀的順序和進(jìn)程存活管理

• 流量控制：Pod的健康檢查通過后會自動推送當(dāng)前節(jié)點(diǎn)到Consul上；Pod被Kill時,dinit會先停外部流量及內(nèi)部流量，再殺服務(wù)進(jìn)程，實(shí)現(xiàn)優(yōu)雅銷毀

• 原地重啟：Kubernetes不支持Pod原地重啟，dinit可以實(shí)現(xiàn)服務(wù)進(jìn)程就地重啟

在實(shí)際落地過程中，我們在算法部門推送的極限擴(kuò)縮容及多運(yùn)行時的方案，且極限縮容也為算法部門服務(wù)云主機(jī)成本帶來大幅度的降低。在發(fā)布方面我們做到了變更邏輯同步觸發(fā)，用戶體驗(yàn)和業(yè)務(wù)響應(yīng)也做到了一致性保證。目前我們正在配合算法部門一起推進(jìn)算法模型服務(wù)部署到Kubernetes，力求容量性能和成本之間的平衡做進(jìn)一步提升和優(yōu)化。

4 總結(jié)和展望

彈性擴(kuò)縮容系統(tǒng)已經(jīng)穩(wěn)定運(yùn)行了將近20個月，企業(yè)微信每天都可以收到許多服務(wù)自動擴(kuò)容/縮容的消息推送，AutoScaler一直在后臺默默地工作著，為系統(tǒng)穩(wěn)定性保駕護(hù)航。

目前彈性擴(kuò)縮容系統(tǒng)仍具有非常大的提升優(yōu)化空間：

• 時序數(shù)據(jù)分析后的決策和實(shí)際情況仍有一定程度的滯后，比如連續(xù)擴(kuò)容的情況，我們希望容量在一定程度上是可以預(yù)測出來的，且最小實(shí)例數(shù)也是會隨實(shí)際情況變化的，目前基于facebook prophet的Predict模塊正在設(shè)計(jì)開發(fā)中，希望可以自適應(yīng)做到提前預(yù)測并執(zhí)行擴(kuò)縮容;

• 優(yōu)化并提升TSA模塊，以便可以有效地檢測識別出異常點(diǎn)，輔助問題定位并最終生成決策，目標(biāo)是實(shí)現(xiàn)全自動的故障自愈。

作者簡介：楊森，達(dá)達(dá)集團(tuán)DevOps & SRE 負(fù)責(zé)人，專注于提升分布式系統(tǒng)的穩(wěn)定性和可觀測性、彈性容量、故障自愈、多云容器架構(gòu)及效能平臺建設(shè)。