騰訊雲 Serverless 函式跑在 K8s 上,突破企業服務新格局

騰訊雲原生發表於2023-04-24

背景

自 2013 年提出以來,Serverless(無伺服器)作為遮蔽伺服器、按呼叫計費、事件驅動、彈性自動伸縮的計算服務,深受開發者喜愛,被稱為雲原生未來發展的方向。

最新的調查報告顯示:在核心業務中使用 Serverless 的使用者達到 18.11%;已經開始和計劃使用 Serverless 技術的使用者超過了 70%。根據 Datadog 資料,有超過 50% 的使用雲服務的企業或組織使用了 Serverless 技術。

但是,當開發者從創業階段過渡到大型企業階段,原來的 Serverless 模式逐漸給企業的管理、運維以及財務等帶來一系列的挑戰,這也是當期Serverless很難在大型企業全面應用的根本原因,為了破解這樣的難題,騰訊雲工程師從深度分析癥結,推出了順應企業發展需求的技術,打造真正服務於企業的 serverless 平臺。

Serverless 的從 1 到 100:企業又愛又恨
Serverless 為一個新業務提供了理想的從 0 到 1 孵化體驗——開發者只需要關注業務邏輯開發,業務所需的底層資源規劃運維由雲平臺處理,輕鬆應對上線後的流量增長,同時,業務的成本支出由業務的真實請求呼叫量決定。可以說Serverless給開發者真正帶來了上線足夠快,服務足夠穩,花費足夠少的完美“創業”體驗。

然後,當這個業務在 Serverless 的幫助下成功跨越 0 到 1,開發者成長為企業,來到從 1 到 100 的精益經營階段,Serverless 技術的應用開始出現問題——

  • 按呼叫計費模式從“蜜糖”變成“毒藥” ;
  • 全託管的計算服務無法滿足企業更進一步的管控、觀測、定製需求 ;
  • 自成一體的釋出流程、資源 quota、許可權體系,企業內部的研發中臺團隊不好統一管理,出了問題還得背鍋 ;
  • 完全的公有云形態制約了企業在跨雲、混合雲等特殊環境上的可選擇性。

這些問題讓企業對 Serverless 又愛又恨。以金融行業為例,不少大行等均嘗試在內部自建 faas 服務。K8s 社群近年來也一直湧現各類 FaaS 框架,例如 Keda、Knative、OpenFaaS 等。當然企業自建目前問題也不少,投入大、維護難、效果不佳,也導致自建的 FaaS 在內部往往承接業務上量不多。

面向開發者設計的 Serverless,需要為企業重新思考。只有服務好企業,才能真正意義上將 Serverless 發展為雲原生開發模型,實現 Serverless 自己的 1 到 100。

企業真正需要的是“雲原生 Serverless“

2017 年,騰訊云云函式 SCF(Serverless Cloud Function)釋出後不久迎來了第一批種子使用者,每個月 100 萬次呼叫量免費額度,幫助使用者零成本發展業務,其中不少使用者發展良好,最終拿到更大的投資,業務越做越大。

其中,有一家做跨境電商業務的 A 公司就是典型代表,2018 年成立,2021 年拿到上億融資,期間企業用雲體驗也發生了顯著變化。2018 年 ~ 2020 年,作為創業公司需要快速響應市場需求,A 公司的技術棧完全基於函式 FaaS 架構搭建——

  • 用事件函式 + 訊息佇列觸發器實現商品資訊的採集分析入庫;
  • 用事件函式 + 定時觸發器實現離線的資料批次處理;
  • 用 web 函式 + API 閘道器實現 api 服務;
  • ……

2020 年前後,一直不溫不火的國內跨境電商業務,突然爆發,A公司屬於該賽道的 Top 選手,業務也隨之迅速起量,從年初每月幾百上千塊用雲成本,到了年底增長到每個月過百萬,研發團隊也從幾個人,快速擴張到了幾百人。A公司的全量業務一直以騰訊云云函式SCF作為業務的計算平臺,終於在 2021 年拿到了新一輪融資。

然而接下來, A公司卻開始考慮把部分業務從雲函式往容器遷移了,這讓我們倍受困擾,透過與客戶研發負責人深度溝通,以下幾個非常現實而又不得不承認的核心問題擺在了我們面前:

業務複雜度與管理需求升級,Serverless 對企業的管理團隊造成衝擊

業務發展壯大,不可避免要引入行業主流人才,對業務線進行拆分,對研發工序進行分層。這個過程融合了管理流程升級和技術棧轉移。

拆分業務線後,各業務線開發自己的模組,保持業務線的快速迭代效率,但完全的業務線自治在企業內部自然會導致資源配置冗餘和浪費,於是中臺開始搭建,統一的服務發現、治理機制開始上線。這些都和 Serverless 從開發到釋出一竿子插到底的全棧自助模式有衝突。

快速擴張的團隊,引入的行業人才都是帶著多年工作經驗進來的,他們或熟悉某些開發框架,或熟悉某些架構模式,為了快速上線業務,這些框架和架構模式也會被開綠燈,在內部生長開花。Serverless 需要一些改造或對接在這個過程就會被嫌棄,更靈活自由的容器平臺受到青睞。

基礎設施的掌控度升級,Serverless 對企業的運維團隊造成衝擊

拔地而起的中臺團隊承接了運維、研效治理的工作職責,他們有多年的機器運維經驗、核心指標觀測經驗。Serverless 完全託管免運維的黑盒模式在這時也逐漸帶來一些問題,業務團隊想用攔不住,出了問題(比如說程式碼寫的不好 OOM)還得背鍋。

業務線的擴充也引入了更多的系統,如大資料的 Spark、Flink,中介軟體的 Kafka、Redis,資料庫等等,隨著雲原生的大發展,基於 K8s 底座的統一資源管理和運維工具鏈也更加成熟。在這個底座上,每個業務線都可以用資源 quota 進行管理,Serverless 獨立的併發配額彈性資源讓平臺運維對資源不再可控。

同時,隨著業務的擴張,企業也在籌備著進軍不同國家地區的計劃。不同國家地區有更多的安全合規要求,這也要求系統服務能響應這些要求上雲或下雲。Serverless 只能跑在公有云就成為阻礙計劃的絆腳石。

預算和採購需求升級,Serverless 對企業的財務團隊造成衝擊

Serverless 的按量計費模式替代了傳統的包年包月,讓財務規劃異常困難。

按量計費是典型的線性計費模型,按照業務的實際用量,成本線性增長,這對於孵化期的業務是減少早期投入降低成本的好機制,但對於穩定增長的業務來說,則是越來越重的成本負擔,業務規模越大,成本越高,完全沒有收斂的意思,成本不再可控。

讓 Serverless 函式跑在雲原生 K8s 上

企業擁抱雲原生,企業內的開發者擁抱 Serverless,融合帶來完美平衡

Serverless 對一個上規模的企業,引入的是管理、財務、基礎設施掌控等方面的問題。而我們回過頭來看,Serverless 對企業內的開發者依然是最優解。企業裡的業務開發者也是開發者,他們專注在需求轉化為程式碼這一過程中,不喜歡和機器、節點打交道。一個類似 Serverless 的自助開發平臺可以最大程度上幫助業務開發實現最高效率。

另一方面,隨著雲原生的大發展,企業的用雲體驗逐漸統一,K8s 成為事實上的標準,每一個上規模的企業都在基於 K8s 底座實現著自己的管理、財務預算、基礎設施掌控等需求。這是雲原生概念之於企業的最核心價值。

現在,我們思考的是,在當下如何找到 Serverless 和企業的雲原生訴求的結合點,讓企業在基礎設施掌控度和業務高效開發之間找到一個平衡。因此騰訊雲提出“雲原生 Serverless ”理念,構造了全新的 Serverless 產品形態騰訊雲Serverless雲函式 SCF on K8s。

SCF on K8s 實現 serverless 能力同時跑公有云和私有云

騰訊云云函式 SCF on K8s 將 SCF 的開發工具棧和公有云資源池進行解耦,讓 SCF 的整套能力可執行在企業自己的 K8s 叢集中,可完整複用企業已有資源。同時,SCF 完整相容 K8s API 和 RBAC 許可權體系,方便中臺團隊快速整合 SCF 能力,無需重複對接。有了 SCF 能力,中臺團隊也無需從頭構建開發工具棧。

如下描繪了 SCF on K8s 在企業研效流程中的結合:

騰訊云云函式 SCF on K8s 不僅讓企業內的業務開發者擁有公有云 SCF 一樣的開發體驗,也讓中臺運維團隊可以從研發流程到資源管控到可觀測上管理 SCF,同時,跑在企業統一的 K8s 資源池中,讓財務預算工作也更好展開。

SCF on K8s 可無縫整合到企業已有技術中臺,滿足企業多雲跨雲需求

SCF on K8s 可以滿足企業多樣的用雲需求:從 0 到1階段的公有云彈性資源模式,讓企業快速試錯;從 1 到 100 階段的混合資源池模式,讓企業選擇最經濟的方案,無需被公有云繫結,在自己的基礎設施上使用 Serverless。

SCF on K8s 完全相容 K8s API 和許可權體系,並提供了 CRD,中臺團隊可像管理 Workload 一樣管理 SCF。

  • 統一的研效流程管理:

業務開發者遵循研發審批流開發、測試、釋出,全程都在中臺團隊管控之下;

  • 可控的資源 quota:

業務開發者根據需要申請資源 quota,中臺團隊透過 K8s 叢集資源管控來進行資源供給;

  • 可觀測的 SCF:

SCF 跑在 K8s 叢集中,相容 K8s 本身的PVC、服務發現、監控日誌機制。

SCF on K8s 和公有云 SCF 的能力保持完全一致,業務開發者只需選擇自己熟悉的程式語言、IDE 完成程式碼編寫,透過 SCF 命令列工具或中臺團隊提供的釋出流程完成程式碼的釋出,最後配置觸發器和 算力(CPU 或 GPU)即可。真正專注於業務需求實現。

在大型企業的研發模式中,微服務是佔據主流的存在。不同業務開發各自的服務模組,同時又能由服務發現、服務治理等中央服務實現統一管理。非常符合企業的統一納管,分而治之的理念。而微服務也存在過於複雜的問題,快速迭代的業務使用微服務體系,研發效率會偏低,一次釋出需要半天對於敏捷研效是個巨大的挑戰。

SCF on K8s 可以和微服務體系實現補位,對於快速迭代的專案,可先採用 SCF 實現高效開發,快速釋出;待專案成熟後,再轉為微服務體系。微服務在線上場景上生態豐富,表現卓越,而對於近離線場景的資料處理、影片轉碼等事件觸發型服務,則可使用 SCF 實現,不管是開發效率還是資源利用率都能更高。

業界首創在離線混合資源池模式,有效提升 K8s 叢集資源利用率

騰訊云云函式SCF on K8s 支援配置資源配比,將 K8s 叢集資源和公有云彈性資源搭配使用。在該模式下,函式請求優先排程到 K8s 叢集,函式排程層感知到 K8s 叢集資源不足時排程回函式公有云資源池。如此以來,企業可根據業務實際請求量,配置一個打底的 K8s 叢集滿足日常資源所需。同時,利用函式公有云資源池,響應高峰期的溢位資源所需。在實現業務高可用的同時,實現最經濟的雲資源採購。

K8s 叢集基於 Virtual Kubelet 抽取閒置資源,成為離線算力,將一部分低優的任務排程過來,這些任務會在有資源供給時執行。該方案不僅在業務排程層較為複雜,也存在挑業務的情況,需要業務能接受較長的等待時間,同時,低優任務如果不及時釋放資源,又會反過來影響線上業務的資源供給。

而將 K8s 離線算力作為虛擬的 K8s 叢集繫結到函式服務,再開啟混合資源池,這些問題將迎刃而解——

  • 不挑業務:

函式的主動排程機制在 K8s 離線資源有供給時立即排程任務執行,沒有時及時排程回公有云資源池,保障任務始終可以執行;

  • 不影響線上業務:

函式的超時配置限制任務的最長執行時間,執行完或到了超時時間會立即釋放資源,最大程度保障線上業務的資源供給;

  • 業務排程層簡單易用:

只需要將任務釋出為事件函式,配置訊息佇列、定時任務等觸發器,並開啟混合資源池配置即可。

騰訊內部的實踐

TKE 容器服務在騰訊集團內部作為統一的應用研發管理平臺,在標準的 K8s 能力之上,提供了跨叢集、跨 zone 的容器資源排程管理能力和應用維度的運維治理能力,也是技術中臺的一種實現,在過去的三年裡很好的支撐了騰訊集團業務全面雲原生上雲。

騰訊云云函式 SCF 作為 Serverless 的落地實現,在集團內部同樣深受業務開發同學的喜愛,例如大家熟悉的騰訊文件、騰訊會議、騰訊地圖、企業微信等都有大量的服務是基於函式開發上線。

在具體的研發模式上,核心業務邏輯和重點的線上服務主要是用微服務架構實現,服務管理、流量管理、故障容錯和配置管理用北極星做了統一治理。函式主要用在以下幾個場景:

  • 前端的 SSR 和 BFF 場景,例如騰訊文件的表格、演示文件的 SSR 用函式實現;
  • 近線資料處理場景,例如騰訊地圖的導航資料計算、地圖瓦片資料的計算等用函式實現;
  • 離線任務場景,例如運維團隊的定時巡檢任務和定時撥測任務、計費團隊的定時賬單彙算任務等用函式實現。

這些場景中,函式以其靈活高效且免運維的開發體驗很好的支撐了業務發展。但獨立的按量計費模型也給業務團隊的財務預算帶來了挑戰:不好預估專案的成本支出,業務增長帶來使用量上漲後,按量計費的總費用相比採買一批機器不夠划算等,在集團降本增效的大環境下,成為業務團隊的一塊心病。

22 年 11 月,騰訊云云函式SCF on K8s 透過“任務中心”的產品形態整合到 TKE,拉通賬戶許可權體系,相容統一的釋出審批流程和預算 quota 申領機制。

上線後,目前已經有大量的 K8s job、cronjob 遷移到 雲函式SCF 任務平臺,不僅開發簡單,且在任務的響應延遲等技術指標上存在量級上的提升。

不少之前使用公有云函式實現的業務也遷移過來,相容了 TKE 的 quota 申領機制,業務團隊可以在傳統的函式按量計費模式和批次採買容器作為函式的執行資源池之間選擇。對於量級較大的業務來說,後者是控制成本的最佳措施,降本增效環境下的心病解除。

Serverless 終將跑在每一個基礎設施之上

無可否認,Serverless 仍然是企業用雲的終極理想形態,只需關注核心業務邏輯,其它的一切交給算力供給方搞定,是精益經營的經濟體決勝於市場的基本邏輯。然而,這是一個漫長的進化過程,參與其中的每一方都要發展,例如,Serverless 的函式粒度的開發模式,需要更優秀的人才梯隊能夠將業務需求拆解的更細,而更細更多的模組則又需要更強大的服務治理機制…… 類比到傳統制造業,就是從工廠裡的生產工序、流水線到上下游供應鏈都要整體升級,最終才能達成工業革命。這需要一些時間,也許是 5 年,也許是 10 年或更久。

在我們抬頭仰望星空的同時,也要踏實走好腳下的每一步——如何讓企業用足夠小的代價換取最大的收益,是每個雲廠商都要積極思考並探索解決的課題。從公有云 Serverless 到雲原生 Serverless,也許部分廠商會認為是一種退步,而也許恰恰相反,只要改變本身能解決多數企業的痛點,為企業帶來真正的價值,它就是進步的。

可以預計,隨著 Serverless 正規化的逐漸完善,Serverless 終將跑在每一個基礎設施之上!

SCF on K8s 搶先體驗指南

SCF on K8s 資源託管模式目前已經全量開放,登入 - 騰訊雲,趕緊試起來吧!

建立函式名稱空間並繫結 TKE 叢集

1.登入 - 騰訊雲,單擊左側導航欄的函式服務。

2.在函式服務頁面上方選擇期望建立函式的地域,單擊名稱空間右側的⚙️,進入名稱空間管理。如下圖所示:


3.在“名稱空間”管理彈窗中,單擊新增名稱空間,進入名稱空間建立彈窗。如下圖所示:

4.在資源託管模式選項中,選擇 K8s,並選擇對應的 TKE 叢集完成繫結即可完成設定。設定完成後在名稱空間下建立函式即可開始使用。

【騰訊雲原生】雲說新品、雲研新術、雲遊新活、雲賞資訊,掃碼關注同名公眾號,及時獲取更多幹貨!!

相關文章