作者：閑魚技術——影湛

引言

閑魚的服務端技術架構正向著云原生/Serverless化發展，Serverless具有著運維自動化、按需加載、彈性伸縮、強隔離性、敏捷開發部署等技術特點，帶來了降低人力成本、降低風險、降低基礎設施成本、降低交付時間等核心優勢。這其中，彈性伸縮是Serverless中被廣泛關注的一大亮點，甚至有些人將自動擴縮容的能力支持作為應用是否Serverless化的判定標準。另外，在閑魚與淘系Gaia FaaS平臺共建Serverless化的業務遷移時，彈性伸縮也一直是個懸而未決的問題。為此，本文會針對Serverless的彈性伸縮技術的現狀做一個初步的調研。

彈性伸縮的基本概念

定義

彈性伸縮所關注的問題主要是容量規劃與實際集群負載間的矛盾，當現有集群的資源無法承載流量壓力時，如果通過調整集群的規模或者資源的分配，從而保障系統的穩定性，同樣在集群負載較低時，盡量降低集群的資源配置從而減少閑置資源的浪費帶來的成本開銷。彈性伸縮不僅適合業務量不斷波動的應用程序， 同時也適合業務量穩定的應用程序。

彈性伸縮可以分為應用伸縮、技術伸縮和資源伸縮，我們通常所說的伸縮大都指的是資源的伸縮性，即調整機器的硬件資源以提高系統性能。而資源伸縮又可以分為橫向水平伸縮和縱向垂直伸縮。縱向垂直伸縮是指通過提升集群內每個節點的處理能力以提升整體性能的伸縮方式，簡單來說就是給單節點機器配置升級；而橫向伸縮是指通過增刪集群節點來提升或降低系統的處理能力，優點在于伸縮更加靈活，由于節點間資源是完全隔離的，也不必擔心單點故障對其他節點的影響，更加安全可靠。因此在大部分Serverless應用場景中都采用橫向水平伸縮方式。

彈性伸縮算法

彈性伸縮算法一般可分為基于某個資源指標閾值的響應式伸縮算法和基于預測型的伸縮算法，前者通過周期性的資源指標數據，與所設定的指標閾值進行對比，從而動態的改變集群節點數量；后者則通過對歷史的系統性能與資源配置數據的分析，對未來的容量進行評估預測，相比于基于閾值的響應式伸縮算法，基于預測型的伸縮算法能更快的響應突發狀況，彈性伸縮變化更加的平滑，但是分析數據所需要的模型建立也顯得尤為關鍵，具有比較大的挑戰難度。

通常在業務場景的落地和大部分的開源解決方案中，彈性伸縮的算法都是基于閾值來實現的，比如CPU使用率、Load、內存使用率、磁盤使用率等，通過設定一個資源的Buffer水位來避免系統的過載發生。

云原生應用Kubernetes彈性實踐

目前云原生應用的設計理念已被越來越多的業內人士所認可，而Kubernetes作為云原生的標準接口實現，已經成為了容器編排的事實標準。云服務的能力可以通過Cloud Provider、Operator等方式從Kubernetes的標準接口向業務層透出，而業務開發者可以基于Kubernetes構建自己的云原生應用，基于Kubernetes的各種云原生應用生態讓Kubernetes成為了“云OS”。

Kubernetes彈性伸縮組件

Kubernetes提供了一系列標準的彈性伸縮組件，從方向上可分為橫向水平和縱向垂直兩種伸縮方式，從對象上可分為按Pod伸縮和按節點伸縮。這樣就存在節點水平伸縮組件Cluster-Autoscaler、Pod水平伸縮HPA&Cluster-Proportional-Autoscaler以及Pod垂直伸縮VPA&Resizer這三大組件。其中HPA組件最為常用，HPA可以基于CPU利用率自動擴展Pod數量，當然也支持基于其他應用程序提供的自定義度量指標來執行自動擴縮。Pod 水平自動擴縮特性由 Kubernetes API 資源和控制器實現，資源決定了控制器的行為。 控制器會周期性的調整副本控制器或部署中的副本數量，以使得 Pod 的平均 CPU 利用率與用戶所設定的目標值匹配。

HPA

Kubernetes資源指標數據

目前HPA的API共有三個版本，分別是autoscaling/v1、autoscaling/v2beta1和autoscaling/v2beta2，其中autoscaling/v1只支持基于CPU指標的伸縮，v2beta版本額外支持內存等其他資源指標，并且還支持自定義指標的伸縮。所有的系統資源指標數據，都可以通過Metrics API來獲取，而自定義指標數據的采集是通過Agrregator APIServer擴展機制來實現的，HPA使用這些metrics信息來實現動態伸縮。

HPA算法介紹

HPA的主要伸縮流程如下：

1. HPA控制器根據當前指標和期望計算擴縮比例

期望副本數 = ceil[當前副本數 * (當前指標 / 期望指標)]

1. 計算期望指標與當前指標的比值得到一個伸縮系數，如果系數大于1表示擴容，小于1表示縮容，指標數值有平均值、平均使用率、裸值三種類型，每種類型的數值都有對應的算法。需要注意的是，如果伸縮系數未達到某個容忍值，HPA控制器會認為變化太小而忽略這次系數的變化，容忍值默認為0.1。

HPA伸縮算法是一個相對比較保守的算法，如果某個Pod獲取不到資源指標或者資源沒有準備好的情況下，在進行擴容操作時，該Pod的資源指標均不會加入計算。如果創建HPA的時候指定了多個指標，那個會按每個指標分別計算擴縮容副本數，并取最大值進行擴縮容。另外，在HPA執行伸縮操作前，會記錄擴縮建議信息，HPA控制器會在操作時間窗口中考慮所有的建議信息，并選擇得分最高的建議。這個值可配置，從而可以讓系統更為平滑地進行縮容操作，從而消除短時間內指標值快速波動產生的影響。

HPA應用場景

HPA的特性使得部署在HPA伸縮對象上的服務具有非常靈活的自適應能力，當面對某個系統指標的突增時能夠在一定限定范圍內快速復制多個副本，也可以在指標持續走低的情形下通過刪除副本以騰出資源，從而保障了整個系統的穩定性。比較適合存在周期性較大流量波動的業務場景，如電商、金融等應用。

困難與挑戰

Kubernetes彈性伸縮挑戰

目前大部分開源組件和解決方案都是基于Kubernetes的彈性伸縮組件來實現的，表面上看起來沒什么大的問題，但是通過調研發現，隨著用戶需求的日趨多樣化，基于Kubernetes彈性組件的應用擴縮容策略逐漸暴露出很多不足之處：

1. 應用級別指標進行彈性伸縮的支持不佳

Kubernetes的內置能力主要作用對象都是容器級別的，提供了管理和編排容器的能力支持，但是大部分產品都是以應用和用戶為核心，這樣以容器級別的CPU和內存等作為擴縮容指標就顯得有點粗粒度，他們更關注RT、QPS、接口成功率等應用級別細粒度的負載指標，圍繞者這些指標以提供彈性伸縮能力才是迫切需要的。但比較尷尬的是，盡管Kubernetes HPA組件提供了自定義指標的功能，它的可擴展性整體上還是不夠靈活，自定義指標的可插拔性也不夠好，尤其當將自定義指標細化到應用層面時，經常不得不去修改底層的HPA組件代碼。因此，如何通過一個擴展性更強的、外部框架來進行細粒度的應用擴縮容策略顯得尤為關鍵。

1. 不支持應用Scale To Zero的需求

Scale To Zero是指當容器或者Pod處于閑置狀態時可以將副本數縮減至0，然后當有請求流量時，可以快速恢復。 在Serverless場景中，Scale To Zero是一個比較典型的自動彈性伸縮場景，可以有效節省資源開銷和降低成本。但是Kubernetes HPA并不關注這種場景，因此也不會提供這種能力支持的。

1. 容量規劃問題

我們在做傳統應用的機器配置選型時，一般是按照應用進行分配的，但是在容器尤其Serverless的場景中，開發者是無需關心底層的資源的，這時候就會缺少實際的容量規劃這一步，導致在Kubernetes中對于每個節點的預留資源閾值而言，很有可能會造成小節點預留資源過低，無法滿足計算需求，而大節點的預留又過高而造成資源浪費的情形。

1. 資源分配碎片問題

在同一個Kubernetes集群中，不同規格的機器、不同的場景容量規劃可能會有比較大的差異，那么集群伸縮的百分比會存在較大的不一致性與誤導性。如果存在4c8g和16c32g兩種規格的Pod，在縮容的場景下，為了保證縮容后集群的穩定性，如果我們按照統一的資源利用率來判定縮容機器的標準，那么很有可能造成大規格的機器被縮容后，容器重新調度后的爭搶饑餓問題。如果配置優先縮容小規格的機器，就會造成小規格機器的大量冗余。

1. 資源利用率問題

當一個Pod資源利用率很低時，不代表就可以侵占它所申請的資源。在大部分線上業務場景中，資源的利用率都不會保持著一個很高的水位，但是從Kubernetes的調度原則中來說，資源的利用又應該保持在一個較高的水位，這樣才能避免資源的浪費，這兩者間存在著矛盾性，如果權衡是個比較大的難題。

閑魚Serverless化實踐中彈性伸縮挑戰

除了上述的Kubernetes中遇到的典型難題外，閑魚在對服務端架構Serverless化的探索過程中還遇到了其他的一些困難點，影響自動彈性伸縮能力的落地。

1. Runtime冷啟動時延問題

業務場景中會經常遇到流量突發情況，大部分的非業務形態的系統故障也都是由流量突增引起的，這就要求Serverless具備秒級彈性的能力，如果擴容時間過長，可能流量峰值已經一閃而過，擴容就顯得毫無意義。而影響擴容時長的一個重要步驟就是Runtime的冷啟動，不同特性的語言Runtime冷啟動的時長有比較大的差別，比如用Nodejs / python等語言實現的純凈的Runtime，冷啟動完全可以控制在2s以內。但是在我們閑魚內部的業務場景中，為了兼容原有應用框架，復用彈內的中間件和中臺能力，我們有很多是用Java語言基于Spring框架實現的Serverless，冷啟動要經歷Spring&Pandora啟動、插件加載、中間件Client的初始化、Bean初始化等過程，秒級啟動幾乎是不可能的。

1. 上游依賴容量評估問題

如果僅是針對一個獨立的應用進行擴容，風險相對還是可控的，但是往往一個Serverless應用都會有多個上游依賴，這個依賴或是領域服務，或是數據存儲BaaS服務等。當某個核心鏈路比如交易下單應用流量突增，我們需要將提供該服務的Serverless應用的資源擴容，但僅擴容該應用是遠遠不夠的，因為上游查詢商品領域服務的依賴應用也必然出現流量突增狀況，相應的我們也需要對該領域服務進行重新的流量評估并擴容，這就大大加劇了擴容問題的復雜度。

1. 流量高峰的資源分配問題

閑魚大部分核心服務的流量時間分布還是相對比較集中的，彈性伸縮場景下，在流量峰值到達時這些應用都需要進行擴容操作，但是Serverless基于Pod的擴容都是存在一個比較固定的Pod池的，這就要求Pod池的容量Buffer要基于整個閑魚業務流量峰值來設定，如果容量評估不足，會造成高峰期資源競爭饑餓現象，而容量評估過高時，又會導致在大多數的非高峰期間內的資源浪費現象。當然，如果存在錯峰的業務場景并且相應的峰值流量比較平衡時，這個問題就不復存在了。

彈性伸縮方案實踐

彈性按階段可劃分為從0到1的Zero-Scaler階段以及從1到N的擴容階段，目前業內大部分的實踐場景都是圍繞著從1到N的彈性擴容方案展開的，關鍵技術點包括資源池化、容量評估決策、彈性調度、智能自動化、穩定性保障等，而從0到1則主要關注從資源的分配到應用的冷啟動的加速實踐，下面會針對幾個典型的彈性系統進行介紹。

菜鳥彈性調度系統

業務場景

菜鳥的系統應用主要是協調商家、CP、消費者之間的信息流轉，而且物流訂單流轉的長鏈路多交互的特定也決定了信息流大于實操流，因此系統面臨的導購秒殺型的脈沖峰值場景非常稀有。核心應用也大都屬于無狀態的在線計算型應用，業務峰谷值差距明顯，這就為彈性伸縮的落地提供足夠的場景支撐。

方舟彈性調度方案

方舟彈性調度提出了一種閉環反饋式的模式，彈性調度基礎能力基于應用分組運行情況和不同應用分組的策略配置參數，做出擴縮容決策，并通過方舟的容器操作服務調整集群容器數量；應用分組集群受到集群容器數量變化的影響，會產生不同的表現行為（例如擴容時集群平均CPU使用率會發生變化，服務rt會在一定范圍內下降等）；應用分組的表現在以實時數據提供給彈性決策的同時，也會進行歷史數據的離線存儲；自動策略配置會周期性獲取這些歷史數據，并依照一定的算法，對不同的應用分組進行不同的策略配置，從而再次影響到彈性調度策略的決策。

這種模式具備一定的自我進化能力，當應用分組剛接入彈性時，大多數策略都是默認指定的，而當彈性運行一段時間后，結合自動評估方式，各種參數會得到不斷的修正以達到更好的彈性效果。而且，這種模式能以更高的抽象層次來進行海量參數的配置，以解決普遍問題。

方舟彈性調度架構體系

方舟彈性調度采用三層決策模型，分別是策略決策、聚合決策和執行決策，解決了計算的無狀態、冪等和高可用的問題，決策策略支持快速橫向擴展，目前已上線的策略包括資源安全策略、資源優化策略、時間策略、服務安全策略等。

目前方舟彈性調度系統能解決實際場景中毛刺問題，能實現整條鏈路的容量彈性伸縮，面對大促場景也能游刃有余，但是在處理無規律脈沖型流量的應用時，還是存在很大的缺陷的。

新浪微博彈性實踐

業務場景

新浪微博總是在特定的時間和特定的事件發生時引來流量高峰，常見的峰值場景為日常的晚高峰、各種運營活動以及明星大V的熱門微博帶來的流量高峰、極端突發事件引起的流量陡增。這些場景的流量特點可以總結為瞬間峰值高和互動時間短。

微博自動彈性伸縮方案

無人值守的擴縮容的三個核心技術是彈性伸縮、故障遷移和服務自動回收，與之對應的是模板中的原子型API。

在平臺擴容時需要向混合云平臺發起請求，平臺進行資源評估，如果配額足夠，可以按照配額量申請，如果配額不足時，需要申請配額，防止資源濫用。上述步驟可以抽象成原子型API任務，以支持自動化的實現。目前新浪研發了一套原子型API任務分發系統，它在每臺機器上都有一個Agent，在中心化組件Dispatch端根據任務模板定義任務，并最終對外提供API。

在容量決策方面，該方案支持兩種決策方式，一種是定時觸發，根據自動壓測的指標和經驗值觸發進行，另一種是自動觸發，通過分析業務指標，對容量預估進行同比和環比分析自動進行擴縮容操作。

阿里云平臺解決容器資源按需分配的實踐

核心痛點是不合理的資源初始化分配和應用容器資源競爭的穩定性問題，以及潮汐應用分時復用和減少資源碎片的資源利用率問題。交付目標是既要穩定性，也要利用率，還要自動化實施和智能化。

方案設計

最初的工具流程設計：當一個應用面臨很高的業務訪問需求時，體現在 CPU、Memory 或其他資源類型需求量變大，我們根據 Data Collector 采集的實時基礎數據，利用 Data Aggregator 生成某個容器或整個應用的畫像，再將畫像反饋給 Policy engine。 Policy engine 會瞬時快速修改容器 Cgroup 文件目錄下的的參數。這種方案對Kubelet進行了侵入式的修改，每次Kubernetes升級對于Policy engine相關組件升級也是一種挑戰。

因此需要將Kubelet解耦開，可以將關鍵應用容器化，這樣可以不侵入式修改Kubernetes核心組件、支持快速迭代、借助Kubernetes相關QoS Class機制，容器資源配置和資源開銷可控。

這其中，最為關鍵的就是策略引擎（Policy engine）的設計，Policy engine 是單機節點上進行智能調度并執行 Pod 資源調整的核心組件。它主要包括 api server，指揮中心 command center 和執行層 executor，設計如下圖所示。

該方案通過分時復用以及將不同優先級的容器（即在線和離線任務）混合部署，并且通過對容器資源限制的動態調整，保證了在線應用在不同負載情況下都能得到足夠的資源，從而提高集群的綜合資源利用率。通過對單機節點上的容器資源的智能化動態調整，降低了應用間的性能干擾，保障高優先級應用的性能穩定。各種資源調整策略可以自動化地、智能化地在節點上運行，從而降低運維成本。

阿里CSE的Serverless彈性實踐

上述的幾種彈性伸縮實踐都是關注于從1到N的彈性方案，但是往往在實際的彈性場景中從0到1才是最為關鍵的技術難點，這其中解決如何將應用冷啟動速度加速到毫秒級的問題至關重要。

技術方案

阿里CSE團隊在解決應用啟動加速的問題上沉淀了豐富的經驗：

方案一：應用冷啟動資源壓縮方案

方案二：應用熱復制啟動加速方案

L1采用通過fork種子進程達到快速啟動的效果，操作系統團隊專門為此開發了Fork2技術，與linux native fork的關鍵區別是可以指定PID來fork一個進程，L2的單個SNAPSHOT可以創建多個進程，一對多關系。Fork2在本地進程的復制場景中還是非常快速的，但是僅適用于本地Fork，而且對于Scale To Zero場景也不支持，這時就需要一種支持水平擴容和從0到1擴容的策略，Local Storage技術方案主要用于解決這種問題，它是一種基于CRIU的進程級熱復制技術。此外，CSE在應用的熱復制的技術探索之路中還提出一種新的彈性技術方案（Zizz），Zizz的核心是熱備，基于離線的實例功耗非常低的假設，研發出一種基于彈性堆的低功耗技術、基于內核態和用戶態的Swap能力的內存彈性技術以及基于ASI的Inplace Update的實例規格動態升降技術，并通過Kubernetes自定義CRD的方式進行能力輸出。

綜合來看這兩種方案，方案一的適用場景更廣，但是每種語言的VM要單獨定制，實現成本更高；方案二會存在UUID問題，如開發者希望應用每個實例啟動都賦值一個UUID給一個靜態變量，優勢是語言無關、方案更容易實現，適用于FaaS類場景。

CSE與AWS Lambda的差異

Lambda為了做到快速擴縮容，要求用戶的應用以Function為單位開發，Lambda Runtime動態加載Function來快速增加實例。而CSE通過將一個應用的多個實例啟動后，共享相同的指令數據，抽取出不同的指令數據，每次啟動實例只需要加載多實例的差異部分，可以透明兼容社區主流技術棧。

總結

通過上述彈性伸縮的調研結果以及我們已經探索的一些實踐經驗，資源池化、彈性調度、容量決策、運維自動化等都已經具備相對比較成熟的解決方案了，基于Kubernetes所提供的基礎能力以及各自業務場景所產出的數據模型所構建的彈性系統能從容應對大多數的彈性需求，但是如何更快、更智能化、更安全的讓業務Pod彈起來仍然有很長的路要走。目前，閑魚團隊在對傳統膠水層應用做自動拆分FaaS化，另外我們還計劃將一些底層的中間件和中臺服務剝離開集中治理，這樣能使得業務應用更加的輕量化，從而加速應用啟動時長，更有利于彈性伸縮。

參考文檔

• https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/
• https://en.wikipedia.org/wiki/Autoscaling
• https://my.oschina.net/u/1464083/blog/3116884
• https://my.oschina.net/u/1464083/blog/3069464
• https://developer.aliyun.com/article/717318
• https://developer.aliyun.com/article/779281
• https://developer.aliyun.com/article/672398
• https://developer.aliyun.com/article/71021
• https://developer.aliyun.com/article/521784
• https://developer.aliyun.com/article/720556
• https://developer.aliyun.com/article/702070

總結

以上是生活随笔為你收集整理的基于希克斯需求价格弹性计算_Serverless弹性伸缩的现状调研（超详细）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。