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

本文將分享在業務量激增和云原生技術升級改造的背景下，達達在彈性伸縮架構方面的探索和推廣、精細化的容量管理和策略優化、多云環境和多運行時的適配、指標可觀測等方面的實踐和收益。

1 彈性容量的重要性及自動擴縮容初探

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

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

復盤整個故障過程，引發了更多的靈魂拷問，比如常規促銷是否也需要壓測以確保容量是足夠的、擴容SOP及成功率和效率的保障、故障處理流程優化、業務設置降級開關等等， 其中容量規劃及擴容成功率、效率是運維側首當其沖要復盤跟進解決的。

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

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

上圖中，黃線所代表的傳統容量規劃，在應對時刻變化的業務需求時，要么是資源不足造成系統性能不足，要么是資源浪費。而綠線所代表的彈性伸縮可以實現 “哪些服務應該在哪個時間點擴容多少實例” 以自適應應對業務需求的變化， 這正是我們想要做到的彈性容量。

1.2 自動擴縮容初探

自動擴縮容之所以可以順利開展，得益于我們在配置管理引入Apollo、基于Consul實現服務注冊發現和數據源高可用、基于OpenResty+Consul的網關實現了upstream節點熱更新，并做到了節點無狀態。

我們給每個服務設置了一個基準值（最小實例數），并借助于Falcon集群水位告警+彈性配置 實現了第一版的自動擴縮容系統AutoScaler，具體如下：

AutoScaler彈性配置如下：

• 最小實例數：默認2，可調整

• 擴容：

  P0、P1核心服務：

  集群CPU水位>30%，直接擴容線上一半實例數

  集群CPU水位>50%，直接擴容線上一倍實例數

  P0、P1核心服務：

  集群CPU水位>50%，直接擴容線上一半實例數

• 縮容：

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

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

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

2  智能彈性架構的思考和設計

毫無疑問，精細化的容量管理對系統持續穩定運行和云成本控制至關重要，而彈性架構又是實現這一問題的核心點。

但是，彈性架構和自動伸縮是一定需要結合實際業務場景來考慮，“從上至下思考，從下至上執行”，我們對問題的分析和拆解如下圖：

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

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

自動駕駛系統體系架構圖如下：

參考如上自動駕駛的架構，且彈性系統需要滿足如下需求:

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

2.支持大促壓測鏈路服務的自動擴容

3.支持除cpu.busy以外的指標，比如消息隊列長隊、連接數、DiskIO、錯誤日志數、接口響應時間、服務端不可達比例等

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

5.彈性對云原生技術改造過程中多運行時、多云的支持

于是，我們圍繞 “感知” - “決策” - “執行” 設計了如下彈性伸縮架構：

沒錯，以上即我們從自動駕駛獲得的靈感，彈性系統需觀測到每個環節涉及服務及關聯消息隊列等組件相關指標，也就是輸入是某個metric，結合策略及時序數據分析，執行相應策略以保障配送全流程的履約率和體驗。

2.1感知 - 觀測業務系統指標

感知部分是為了接入更多已有的業務系統觀測指標（某個metric），且能適配多種時序數據庫。

• Falcon:系統監控，如cpu.busy、cpu.switches、mem.memused.percent、disk.io.util、ss.timewait、net.if.total.packets等指標，以及集群機器這些指標的方差來衡量是否離群

• InfluxDB：定制化的中間件將服務與服務、服務與緩存和隊列的請求及耗時統計均存入Influxdb中，用于monitor業務指標監控

• Loki：對info、error日志收集后存入Loki，并直接在granfa上形成metrics，比如error中某個class的Exception異常（對應一類業務場景）的指標數據

• Prometheus：支持在云原生技術升級改造過中使用到的Docker和Kubernetes的核心指標監控

• OpenTSDB：目前在集群指標聚合時會把多種時序格式統一轉換成opentsdb格式形成metric

2.2 決策 - 彈性伸縮的核心

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

• Configuration：彈性規則配置入口，研發可自助配置當前服務的最小實例數、所在鏈路、所在云、擴縮容指標、閾值、速率和開關

• Dashboard：彈性擴縮容運行情況實時展示（每個服務當前在線實例數、期望實例數、彈性擴縮實例數、實例成本）

• Notification：擴縮容消息通知到企業微信、發送每日擴縮容匯總郵件

• Aggregator：計算并聚合集群指標， 如下圖是某服務集群基礎分組的cpu.busy的平均水位

• Collector：時序數據統一轉換到opentsdb并生成metric

• Juge：決策引擎

  定時調用Collector和TSA做數據分析，Watch對應服務的Rule，生產下一步決策（擴容、縮容 或 保持不變），其核心邏輯參考自Kubernetes的HPA算法，如下

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

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

• TSA：目前采用的是MA3、MA5并結合TP50、TP90做時序數據分析

• CMDB+Consul：服務元數據，供Aggregator和Collector計算和生產metric

• Cache：緩存Collector和Jude歷史數據和決策，輔助下一次決策下發和算法預測

2.3 執行 - 彈性容量的落地保障

有效執行是彈性容量落地的保障，為了應對上百個服務及對應不同的發布引擎，我們對worker設計了Dispatch和Providers模塊：

• Dispatch：并發執行擴縮容流程及上下線操作、重試策略、日志審計、以及縮容流程的優化點（和schedulejob的對接加入防止將正在運行的節點回收、跳到白名單機器等）

• Providers：抽象統一的擴縮容接口，以適配多種發布系統（deployng、tars、k8s、serverless等）

當前彈性擴縮容系統AutoScaler僅用于生產環境的無狀態服務，如下圖所示，AutoScaler準確捕捉到業務壓力的上升趨勢并擴容了合適的實例數，上升曲線擬合效果達到預期。

3 彈性擴縮容的落地實踐

在彈性伸縮系統AutoScaler落地和推廣過程中，我們通過在Rule加入更多的字段和開關，更好的滿足了業務研發對擴縮容的新需求：

• 支持基礎鏈路base和壓測鏈路benchmark

• 支持應用分組group

• 支持多云cloud

• 支持分時段的極限縮容

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

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

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

這里，著重分享3點我們在落地彈性擴縮容過程中遇到的問題和經驗。

3.1 擴縮容定期演練

擴縮容系統能不能隨時隨地正確的工作，是需要通過經常演練才能確保的。

實際過程我們遇到的情況有如下幾點：

• 彈性核心功能和策略是否如期生效，metric數據聚合的準確度，以及分時段縮容 及多metric協同；擴容實例需要考慮已有節點的多可用區的分布情況，盡量做到多可用均分打散。

• 對下游發布系統、云資源、擴縮容也需要一并驗證，發現問題點和瓶頸點并及時解決。我們曾遇到過賬戶余額不足、云主機無資源、發布系統多任務有瓶頸、縮容了正在跑job的節點、縮容了不該縮容的節點（其他業務有寫死固定IP到/etc/hosts的情況）、縮容太多觸發了中間件的兜底策略等。

• 擴容時刻要堅決擴容，縮容需要應對流量徒增情況，我們引入速率ratio參數有效控制了縮容的速率，從2.3節的圖可以證實生產環境自動縮容是緩慢下降的。

• 不能無止盡無腦的擴容，要有剎車機制：我們和每個服務的研發負責人確認服務的實例最大上限，防止數據源連接池耗盡或者打爆。同時我們也會監控DB的連接和負載并及時做好垂直拆分的預案。

• 觀測大規模并發擴容時，服務依賴的緩存、隊列、DB的連接數、主從復制等是否有壓力或延時，新加節點是否會造成超時以及線上服務響應有無劇烈抖動等。

• 每日跟蹤擴縮容的核心指標：擴縮容成功率、效率、成本趨勢可視化。

3.2 極限縮容

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

極限縮容是精細化容量管理的關鍵點，同時也是彈性系統實現降本的核心點。

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

如何保證100%成功率？我們一直在努力優化擴容流程的每個環節，包括購買VM、環境初始化步驟和一些base image內置到主機系統鏡像、主機啟動后預ping全網節點以削弱流表下發延遲帶來的和其他已有主機建連的失敗概率等等。

為了實現更確信的擴容成功率和效率，我們引入Container、Kubernetes和Serverless安全容器等云原生技術。

3.3 支持多運行時

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

• 為了保持擴縮容流程標準化的延續

• 為了實現擴容優雅上線、縮容優雅下線，進程中止/宕機立即停流量止血

我們選擇了單Container/Pod多進程的方式，并自研的PID 1進程：從基于dumb_init的shell腳本、再到借鑒systemd守護進程方式的entrypoint，再到當前用go重構的dinit

通過dinit，我們很好的實現了以下功能

• 進程管理：容器內多進程的依賴管理，實現進程啟動/銷毀的順序和進程存活管理

• 流量控制：Pod的健康檢查通過后會自動推送當前節點到Consul上；Pod被Kill時,dinit會先停外部流量及內部流量，再殺服務進程，實現優雅銷毀

• 原地重啟：Kubernetes不支持Pod原地重啟，dinit可以實現服務進程就地重啟

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

4 總結和展望

彈性擴縮容系統已經穩定運行了將近20個月，企業微信每天都可以收到許多服務自動擴容/縮容的消息推送，AutoScaler一直在后臺默默地工作著，為系統穩定性保駕護航。

目前彈性擴縮容系統仍具有非常大的提升優化空間：

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

• 優化并提升TSA模塊，以便可以有效地檢測識別出異常點，輔助問題定位并最終生成決策，目標是實現全自動的故障自愈。

作者簡介：楊森，達達集團DevOps & SRE 負責人，專注于提升分布式系統的穩定性和可觀測性、彈性容量、故障自愈、多云容器架構及效能平臺建設。