阿裡雲 FaaS 架構設計

一、基于 ECS 的 FaaS

在阿裡雲傳統架構，使用者通過網際網路進入到負載均衡系統中，再通過負載均衡把系統的請求排程到不同的機器上去。這種傳統的架構帶來的問題比較多，一方面是多應用配比比例容易失衡，造成資源浪費；另一方面是鏡像更新比較繁瑣，整個過程的開機速度在分鐘級，擴容速度也相對較慢。

(1) 架構設計

基于 ECS 的 FaaS 架構設計同樣也是通過網際網路進入，落到 SLB 負載均衡上。SLB 負載均衡這個系統是部署在阿裡雲内部的，主要用于抵擋 DDoS 攻擊及請求均衡到多台 api_server 上。api_server 再發起函數的 CRUD 操作，并向 Scheduler 申請容器。

Scheduler 管理容器在 worker 的放置，請求落在容器上的排程分發。使用者所在 worker 就是我們稱之為的計算節點，如果需要通路使用者的 VPC 環境則在計算節點上通過 ENI 網卡打通到使用者 VPC 環境。

(2) 多租戶多應用部署的支援

namespace 是 linux 前幾年推出的一個資源隔離方案，可以在核心層面做一些設定指定一部分程序固定。并且可以在 cgroup 的這一套設定方案裡設定，控制資源的通路。在 namespace、cgroup 整套方案下，衍生出了 container，社群中常用的的 Docker 方案把鏡像作業系統中的很多細節包裝成一個方案，使用者看到了一個相對比較完整的作業系統，把使用者當成一個單個使用者放置在虛拟機當中。這就是一個 vm，相當于說一台 ECS，這裡就是作業系統層面，把整個 cpu、memory、包括裝置全部給屏蔽掉，在上面用 cgroup 封一層，對應的就是 Docker 容器。

應用放置政策包括使用者獨占虛拟機、同 VPC 獨占虛拟機、資源通路權限一緻的 APP 混部在同機器。把兩個不同的使用者混在一個 vm 下，也就是 ECS 上面，對于使用者之間來說是存在風險的。為了屏蔽掉共用 kernel 帶來的風險，ECS 上的實作，我們單個 ECS 隻有一個租戶，這樣處理也存在一些問題，最突出的就是對于低頻調用函數資源使用率低。

(3) 快速水準彈性擴容

如何做到水準彈性擴容？

① 通過應用容器部署，可以定制一些特别的語言、Runtime容器、通用LIB/SDK，并保持社群生态一緻，這樣就不需要另外去下載下傳，使用者用起來也比較友善，啟動速度也非常快。

② 通過設定公共容器鏡像、容器鏡像寫入ECS鏡像、ECS鏡像啟動機器、快速補充機器池等控制機器資源池，進而能夠兼顧性能與成本。

③ 在池化的機器中池化容器建立、代碼目錄延遲挂載、提前啟動runtime、提前health check，使用者請求來臨的時候需要啟動的時間會變得更短。

④ 通過限制使用者應用大小、鼓勵拆分業務邏輯、内置SDK/Lib來控制應用大小。

⑤ 通過P2P鏡像分發、避免對下載下傳服務造成沖擊、按需加載、降低下載下傳延遲、提升啟動速度等完成P2P鏡像下載下傳加速。

如何提升資源使用率

在實際研發過程中發現，相同QPS下機關時間片内排程對資源量的影響非常大，我們可以通過排程提升資源使用率。例如在下圖中，我們看到宏觀狀态下的整體 TPS 是非常穩定的，然而事實上，我們放大到毫秒級别會發現，其實非常不均勻！那麼這種不均勻到底會給我們帶來什麼影響？

假設我們每個容器被設定的最大并發度為 1，即任意時刻一個容器隻處理一個任務。下圖展示了 a,b,c,d,e,f 多個請求在不同時刻點被排程時對容器數目的影響。

可以看到場景一時，每個請求均勻打入時，任意時刻隻需要一個容器就夠了，這種情況就是我們理想中希望能達到的；

而在場景二下，如果排程發生了滞後，可能導緻前置的請求和後來的請求混到了一個時間點，導緻容器數目翻倍，在中間的空白處，這些容器又沒有被充分利用造成了資源的浪費；

在場景三下，如果容器啟動耗時較長，或者調用耗時變長，原來的 b 請求會和 a 請求出現時間上的疊加，導緻又需要建立新的容器，而新的容器如果需要較長時間的冷啟動， 又會導緻和 c 請求出現時間上的疊加。如果排程系統實作得不夠好，這樣一來就可能産生雪崩效應，導緻資源使用量暴漲，而實際使用率卻極其低下。

通過上面幾個場景，我們可以大緻為資源使用率的開銷上總結一個優化方向：

1. 盡可能讓排程更均勻、更合理，避免紮堆喚起容器
2. 盡可能降低冷啟動時長，避免短期大量容器都處于建立當中，避免無意義的系統排程開銷
3. 除了上述外，我們還可以考慮高密部署，将單機的資源使用率提升上去

如何容災、防止雪崩？

在實際操作中發生異常的時候，使用者請求會出錯，出錯後會重新開機或調動新資源建立新的容器，但這樣會導緻整個延遲增大。使用者有又會重複嘗試，重複嘗試則會導緻負載升高，進而又引起異常，如此惡性循環。可以通過優化啟動速度、多 Partition 容災部署、指數退避重試、Breaker 阻斷異常請求、多可用區備災、SLB 阻斷 DDoS 攻擊來防止雪崩。

二、基于神龍高密部署的FaaS

(1) 為什麼需要做高密部署？

一是因為彈性啟動速度要求高，希望做到每秒1萬個容器執行個體的啟動、啟動延遲控制在300毫秒以内、容器的存活時間在分鐘級别、資源粒度128MB；

二是成本更低，ECS 架構因安全隔離問題資源碎片多，突發調用延遲高，影響資源數目；

三是性能，ECS 單機緩存少、請求毛刺率較高、請求最大延遲高；

四是穩定性，高并發對系統沖擊、頻繁的建立删除資源、ECS管控壓力，爆炸半徑難以控制。

(2) 高密部署架構帶來的技術難題

整個高密部署架構帶來的一些技術難題：

首先要面對的是如何解決單機多租戶隔離安全風險，如果不解決這個問題那麼就無法做到單機多租戶的安全高密部署，這樣資源使用率密度無法有效提升；

其次是如何解決高并發下啟動速度問題，如果無法做到這點，如我們前面所提到的，冷啟動時間較長會嚴重加劇資源的開銷，同時嚴重影響使用者延遲體驗；

再就是如何解決單機多租戶VPC網絡打通及安全問題，這一點其實非常重要，我們在 ECS 上建立 VPC 網絡連接配接的速度非常慢，這也嚴重影響了使用者冷啟動及資源的使用；

另外我們還需要考慮如何設計高密部署下的技術容災方案，因為任何一個計算節點的異常會帶來大量使用者的服務異常。

(3) 基于安全容器模闆技術的優化

我們是如何做到基于安全容器模闆技術的優化的？每個容器獨占一個虛拟機沙箱，這個沙箱相當于是一個獨立的虛拟機，有自己獨立的 linux 核心，這樣一來每個容器都是通過獨立的 kernel 來做安全隔離。神龍啟動時模闆化大量虛拟機用于提升啟動速度，通過 virtiofs 延遲挂載使用者代碼目錄，通過虛拟機微核心隔離使用者，可以做到單台機上每個微核心20M左右的記憶體，單機至少 2000 個容器，控制它的冷啟動時間是在250毫秒左右。通過排程算法，我們可以合理地使用資源，承諾使用者的資源 quota。

(4) 代碼按需加載

代碼按需加載是通過以下幾個方面做到的：使用者容器會重複使用同一份代碼，單台神龍隻需下載下傳一次；腳本語言包含了大量用不到的代碼；使用使用 FUSE（使用者空間檔案系統）來做中間層檔案的真實讀取；底層使用 NAS 做低延遲的資料下載下傳；OSS（阿裡雲對象存儲）做高帶寬支援的資料下載下傳。注意到，我們這裡混用了 NAS 及 OSS 一同來做代碼的加載，需要注意的是，NAS 的通路延遲相對而言更低，對于小檔案的加載更快。我們在加載初始階段開始全量異步從 OSS 下載下傳代碼。而對于需要立即通路的資料，我們則從 NAS 上讀取。由于我們将整個使用者代碼目錄做成了兩個檔案：一個為目錄檔案索引資料，另一個為檔案内容資料。由于 NAS 通路延遲低，我們可以通過類似 GetRange 的方式去資料檔案上擷取小檔案内容。這樣就可以用最快的速度即時加載使用者代碼來達到快速冷啟動了。

(5) VPC 網絡優化

基于網絡服務網格的 VPC 網關代理是通過使用者VPC網絡安全隔離。我們過去在 ECS 方案上插拔 ENI 網卡非常耗時，至少需要2~3s，P99甚至達到6～8s。在高密部署的神龍方案上，我們沒有必要為每個安全容器做多次網卡插拔，隻需要在神龍機器上統一打通到網關代理，而使用者 ENI 網卡常駐在網關叢集上，這樣整個網卡的加載速度會變得很快。這樣對于使用者體驗和資源開銷都會是一個巨大的優化。

(6) 資源配置設定率

通過混合部署多租戶各類業務提升部署密度，合理配比不同資源需求的容器到一台實體神龍，進而提升資源配置設定率。

三、總結

講師簡介：朱鵬，阿裡雲 Serverless 技術專家

負責阿裡雲函數計算排程設計研發，在函數計算高并發、技術容災、冷啟動優化、排程資源管理、神龍裸金屬技術架構等多個方向均參與了設計和研發實作，是阿裡雲函數計算神龍高密部署架構主導推動負責人之一。目前主要緻力于提升資源使用率，研究設計超大規模并發下的低延遲資源排程解決方案。