前言
在「RTE2022 實時網際網路大會」中，聲網雲原生邊緣計算團隊的負責人 @王浩宇 Dylan 以《RTE 場景下的 Serverless 架構挑戰 —— 聲網如何兼顧後端服務的可靠、高效和快速迭代》為題進行了主題演講。
這也是聲網第一次在 RTE 大會上，對外分享內部的一些後端技術實踐。相信大家也一直比較好奇，聲網如何在廣泛的 RTE 應用場景下解決服務的高效擴充套件問題。
以下內容基於 @王浩宇 Dylan 於大會中演講內容整理，為方便閱讀略有刪改。
01 實時互動後端技術演進
先看一下三個主要的業務需求：
一是不斷爆發的新互動場景。從 RTC 的影片、推流、錄製、鑑黃的基礎能力，到 RTE 的靈動課堂、互動遊戲、一起 KTV、空間音訊、AI 聲紋等等。現在的互動場景越來越複雜，相比以前僅僅需要滿足音影片的互通，已經到了需要同時兼顧複雜的信令過程、複雜的資料互動。
二是追求更加穩定可靠的極致質量。從原本的低延遲、低卡頓率，上升到 RTE 實時互動體驗的質量標準 XLA；需要去支援異常情況下的智慧容災，異常自動恢復。
三是敏捷高效的大規模擴充套件能力。實時擴容，支援超大規模的業務場景彈性，以低成本覆蓋全球各個國家和地區。
以上這些，都是讓實時互動更加易用、更加普及的能力和需求。
在講聲網如何解決這些場景需求之前，我想先跟大家講一下這些年在各種邊緣雲和公有云場景下，當前的一些典型架構模式。
在邊緣上最傳統也最成熟的模式是 CDN 的分發。這種架構經歷了幾十年的演進，已經非常的成熟穩定。最常見的場景像基於 CDN 的直播、邊緣函式、IoT 等等。
基於 CDN 的場景也能夠高效的滿足彈性、擴充套件、覆蓋的問題。它的優勢在於，這樣的一個簡單靜態配置，一般只用關注一個鏈路切換就可以實現橫向的邊緣擴容。但這種場景下只能解決分發、傳輸和接入能力，沒有辦法去實現複雜的多項互動的業務。
現在的網際網路業務幾乎都是雲化的，公有云場景經過這些年的發展，幾乎能支援一切的網際網路業務。它具備完備的儲存、計算、事務等各種雲服務和中介軟體的能力，易用性和擴充套件性良好。但有一個問題是鏈路很複雜，用了雲之後意味著重度依賴基建的可靠性，任何一環都不能出問題。
大家也知道聲網基本是不用公有云的，也用不了 CDN。我們提出了自己的實時互動邊緣雲，希望能在我們的邊緣雲上同時具備邊緣的靈活和雲的強健，能夠在邊緣實現複雜的實時互動邏輯，不依賴專線實現可靠傳輸，解決資料和狀態的全球同步。
我們希望做到又快又好，在任意環境都可以執行，覆蓋全球的每一個角落。去支援從密集計算的突發任務，到有狀態服務在內的任意負載，能夠去 Serverless 化，支援動態的資源分配和彈性伸縮。
不同於傳統的中心化模式，聲網其實並不需要類似 CDN 的回源這類的核心節點，整體架構都做了去中心化。好處是可以徹底擺脫對機房和運營商的依賴，也不需要對基礎設施做很高程度的可用性保障。
另外一方面，雲的易用性帶來了複雜度的急劇增長，故障機率和影響範圍也進一步加劇。這些年不管是國際上的一些巨頭還是國內的一些廠商，基本都出現過大範圍的故障。並且如果是骨幹網或者運營商故障，很多情況下是沒有辦法挽回的，雲網路底層的 BGP 協議一旦在路由層面出問題，可能影響整個大洲。例如北美最近一兩年已經遇到過多次公有云幾乎整體斷網的情況。
聲網希望能夠在實時互動邊緣雲上做到真正的反脆弱性，所以會對任何的基礎設施去做一定的故障預設。我們的服務至少滿足 N-3 的冗餘度，意味著不會依賴任何單一的基建或者運營商，在任意區域均可承受 3 個機房故障不影響可用性。
02 實時互動 x 邊緣 Serverless
上述幾點在過去幾年我們反覆提及過，今天想要給大家講的是在邊緣雲的能力上，Serverless 如何進一步驅動業務創新。
這裡主要有幾個點：
- 提供了一致化的雲能力
不同的 RTC、RTE，包括錄製、推流、RTIC 等業務之間，都需要一個可複製的架構能力，去保障開發者在使用不同雲服務的時候，均能享受到相同水平的彈性，可擴充套件性和健壯性的服務。
- 完備的排程覆蓋和全球擴充套件能力
想要真正做到完備的排程覆蓋和全球擴充套件，不是單獨的某一個業務做到，而是需要所有業務都做到。我們的 Serverless 可以在有伺服器和網路的地方完成即刻覆蓋，不需要考慮機器的規格如何，透過負載均衡機制都能去實現最優的分配策略，滿足質量與負載的平衡。
- 專注於業務迭代
為了給開發者實現最大程度的價值，我們要滿足更快的需求交付。聲網內部研發在無需關注底層資源的同時，會享受到豐富的流量排程和灰度能力。對外大家能看到的實際體現，就是聲網這些年互動應用的不斷爆發。
- 高價效比
同時，我們也需要給開發者提供最高價效比的服務。聲網利用極致的靈活與彈性的邊緣資源，能夠替代公有云沉重的基建成本，不用去購買昂貴的公有云的頻寬以及專線。
在這些需求之外，聲網是如何真正在邊緣實現所有類似的應用落地，這裡面又有什麼挑戰？我想先用一個稍微有點複雜的小表格，來跟大家講一下。
在講挑戰之前，我們先提一個傳統意義上原生應用架構跟實時互動應用的區別。
雲原生應用很多時候大家都在講無狀態性，但所有的實時互動應用幾乎都跟流有關。streaming 意味著資訊的高效傳遞，所有的資料都在毫秒級的時間傳達到對方。我們沒有辦法再去做一個無狀態協議，把流做切片。
相信大家也知道，如果用 HLS 的協議去拉流，它的延遲比 RTC 會差出一個數量級或更多。所以在實時互動應用場景下，一定會選擇用有狀態的實時流服務去實現業務，追求在效能、成本、可能性層面，都做到極體驗致，但代價就是需要去管理這裡的複雜度，無論是擴容、遷移、升級、維護，擴充套件，一切都變得非常的麻煩。
過去雲廠商包括一些網際網路大廠，也都在做面向無狀態服務的 Serverless 架構，讓大家都能有各種各樣的函式服務去解決這種短暫無狀態應用，包括對冷啟動時間不敏感的場景，這是迄今為止 Serverless 的技術白皮書當中推薦的場景應用模式。但這樣的 Serverless 方案，從執行環境、API 到執行時間層面，都是層層受限的。
我們在實現一些像音影片之類比較重的業務時，不管是啟動時間還是業務的執行時長，或者是需要用到的各種各樣的 API，都會對基建能力和 Serverless 能力提出全新的高要求。
以錄製場景為例，最早聲網在沒有提供內部的雲能力之前，也是讓客戶用 SDK 錄製，也就是一個 Linux SDK。這種在服務端跑 SDK 的好處就是不受限，想實現各種各樣的業務場景都可以，非常靈活。
但是 SDK 錄製也有幾個非常顯著的問題：
- 機房/雲廠商網路波動影響錄製質量
- 擴縮容困難，部署維護複雜
- 跑起來簡單，高可用難
我們發現，如果要想把實時互動場景做好，必須要把各種各樣的複雜的有狀態服務，幫助客戶簡化複雜度，基於此我們推出了雲錄製。
當然除了錄製外，聲網還有大量其他的業務場景，因為時間關係我們就拿錄製這一個例子來舉例，也方便大家來理解。
簡單來說，開發者不再需要維護一個有狀態的服務，只需要調聲網的一個無狀態的 RESTful 介面，就可以完成頻道的錄製。
我們來具體看一下，錄製場景當中 Serverless 會帶來哪些挑戰。簡單來說這裡面有幾條：
- 不確定負載，根據主播人數幀率位元速率不同實時變化
- 有狀態持續性任務，頻道可能持續數小時乃至數天
- 保障任務唯一性的同時允許更新任務
- 強實時性和可靠性，無法接受丟路與黑屏
需滿足全球化場景，即使主播和最終錄製儲存區域不同。例如：
° 客戶伺服器在新加坡發起錄製
° 主播在中東接入 RTC
° 錄製檔案上傳到北美
通常來說，這些場景中的傳輸問題，客戶往往沒有辦法自行搞定。因此在實時互動邊緣雲場景中，聲網提出瞭如下圖所示的架構：
聲網有一套叫 UAP 的雲原生邊緣應用平臺，可以就字面意義理解為通用應用平臺。開發者可以在上面執行任意的應用程式碼。
中間是 RTE Runtime，可以理解為聲網內部的服務端 SDK。上面的任意應用程式碼可以被跑在任意位置，UAP 平臺會幫大家去管理資源編排、容量規劃、遷移管理、負載感知、智慧排程、動態組網在內的邊緣場景下的問題。
總的來講，我們希望透過對底層資源包括對邊緣複雜度的封裝，讓業務能夠只關注在最上層的應用程式碼的開發。同時大家也可以把這個平臺想象成一個 Linux SDK，可以用來做各種各樣的 RTE 的場景。
為了方便大家理解相關概念，給大家看一個簡單的例子。
上圖左下角是一個 golong 的例子，藉助 UAP 可以用一個非常小的 library 快速的把任意的程式碼邏輯整合進來。這裡的執行環境是不受限的，開發者可以用任意的容器負載放進來，同時我們提供一個完全雲原生化的應用規範和標準，做到分鐘級的部署。
上圖右側是聲網內部的一些 CRD。在這個 Demo Serverless 的例子中，我們定義了幾個 worker，用了一個自定義的 demo 映象，Request 的一部分資源。在分鐘級的時間內，就可以把這樣的一個 Demo Serverless 推廣到全球的各個邊緣上。
同時業務不需要管節點跑在哪、怎麼連到它，整個過程都是有動態註冊、動態分配的，這一點後面我們會詳細來講。
當然這是最簡單的一個整合的場景，還有很多其他的功能模組可以按需擴充套件。
下面來講一下，剛剛說的接入分配的過程。
上圖左側的示例圖有些複雜，所以我做了一個簡化，大家可以看右邊的這三個小圓圈。
我們在做任何邊緣業務的時候，第一步要考慮的就是排程，也就是需要滿足哪些不同場景。比如說可能有些是對負載比較敏感，有些對時延比較敏感，有些對地理位置比較敏感，這些條件都會由演算法規劃出來一個最佳的排程策略。
同時業務也可以在上面去自定義想要的業務邏輯。比如可能想要多個不同的版本，想在不同的區域用不同的版本，包括可能精確到不同的業務場景去用不同的版本，又或者可能他有自己的業務屬性，在他的業務屬性下可以進一步去控制更復雜的策略。
比如說像匯聚，最終在端測聲網的 SDK 也會去完成一個動態組網，實現匯聚→遷移→重連的高可能閉環。經過這幾個步驟的整合，基本上可以幫業務做到透明化。
在分配的基礎上，還有一層是服務部署在哪裡，這是一個雲原生的資源編排問題。在聲網內部有一套叫做 HCI 的底層雲原生平臺，它是基於 kubernetes 開發的。我們把這整套的雲原生架構推廣到了聲網在全球的所有邊緣上。
除 kubernetes 本身有的一些機制外，我們還做了一些特殊的邏輯。
首先是一個基於雲原生的全球資源控制面。我們同時有 HCI 核心環境和 HCI 邊緣環境，這兩個環境同時滿足分鐘級排程至全球任意邊緣節點的能力。
在簡單的 Kubernetes 裡面，我們認為它是一個裸 API，而我們提供的是經過一定封裝的平臺，不是讓開發者直接在裡面裸跑容器，是經過負載封裝之後，有一個不受限的執行環境，同時它能在平臺上很好的管理長駐程式、有狀態的長生命週期任務、動態函式等。
另外是為邊緣設計最佳化。在邊緣上使用複雜業務場景具有相當的困難性。比如說有些業務它需要彈性的 IP，IP 需要能夠跟著 Pod 進行遷移；又或者說需要一個四層的邊緣負載均衡器，針對這些情況我們都實現了軟體化的邊緣彈性，可以在邊緣環境中快速實現各種各樣的豐富的網路棧擴充套件。
同時像複雜業務基本上會有更加麻煩的一些編排策略，比如說可能需要在一組 Pod 之間去共享 Sidecar，多版本灰讀等豐富的編排策略，這些都會在內建的 CRD 當中得到支援。
下面再來看一個簡單的 DEMO。
上圖是我們的 DEMO Serverless，展示瞭如何一鍵部署到邊叢集。在我們內部既有圖形化的介面，也有類似圖中這樣的命令列釋出工具，開發者可以用完全雲原生的方式一鍵部署，就像在操作 Kubernetes 一樣。在業務負載層面，既然是 Serverless 那肯定是要讓業務不去關注資源層面的問題，所以我們有一個高精度的容量預測和動態伸縮能力支援。大家可以看下面這個圖：
這是一個線上業務的預測視窗，視窗內的黃色區域是提前 15 分鐘預測出來的一個排程線。
從圖中前半段的曲線可以看出，預測值和實際情況保持了高度的準確性。我們的動態排程能力可以讓開發者在使用雲原生邊緣平臺的時候，更好的實現資源層的靈活性，而不需要去關注到底要在不同的區域中規劃多少容量，同時還可以實現容量間的實時調配，為不同的業務實現更好的彈性。
在這些基礎上，我們還解決了傳統雲原生當中非常難以解決的一個問題 —— 動態負載。如果所有資源都做靜態分配，沒有辦法應對實時互動場景下突發的各類場景。我們前面舉的例子，是一個頻道內主播突然變多了，在這樣的場景下，我們排程其實分成了兩層。
上圖左側的草圖是一個抽象的概念，表示的是在業務的 worker 層面，agent 會實時感知到機器和業務層面的負載情況。並且這是一個全網的對 CPU 記憶體、GPU 磁碟的使用情況的整體秒級感知，使得我們可以在秒級時間內去規避排程熱點，做到完全實時的排程和遷移。
這個層面上和傳統的容器靜態分配不同，我們可以在動態規劃資源池之後，動態的根據負載分配容量。如果出現了超大規模的頻道，比如說客戶做活動突然湧進了很多人，我們就可以快速的把機器上的其他業務遷移走，避免影響到其他業務場景。
這在本質上相當於實現了 Pod 與 Pod 之間的資源共享，一組相同的業務容器負載可以共享資源，我們就不用擔心資源會分配過度或者分配不足。之前我們可能會說 request 2C 有點少、request 8C 有點多，那現在就無所謂了。其實所有的 Pod 之間，只要存在資源就都是可以共享的，但如果資源真的沒有了，也會被動態的規劃到別的地方。
智慧路由是相對高階一些的能力，也相對比較複雜。
智慧路由在業務場景中有時會被提到。
我們希望相同的頻道一起被處理，比如抓娃娃機場景中，當大家一起在抓娃娃，我們希望用一個 convergeKey 實現任務的匯聚。如果娃娃機需要一個 GPU，那也可以在申請分配資源的時候帶一個 GPU 加速。
同樣，也可以去指定分配各種不同的版本，實現多版本並行的線上業務，我們會根據實際的業務場景給客戶做動態分配。
還有一塊是傳輸和狀態管理，這一層面是聲網真正的一個邊緣大殺器。
邊緣會存在非常多的脆弱性和不確定性，要想真正的解決複雜業務場景，不能只是靠分配、部署、託管，不是一個簡單的 Serverless 就能搞定的。所以在後臺除了 Serverless 能力之外，我們還有大量其他的後臺能力，比如說 Worker 狀態管理帶來的可操作性。目前市面上沒有什麼 Serverless 場景是可以在任務啟動過程中仍然去持續管理它的，這個時候我們的特殊架構便可以帶來一些操作上的便利。
最後我們來簡單回顧一下聲網 UAP 在實時互動邊緣雲層面，跟現在市面上的其他雲廠商相比做了哪些不一樣的事兒。
這個表格不算列的很全，我們基本上都是按照遇到的業務場景、業務挑戰，去做一些針對性的規劃。但我們可以看到大量的第三方，包括雲函式、雲容器或者邊緣函式現在的一些場景支援。
業界現在可能還沒有真正意義上的實時互動邊緣雲，但從表格我們可以看到，聲網可能是在 RTC、RTE 領域走的比較靠前的廠商了，並且一直專注給開發者提供開箱即用的是實時互動能力，所以在內部我們會更關注如何合理的解決這些問題。
之所以做這些，是為了什麼呢？大致有三點：
- 進一步降低門檻
在內部我們希望能夠降低 RTE 應用的開發門檻，帶給大家更多、更快、更好的 RTE 後臺服務。當然這是相當艱鉅的一個挑戰，現在還存在一定的門檻，即使在有了我們這樣的一個平臺的基礎上，也需要開發者有非常強的研發能力，需要能正確的整合，去解決好高可用的故障切換。所以，我們還是希望能夠進一步對能力做抽象和封裝。
- 完善解決方案
同時，我們也在聲網後臺內部不斷深化完善內部的基建能力，加強應用性和工具鏈，最終帶給大家更多開箱即用的場景。
- 與生態和合作夥伴結合
進一步來講，我們也希望能夠跟生態合作伙伴做結合，透過雲市場接入更多第三方的互動場景，放到我們的邊緣雲平臺上。我們會針對有開發能力的合作伙伴，一起考慮如何進一步開放我們的實時邊緣雲的能力。
03 當 RTE 遇見 Serverless
前面講的是聲網內部的一些技術能力和方案，相信大家也會很關心我們的能力除了做了一個雲錄製之外，還能給大家提供什麼？
下面我想從完整的業務場景來講一講，RTE 和 Serverless 之間的一些關係和技術展望。
在一個完整的業務場景裡，除了前面提到的基礎的 PaaS 能力，還有很大部分都是基於每一位開發者身上實現的應用邏輯，如何解決這類業務邏輯的互動問題也至關重要。
如果我們用最簡單的方法來看，可以用無伺服器的移動端把所有的應用邏輯都放在端測，這對開發者非常友好，簡單無後臺。但如果應用比較複雜，團隊和業務已經到了一定規模，這種方法就很難滿足更復雜的場景。
在早期我們能以這種幾行程式碼整合的 RTC 開發很長的時間，幫助開發者把整個互動應用創新做好，但當業務做大做強的時候，就需要一個更加完整的後臺。
下圖包含一個大致的示意圖，是當客戶需要管理自己的業務信令、業務事件，結合聲網的 SDK、NCS 回撥，業績服務端 RESTful API 並用的一個相對完整的業務場景。
上圖中淺色的部分都是客戶要實現的，深色的部分是聲網的各種模組。如果我們上來就給開發者看這樣一個圖，很可能會覺得頭有點大，看起來好複雜。但實際上這裡的複雜結構一定程度上是不必要的。
大家可以看到，我們引入了三個端之間的互動。開發者的端側以及我們的兩套後臺，這樣勢必會帶來極大的通訊成本，包括中間的互動鏈路。
假如說專案中聲網後臺的任意互動都有需要，那中間任何一端出了問題都非常麻煩，比如前面提到的雲錄製，可能要收一個雲錄製的回撥，才能知道在錄的過程中出現了什麼樣的問題。
但是有可能聲網的錄製並不能直接滿足你的場景，比如說在錄的過程中主播和觀眾需要同時出現，或者說在特定的時刻才開始錄製，顯然是需要特別關注在自定義的業務場景下的錄製是如何實現的。我們過去直接提供的 API 不能直接幫客戶實現這個問題，因此我們希望能夠進一步的用 Serverless 去簡化架構。
前幾年大家有看到聲網的 aPaaS，某種程度上就是新架構的體現。我們希望能夠把我們跟客戶之間的互動、客戶跟後臺之間的互動做簡化。
這裡我們把它粗略的分成兩大類，實時互動場景和非實時互動場景。
非實時互動場景其實就是客戶自己的業務端和後臺的互動，但我們希望的是把實時互動相關的場景在聲網整體做一個閉環。這樣的好處是非常大的，因為實時互動相關的功能開發其實都不簡單，聲網可以幫開發者儘可能的去遮蔽這部分的複雜度，同時實現客戶自定義的業務邏輯。比如說互動遊戲場景中的仲裁、防作弊，這些都是沒有辦法單純在端測去實現的。
整體來看，我們希望能夠去賦能開發者，讓實時互動觸手可及。
我們並不是在做一個 Serverless，也不是傳統意義上的雲廠商，而是一個專注於做實時互動的平臺，希望能透過基於 RTE platform 的開放性框架，讓內部的實時互動邊緣雲更好的孵化 RTE 場景。
從 Serverless 的角度來看，我們更加關注整個生態以及實時互動應用後臺能力的發展。
邊緣應用正在變得越來越複雜，同樣也越來越完善。
從電信運營商的角度看，電話，簡訊這些大家習以為常的基礎服務都可以認為是邊緣化的互動場景。
而聲網後臺今天帶給大家的 RTC，RTE 互動能力，其實也是一個分散式的邊緣雲，未來的十年，我們認為整個實時互動邊緣雲，還會更多的走進大家的生活，會給開發者帶來更多更復雜豐富的業務場景，也希望我們真正能夠透過這樣的 Serverless 能力，讓實時互動變得觸手可及，無處不在。
我本次的分享基本就到這裡，謝謝大家的關注。也希望今天的這個分享能幫助到大家，歡迎大家持續關注聲網未來在 RTE Serverless 應用領域的新進展。