文｜陳鏗彬（花名：阿歹）
螞蟻搜推技術專家
本文 5211 字    閲讀 10 分鐘

背景介紹

螞蟻推薦平台 Arec（Ant Recommender Platform, 後續簡稱 Arec）是針對螞蟻搜索、推薦、營銷以及投放等業務特點建設的在線算法 FaaS 平台。它是由支付寶通用推薦平台 RecNeptune（中文稱: 海王星）演進發展而來，目前在螞蟻內部服務了支付寶、數金、網商、國際等多個部門的搜索、營銷、投放等基於大數據和算法的業務（後面統一叫個性化業務）。

在個性化業務的特點下，專注於數據、策略和算法以及效果提升是這些業務取得成功的關鍵。算法同學的核心在於通過在線多版本能力，面向體驗和效果實現和優化相關策略和算法，而不關心整體系統、環境、穩定性保障等細節。而螞蟻傳統的業務開發是一套複雜、週期性的迭代式發佈流。針對高頻變化、實驗的個性化業務來説，建設相關平台能力，提升整體效率是 Arec 2.0 開展 Serverless 化的重要目標。

問題與挑戰

早期的 Arec 是基於 SOFA4（Cloud-Engine）技術棧開發的應用系統，它的 FaaS/動態模塊化方案也是基於這套技術框架所實現的：採用集中部署策略，將所有業務方案代碼通過 SOFA CE 動態 Bundle 方式熱部署到同一個在線應用中。這種方式雖然在部署效率、切流穩定性和資源利用率上都有一定優勢，但當業務場景增長到幾百上千個，並且在線請求量增長到上百萬 QPS 之後，業務隔離性挑戰越來越大、平台維護成本越來越高、方案代碼編譯發佈保障弱效率低、頭部場景多人協同研發效率低等問題不斷。

1、隨着螞蟻在搜推廣業務的發展，在單台機器裏部署的方案和代碼越來越多，業務的隔離性訴求、服務穩定性差、平台維護成本高，以至於混合部署的方案難以繼續推進。

2、從 Arec 整體的產品層視角出發，為了解決隔離性問題，勢必需要引入獨立部署機制。Arec 2.0 的模型、產品設計上，目標在於平滑銜接獨立部署機制以確保算法部署效率不受影響，甚至達到更優的效果；而針對算法在線部分，Arec 1.0 原本的編譯流程不可控、產物不可信導致部署和運維困難的問題，以及頭部場景多人協同研發、在線多版本實驗的效率問題，都極大影響了個性化業務日常研發的效率以及產品的使用體驗，亟待解決。

3、經過近兩年的迭代後，Arec 更是產生了 CPU 等物理資源利用率不高的問題，存在較大空間優化。

解決方法

為此，Arec 1.0 算法研發能力通過接入 Koupleless，做了全面化升級。

多集羣化與模塊化

通過對集中部署機制升級為多個按業務或按場景隔離部署，徹底解決了業務隔離問題和平台維護問題。首先，我們將原來大的集羣，根據業務域拆分出不同的集羣，如下圖的腰封集羣、基金集羣、底紋詞集羣，每個集羣上按業務安裝不同的模塊代碼包。✅這樣解決了不同業務域的隔離和穩定性問題。

完整的研發模式升級為如下圖，具備以下優勢：

• 研發過程解耦：模塊和基座、模塊和模塊間的研發活動、運維活動完全獨立，互不干擾。
• 模塊極速研發：模塊非常輕量，構建 20 秒，發佈僅 10 秒，極大提高了開發效率。此外，模塊與應用一樣，通過標準迭代發佈到線上基座，迭代可以做到非常快，甚至是朝寫夕發。
• 低成本業務隔離：幾分鐘即可創建邏輯集羣（機器分組），只部署特定模塊，服務特定業務流量，和其他業務實現資源隔離、變更隔離，模塊還支持秒級彈性伸縮。
• 變更部署能力全面升級：通過打通 Git 倉庫，對接 ACI。我們實現 Git 倉庫自動創建，算法編譯部署流程自動化，代碼產物從未知不可信提升到模塊產物可信可交付，發佈鏈路難定位到鏈路可溯源、狀態有感追蹤，通過編譯緩存優化將日常構建時間從 7 分鐘縮短到 1 分鐘；並升級支持多灰度方案，和代碼實驗極大提升複雜場景多人協同研發效率。

模塊組與流量單元

Arec 除了將代碼拆分出各個不同的模塊外，還有兩個問題需要解決：1、模塊裏放基座 SPI 實現，負責一個個業務邏輯片段，但還需要多個模塊搭配在一起才能組裝出一個完整的業務，即需要具備多個模塊組合運維的能力；2、中台業務基座一般會暴露一套統一服務來承接業務流量，但又經常有業務隔離部署的訴求，因此希望將機器資源劃成幾份，安裝不同模塊服務不同業務。如果對服務不做區分，就會出現業務 A 的請求打到業務 B 的機器（只部署了業務B相關模塊）上，請求失敗的情況👇：

我們將參數發佈和代碼發佈解耦，並定義場景的模型（場景=模塊組 + 流量單元），一個場景可以圈多個模塊，一起打包部署，一個場景發佈出的服務可以通過場景 id 作為服務 id。這樣每個場景都有自己特有的一套服務，和其他場景完全獨立。✅通過這種「拆」服務的方式，實現了業務流量隔離。

即使代碼相同也可以發佈不同的服務，通過這種方式我們實現了 AB 測試能力。

在線多版本與代碼實驗

Arec 作為面向算法 FaaS：實現線上並行化的 A/B 實驗能力，需要豐富整個 A/B 實驗的生態，是產品的核心訴求。

1、當時的 Arec 僅能支持三個在線版本同時運行：基線 Base、切流 UP、壓測 LT。單一的開發、測試版本能力不滿足多人協同研發的訴求。原來針對同一個場景，多位算法、工程同學需要創建多個同名前綴的場景單獨驗證。例如，主場景 feeds_v1，就可能同時創建了 feeds_v1_01，feeds_v1_02， feeds_v1_03，分別用於不同研發同學研發、驗證與實驗。

2、並且在實際多人協同研發的場景下，同一算法、業務實驗，工程代碼的驗證往往我們需要推進到切流、甚至基線階段，才能看到工程代碼對於算法的效果，原本基於原有的純參數 A/B 實驗能力，難以支持代碼實驗的訴求；

具體方案

在線多版本

在產品優化中，我們明確支持多個版本在線同時運行，並且可以支持指定版本和白名單測試的能力，讓一個場景能同時支持多位算法、工程同學在線研發、驗證和實驗。

【2.0 產品設計】針對多版本問題，我們基於原來三個版本的類型，加入了開發版本類型，和驗證階段的概念：

• 驗證階段：支持多個開發版本的代碼同時運行在線，並且支持指定版本和白名單指定驗證的能力；
• 切流階段：保持原 1.0 的產品設計，用以可發佈版本的線上端到端流量的驗證；
• 基線階段：保持原 1.0 的產品設計，用以線上完成功能、實驗驗證的推全版本；

代碼實驗

基於多版本在線運行，以及指定版本驗證的能力，將在線運行的代碼 A（基線CTR=1.0）進行 A/B 實驗，以此獲取到具體的算法產出結果，用於判斷代碼B（實驗組）是否會大面積影響了算法的指標（CTR=0.5/1.5），用於決策代碼B（重構、大規模改動）是否可以進行推全發佈。

• 為了不影響業務實驗的邏輯，我們將業務實驗的流量單元和代碼實驗的流量單元獨立出來，代碼實驗的決策優先級高於業務實驗，待代碼版本確認後，再繼續執行業務實驗的參數合併邏輯；
• 【代碼實驗】代碼實驗的流量單元決策當前 PV 所執行的版本，通過達爾文的參數實驗能力，在 A/B 實驗參數中決策出當前流量所命中的代碼版本，例如 Version=重構。而基於我們可指定版本驗證的能力下，Version=重構的流量將直接命中重構代碼的邏輯，並且返回相關的實驗指標，反饋到實驗桶中，用於基線版本和重構版本之間各類指標的體現。
• 

Serverless 調度與彈性伸縮

隨着支付寶業務的快速發展（包括但不限於首頁、Tab3、生活管家、醫療助理等），截止 2024 年 7 月，Arec 平台目前使用和管理了幾十萬核的 CPU 資源，承載超過幾百萬 QPS 的峯值流量。

在降本增效的背景下，結合多方面的目標和長期問題的暴露，如何建設並優化形成一套有效的、高效的、低成本的資源管理和優化能力，成為 Arec 當前階段亟需解決的問題。

我們通過將資源分配的調度粒度細化到更小的模塊粒度（也正是我們當前正在做的優化方式），通過提供預熱集羣、業務集羣和模塊的擴容，跳過基座冷啓動階段，轉而直接進行模塊等代碼片段的安裝，可以讓彈性的速度更快，資源部署的密度更高。

基於非對稱部署的場景混部提升平台資源利用率保障場景資源訴求

Arec 承接了上千個活躍場景，支撐的服務器集羣達到了幾十萬核級別；隨着業務接入越來越多，對機器的需求量越來越大。當集羣達到一定的規模之後，機器成本是必須要考慮的，不可能無限制擴充。那麼，如何在資源有限的情況下支撐更多的業務？必要的就是提升資源利用率。

針對資源利用率的提升，雲原生領域已經有成熟的思路，即資源調度，常見的產品有開源的 K8S 。為什麼資源調度能夠提升資源利用率？簡單來講，調度就是通過各種技術手段提升機器部署密度把機器資源充分使用上。

為什麼已經有基於 K8S 的成熟產品了還需要做 Serverless 資源調度？

兩者面臨的調度場景是不同的。

• K8S 調度的粒度是 Pod，Pod 與應用的比例是 1:1 ,他解決的問題是如何把各種規格訴求的應用部署到按照各種規格虛擬化後的 Pod 裏。比如一台物理機有 32C，可以把他虛擬化為一個 16C 和2個 8C 的 Pod，然後就可以把一個規則為 16C32G 的應用和兩個 8C16G規格的應用部署到該物理機上。
• 而 Serverless 調度的粒度是模塊，雖然 Arec 是一個應用，可以在上面安裝多個模塊。模塊的啓動速度更快，與傳統 K8S Pod 的啓動速度有很大優勢；模塊佔用資源小，可以在模塊這層將資源部署密度做得更高。

與 K8S 類似的， Serverless 做模塊資源調度也要做以下兩大能力：1、場景混部 2、非對稱部署。

場景混部

Arec 上運行着上千個場景，而且場景各異，有的只有幾 QPS，有的卻有幾萬 QPS。考慮到螞蟻的應用部署架構有 8 個 zone，而每個 zone 為了避免單點至少需要 2 台機器，那每個場景至少需要 82=16 台機器。頭部場景流量大，獨立部署可以將資源充分利用起來，但是長尾場景如果都按照獨佔計算的話，假如長尾場景有 1000 個，那至少需要 161000 = 16000 台機器，這個規模是驚人的，無法讓人接受的，通過混部可以將資源利用起來，實際運行中 1000 台機器就將長尾業務支撐起來，直接可節省 1w+ 台機器。

非對稱部署

如上圖（基於 Koupleless 模塊化架構），是對稱部署還是非對稱部署是針對一組機器來講的。如果一組機器上部署的模塊/數量相同（對應到 K8S，意味着一組物理機上都部署着相同的 Pod），那我們稱之為對稱部署。相反的，如果一組機器中，有的機器部署着 3 個模塊（對應到 K8S 就是 3 個 Pod），而另一個部署着 5 個模塊，或者説有的機器部署着 A、B ，有的機器部署的 C、D，那我們就稱之為非對稱部署。

資源隔離其實是對虛擬化後的容器做了個規格約束，可以類比於普通應用的規格。當做完資源隔離之後其實我們就能夠對 Arec 的場景設置規格。比如一個小的場景將其約束規格為 2C4G，稍大一點的約束為 4C8G，再大一點的約束為 8C16G，這樣就能夠比較準確的評估出場景所需要的資源，可以稱之為場景副本數，也就是虛擬化後的容器部署個數。不同的場景流量不同，邏輯不同所需要的副本數也就不同。Arec 整體集羣的機器數是一定的，而不同的場景需要的副本數不同，那就無法做到所有的場景都平鋪到集羣的所有機器上，因此 Arec 需要做非對稱部署。

該非對稱部署方案滿足了 Arec 的兩個訴求：

1、親和與非親和部署類比 K8S ，消耗資源高的場景容器不能部署到同一台 Pod 上，避免由於容器隔離不徹底導致兩個場景都受影響。存在場景互調的場景儘可能部署到同一台 Pod 上，由於推薦場景 tr 請求的 request 和 response 都很大，這樣可以減少序列化和非序列化消耗。

2、提高部署密度提升資源利用率把資源進一步細化分隔，從而把碎片化的資源利用起來。舉個例子：一個場景有隔離訴求，按照螞蟻 K8S 現在的調度，有 8 個 zone，那流量再小也要最少 16 台機器；但是對於流量小的業務 16 台機器根本無法將資源充分利用起來。

多目標彈性決策降低彈性對業務的影響

在執行彈性的過程中，只有準確的評估出服務的運行情況，才能夠更好地保證彈性的穩定。

Arec 上運行着上千個異構的場景，各個場景的邏輯不同，有 IO 密集型的，有 CPU 密集型的。有的場景 CPU 達到了 80%，服務成功率還能保持在 99%，而有的場景可能 CPU 只有 40% 就已經出現大量超時和抖動了。所以，準確的評估場景的運行情況是決定彈得穩定的關鍵。

在評估場景能否正常運行時，除了 CPU、load 等基礎指標，還需觀察場景的超時情況、異常情況以及降級熔斷髮生的情況才能準確反映運行情況。基於此，Arec 建設了多目標評估的彈性。目前 Arec 的評估指標包括：

• 超時
• 異常
• 降級
• 限流
• 熔斷
• CPU 利用率

在彈性縮容的過程中通過多批次、多目標的評估執行，保證彈性的安全平穩。

彈性算法

Arec 基於 Metrics 提供了基於過往峯值的計算決策 Base Max、基於過往均值權重的計算決策 Base Weight，聯合 OPTK 的時序預測算法，提供了不同的彈性決策算法能力。

而 OPTK 是一個主要針對互聯網、金融等產業應用中的多種垂直領域超大規模優化問題，螞蟻自研的一套高效分佈式數學規劃求解器套件。OPTK 從【領域問題建模與抽象】【求解算子和算法】及【分佈式引擎】三個方面提供了全方位的統一求解套件。

彈性配置化

在收穫到上述的成本優化結論和實踐後，Arec 將業務集羣日常的運維委託交付到 SRE 手中，減輕平台日常的運維成本，並且提升 SRE 可自主化運維的可控性。針對不同集羣可以開啓不同的彈性算法，例如：時序預測、歷史峯值決策、算比決策等。

因此 Arec 定義了一套聲明式設計，以及可調整的配置內容。API 與 Config First，減少 UI 開發成本和鏈路健壯性。未來還將持續擴展更豐富的配置策略，支持不同的訴求：按時、按天、不同 Metrics 決策、獨立 Zone、全量 Zone 等；

階段結果

當前所有 Arec 的算法與流量都運行在基於 Koupleless 建設的 Serverless 能力之上。除了隔離和業務穩定性得到保障外，還支持了日均 1000+ 的工程師協同研發，個性化場景分鐘級上線，日均  CPU 利用率從原來的 17% 提升到  27%。

未來規劃

1、極致的搜推 Serverless 的生態建設，包括但不僅限於：研發、運維、高可用、彈性、實驗、特徵數據等；

2、綠色計算的優化與生態能力共建，包括但不僅限於：決策算法、彈性能力等。

Koupleless star 一下

https://github.com/koupleless/koupleless