本文作者：ydx
背景
雲主機時代，資源焦慮幾乎普遍存在。突增的巨大任務量、短時間突然調集使用大量的計算資源等型別的業務需求越來越多，企業不願為了應對短暫的流量高峰買本地資源，對服務和擴縮容進行解耦，並接管過自動擴縮容任務的 Serverless 進入大眾視野。
Serverless 自帶“降本增效”基因，特點之一就是可以縮容到零之後再按資源使用情況收費，這自然吸引了大量企業使用，網易雲音樂便是其中之一。
最早，網易雲音樂主要使用雲廠商的 FaaS 產品。隨著 Serverless 社群的發展，2020 年，網易雲音樂開始關注到 Google 開源的 Knative 專案，到了 2021 年 5 月，團隊決定優先利用內部的私有云資源，在滿足業務的非同步處理事件以及彈性擴縮容需求的前提下，透過線上和離線服務的混合部署，提升系統資源利用率，同時完成降本增效目的。
於是，在做了簡單的 POC 測試並與業務溝通後，網易雲音樂便協同網易數帆雲原生團隊面向音影片處理，打造了基於 Knative 的 Serverless 解決方案。
如何做技術選型
網易雲音樂每天都有數十萬的歌曲入庫，曲庫團隊則需要對這部分歌曲做準實時的加工處理、理解分析（包括歌曲轉碼、副歌識別、特徵分析等），相關處理結果用於歌曲播放、VIP 歌曲試聽等業務場景。這類業務的特點就是彈性特別大，任務時多時少，多的時候甚至要對大量存量歌曲資料進行重新計算。這就對資源交付方式提出了新的要求。
按照網易雲音樂在雲主機時代的使用經驗，傳統的資源交付方式主要存在以下幾個問題：
• 彈性效率低下：大型活動業務擴容時，各個角色如應用運維、機房等深度耦合，進行一次大型活動需要非常長的準備時間。
• 計算焦慮：由於規模問題，機房計算資源沒辦法實現在活動期間的快速資源彈性需求，因此常常需要準備很多閒置資源。
• 運維繁瑣：擴容變更時，很多是以工單、人工化為主的低效過程，無論效率還是質量都不盡如人意。
• 成本問題：總體 CPU 等資源利用率不高，小於 20%，缺乏自動化的管理和排程能力，資源無法得到充分利用。
• 穩定性：應用發生故障後，無法自動重新拉起或重新排程，核心業務的服務質量很難得到保障。
雖然基於 Kubernetes 以及生態裡的很多創新雲原生解決方案，上述棘手問題得到了一定程度的解決，但 Serverless 的解決方案相對來說更加高效易用。Serverless 向業務提供了語言無關、框架無關的研發模式，透過自動化 Metric、自動擴縮容等手段讓業務聚焦業務邏輯，無需關注周邊與資源擴縮、沒有伺服器管理，降低了程式生命週期中的大量運維成本。
當前，Serverless 大概有三個技術方向：Serverless 容器服務、Serverless 應用託管和函式計算（FaaS）。
使用 Serverless 容器服務的使用者不需要維護 Kubernetes 叢集的計算節點，系統根據服務使用的 pod 數量進行計費，但 Serverless 容器服務並不能提供完備的周邊配套設施；Serverless 應用託管則會包含應用生命週期的管理、CI/CD、釋出策略，藍綠或者灰度釋出功能等，使用者只需將服務部署後就能坐享應用託管所提供的基礎能力；函式計算的抽象程度更高。對於 Python 等解釋類語言，開發者使用 FasS 將程式碼片段上傳後，函式計算的底層便可快速將服務對外部署，從而實現對外服務。
在雲原生團隊看來，Serverless 應用託管或 FaaS 平臺相對來說是更好的選擇，因為業務不只需要彈性伸縮功能，還要解決 CI/CD、釋出策略、訊息引擎等問題，做更好的開發封裝。只有涵蓋了這些周邊配套服務，才能將開發的心智負擔降至最低。方向確認後，具體怎麼做呢？
容器映象需要基於程式語言的定製化編譯和構建，從而生成二進位制的檔案，最後再經過 Dockerfile 將其構建成容器。但是，曲庫團隊內部有多種語言所開發的演算法，很難用通用的流水線進行容器映象構建。因此，曲庫團隊內部只要求底層 Serverless 平臺或 FaaS 平臺能夠接受 Dockerfile 即可，具體 Dockerfile 怎麼寫則由其內部自行消化。
因此，雲原生團隊的任務就是將曲庫團隊上傳的 Dockerfile 進行映象構造。雲原生團隊為此進行了一次全面調研，內容包括訊息引擎對上下游解耦及彈性擴容的需求、相關開源軟體（Knative、OpenFaas、Fission、Nuclio 等）與需求的匹配度對比，最後確定基於 Knative Serving 做動態擴縮容、基於 Knative Eventing 構建事件處理框架。
<img src="https://p6.music.126.net/obj/wonDlsKUwrLClGjCm8Kx/25949541187/6712/7b66/ddce/748dd98db07fc18dbb2f5edb65818e66.jpg" alt="pic" style="zoom: 50%;" />
在如何進行技術選型上，網易數帆雲原生架構師閆東曉表示主要有三點需要考慮。第一，產品一定要能夠滿足業務場景和應用場景需求；第二，關注產品背後的支援情況，比如 Knative 有谷歌、IBM 等大企業加持，OpenShift 背後有 RedHat 支援；第三，產品具有易用性，通常易用性是落地時團隊要幫助業務解決的問題，但如果專案足夠穩定，就不需要改變底層框架。
在眾多開源軟體中，Knative 的擴充套件性較好、可以選擇訊息引擎，並且生產和消費的客戶端可以以外掛的形式嵌入到 Serverless 系統中。因此，雲原生團隊最後選擇基於 Knative 對每個例項或建立的 Knative Service（類似 Kubernetes 的 Deployment）進行動態擴縮容。
當時的 Knative 本身還處於快速迭代階段，沒有穩定的版本，網易雲音樂使用的還是 0.20、0.21 版本。
2021 年上雲之後，網易雲音樂開始使用事件驅動架構。這次遷移期間，雲原生團隊還在 Knative Eventing 事件框架中內嵌了一個外掛（Knative 之中包含 Knative Serving 和 Knative Eventing 兩個專案），將訊息引擎 Kafka 也整合到了 Serverless 平臺之中。業務只需要在 8080 埠接收透過 Knative Eventing 事件框架轉發的請求，並透過 Kafka 觸發訊息即可實現事件驅動。
具體來講，業務將支援 Knative Eventing 格式的事件請求透過暴露的 URL 傳送到介面，再由介面將訊息轉發到訊息引擎，系統層面在監聽到事件觸發後會消費 Kafka 的訊息，最後再將其轉發給後端演算法進行處理。
自此，網易雲音樂擁有了一個非同步事件處理框架，在偏向離線的場景中可以慢慢地消費訊息，從而確保私有云底層的有限資源能得到合理、充分地使用。
這是一種通用技術，要求啟動的服務不依賴私有云節點，不能在宿主機上的某些路徑下存在檔案等依賴形式，否則會無法彈出導致啟動失敗。但如果所有依賴均在容器映象內部，或者可以透過執行時動態地請求依賴方獲取資訊，那麼就可以應用這種彈效能力。
遷移後，需要解決哪些問題？
冷啟動是 Serverless 使用時被重點考量的點。影響啟動速度的因素有很多，比如，容器映象大小不同，pod 的啟動速度也不同。部分廠商透過預先啟動部分 pod 的方式來解決冷啟動問題，但網易雲音樂沒有這麼做。雲原生團隊使用了更通用的解決方案，比如 Dockerfile 採用多階段構建、P2P 加速容器映象拉取速度等。
網易雲音樂的應用場景偏離線、非實時，因此對負載均衡和併發控制的需求比較高。音影片演算法每個 pod 可處理的併發度很低，理想情況是上游在下發請求時控制併發數量，確保每個 pod 都在處理自己能處理的併發請求。但是，資料鏈路上會有資料不均衡的情況，經過佇列的請求會超過 pod 可處理的併發數量上限，從而導致佇列阻塞和其他 pod 空閒。
為此，雲原生團隊調整了 Knative 內部的負載均衡演算法策略，從預設的 Round Robin 改為 Least Request，將請求發給併發處理數最少的 pod，讓每個 pod 都有任務。
另外業務對穩定性要求也很高，而業務穩定性主要體現在對上游併發的控制上。業務將服務請求全部傳送到訊息佇列後，如果將訊息全部分發給底層服務處理，那麼將擴容出非常多 pod；如果 pod 與線上應用在同一個 node 上，則勢必會影響線上應用的穩定性。因此，除了 Knative 本身所提供的服務外，雲原生團隊還收集業務指標並提供監控告警功能，來給業務信心。
透過與業務的需求溝通，雲原生團隊利用 Serverless 暴露出的資料鏈路指標資訊形成定製的視覺化看板，其中包括監控告警、擴縮容頻率、每個 pod 的負載情況、推送訊息的消費情況等業務基礎資訊，此外也有 Serverless 內部運維的巡檢監控，如 CPU、記憶體的利用率，消費佇列消費延時情況、業務化擴縮容實現等。
當監控效果不達預期時，雲原生團隊則需要調整或借鑑其他最佳化手段做提升。值得注意的是，這些監控指標收集都是使用的基礎 Kubernetes 系列開源產品，並不是 Serverless 獨有的。Serverless 是作為整個架構部分的存在，需要與其它產品配合使用。
在調優方面，業務研發可以自行登入容器檢視程式資訊，也可以透過日誌收集的方式檢視。除錯方面則使用了雲主機時代的遠端除錯方法，這種方式在容器化時代依舊可用。
為了完成“最後一公里”的交付，雲原生團隊在網易開源的雲原生應用交付平臺 Horizon 上交付了一個部署模板，曲庫團隊基於 Horizon 平臺填寫資料表單，雲原生團隊負責模板化例項生成。Horizon 平臺（開源地址：https://github.com/horizoncd）透過引入模板系統解決了各種應用負載標準化的問題，支援 Deployment、Argo Rollout、Knative 等負載，Serverless 平臺則複用了 Horizon 的部分基礎能力，進而為業務提供動態擴縮容和事件處理框架能力。
透過結合業務進行探索和迭代，網易雲音樂用了一年多的時間基於 Knaitve 構建了相對完善的 Serverless 平臺：
• 多語言的構建方式：包括 Dockerfile 、JAVA、Golang、Node、Python 等。
• 多場景：支援彈性線上應用和彈性資料處理，支援同步呼叫模式和非同步呼叫模式。
• 豐富的釋出策略：支援藍綠髮布和基於流量的灰度釋出，確保業務的無損釋出。
• 自動擴縮容：根據業務併發以及 QPS、任務量等實現秒級自動擴縮容。
• 全鏈路監控：全鏈路的採集指標、採集日誌，自動將資料整合到應用監控。
• 豐富的觸發器：除了支援 HTTP、還支援網易內部的 Kafka、Nydus 佇列作為 Serverless 觸發器進行資料處理。
• 無限容量：透過混合雲、混合部署等方式，快速、自動地透過 ECI 等方式彈到阿里雲、AWS 等公有云廠商。
落地效益如何？
“對於企業來說，如果一開始使用的是私有云，那麼在既有 IT 成本的前提下，Serverless 只是提升內部資源的利用率。但如果前提是公有云，那麼只要能保證容器不依賴於主機環境，那麼在解決資訊保安、日誌、指標監控等問題的前提下，Serverless 是一定可行的。”閆東曉表示。
目前，網易雲音樂內部大量使用 Serverless 平臺的場景包括音影片分析、AI 推理分析、前端 SSR、彈性日誌 ETL 等。Serverlesss 透過與線上業務混合部署的方式，大大提升了機房資源的利用率，峰值時超過了 50%，資源整體佔比達到 20% 左右。
網易雲音樂的 Node 負載有波峰、波谷之分，雲原生團隊希望在波峰時段減少 Serverless 的使用，並在凌晨 2-8 點左右提升資源利用率，執行 Serverless 的非實時任務。其中，波峰時段主要是內部私有云線上服務，這也是整個 Kubernetes 資源利用率的波峰。
如今，網易雲音樂的私有云上已經部署了超過 500 個 Serverless 應用，高峰期會使用 1 萬多虛擬核心。從內部 Node 級別的資源利用率來看，有 20% 的 CPU 核心供給了 Serverless 應用使用，透過線上離線混合部署，在不擴容機器增加成本的情況下，基本滿足了業務對底層計算資源的訴求。
網易雲音樂還可以做到優先使用自有機房計算資源，直到飽和時再使用公有云上的計算資源，比如將服務彈出到阿里雲的 ECI（彈性容器例項）上進行臨時的計算輔助，並在執行完成後將其縮容，從而完全解決資源焦慮，大大提高資源交付效率。需要注意的是，這是一種臨時呼叫，而非將服務固定在私有云和公有云上混合使用。
在接入 Serverless 平臺兩年以來，曲庫音影片平均使用資源的 CPU 核數日平均峰值 5000 核，日平均谷值 3000 核。同時，一部分演算法服務還藉助公有云的 Spot 彈性資源和包月資源，利用競價模式，持有彈性的 GPU，快速申請、快速釋放。雲原生團隊的調研顯示，即使是簡單的每天修改副本數，業務對這些彈性擴縮容手段的好感度也非常高。
另外在運維方面，底層運維的成本並沒有因為使用 Serverless 而增加，運維人員的實際操作量減少，將精力更多放在了 Kubernetes 的資源是否能滿足業務需求上。
不過，閆東曉提醒道，對於業務研發而言，雲原生團隊可以將同一類的工具鏈封裝得更穩定、使用更簡單，這時 Serverless 使用效率較高，但是對於非同一類工具鏈，如演算法等無法抽象出 CI 流水線的，收益就比較有限。
要不要用 Serverless
從雲廠商產品為主到基於開源產品二次開發，網易雲音樂的 Serverless 架構雖然更加貼合內部應用場景，但也需要花精力緊跟社群迭代。閆東曉表示，Serverless 也非“銀彈”，本身自帶如冷啟動方面啟動慢、銷燬時造成客戶端異常、對線上類服務不太能友好等問題。另外，在既有成本的情況下，固定副本數要比彈性擴縮容要好。
對於想要接入 Serverless 的企業，閆東曉建議可以從降本增效的角度，或者自有機房或私有云的系統資源利用率角度，看是否有偏離線的計算密集型業務。“一些離線應用往往會在短時間內需要大量的資源，這種需求往往也是一次性的。此時，可以考慮使用 Serverless 提升系統利用率。”
對於使用公有云的企業，如果直接將所有服務全部遷移到 Serverless 架構上，則更需要考慮各種風險，比如擴縮容過程中的冷啟動問題、服務啟停是否會影響業務、縮容時 pod 的銷燬是否會同時關閉未處理完成的使用者請求、擴容時 pod 建立是否夠快、是否會導致擴容時間內的請求高延遲等。
企業如果考慮使用雲廠商產品，閆東曉表示需要了解雲廠商的技術是否封閉、是否跟隨社群前進，否則之後做廠商切換、產品切換時都會比較麻煩。尤其如果雲廠商的 Serverless 產品在底層沒有統一標準，那麼平滑遷移必然會帶來成本問題。
如果內部只是將固定副本數的普通雲主機遷移至 Kubernetes，那麼對於封裝流水線和介面的方式，業務層感知不到底層上雲前後的差別，也不需要太多知識。但如果是使用微服務、選擇自身技術棧的情況，那麼使用方需要能提供 Dockerfile、自行將容器封裝執行，這就需要具備容器、Kubernetes 方面的知識，否則用起來會感到困惑。
結束語
網易雲音樂的 Serverless 應用還在繼續，比如網易雲音樂考慮在事件框架中引入 RocketMQ、排程方面會引入定時併發控制，以及充分利用硬體在波谷時段的資源等。總的來說，網易雲音樂 Serverless 的落地還是圍繞“降本增效”進行更細化的工作。
當然，對於整個 Serverless 行業來說，未來也還有很多路要走。Serverless 能否藉助當下企業對降本增效需求的契機得到進一步發展，我們也將拭目以待。
本文釋出自網易雲音樂技術團隊，文章未經授權禁止任何形式的轉載。我們常年招收各類技術崗位，如果你準備換工作，又恰好喜歡雲音樂，那就加入我們 grp.music-fe(at)corp.netease.com！