作者 : 趙慶傑（阿里雲函數計算）、林雪清（阿里雲函數計算）、杜玲玲（高德）、王壁成（高德）
導言
2023 年春節，經歷了三年的疫情後，我們終於在春天迎來了曙光。國人的出行熱情空前高漲：回家看看父母親；心心念唸的旅行終於可以成行了。按照高德的估計，2023 年春節出行的峯值流量將比 2022 年同期和 2022 年十一都有相當大比例的增長。然而，就在不久前，受疫情的影響，系統的流量還在相對低位運行。
如何在短時間內快速完成春節出行的備戰準備工作，保障系統在春節流量高峯下平穩運行，讓民衆出行所必需的導航等信息服務訪問可以絲般順滑，成爲了擺在技術人員眼前的迫切事情。要在流量變化很大的情況下保障系統平穩運行，同時做到降本增效，怎麼做到呢？
過去幾年，高德一直在堅定、持續地推進應用的 Serverless 化。經過深入的研究和選型，最終選擇阿里雲函數計算 FC 作爲其應用的 Serverless 計算平臺。過去的一年，更是取得了長足的進展。
高德在 Serverless 上的遠見幫助他們以更加敏捷、經濟的方式應對不確定性以及強勁復甦的春節出行：不用費心考慮流量變化帶來的資源變化，無需提前按照峯值流量準備大量的計算資源，不用擔心資源是否足夠，經濟成本大幅下降、研發和運維效率明顯提升。
基於之前的 Serverless 成果，高德相關業務快速完成了春節出行備戰準備工作，春節保障順暢完成。
我們一起來看一個典型的案例：在 2022 年阿里雲函數計算 FC 是如何助力高德 RTA 廣告投放系統實現架構升級的。
業務背景
什麼是 RTA
RTA 是一種實時的廣告程序接口，通過發揮媒體與廣告主雙方的數據、模型能力，實現實時的廣告優選；RTA 是一種接口技術，更是一種策略導向的投放能力。
廣告媒體通過高德的 RTA 接口，來詢問是否要投廣告，RTA 的服務通過查詢高德自己的人羣信息，返回投放結果。這樣媒體投放廣告可以更精準。
原系統的架構&問題
原系統服務器佔用較多，依賴鏈路較長，每次擴容，依賴服務也需相應擴容，造成資源佔用較多。
技術選型
人羣命中功能
人羣命中功能，本質可以歸結爲檢索某個元素是否在一個集合中的問題。
這類問題，業界常用 bloom filter 進行解決。bloom filter 的本質是一組 hash 算法和 bitmap 的組合。優點是查詢效率高，佔用空間小。Redis 擴展版提供了 bf(bloom filter)功能。由於讀取是用 golang，寫入是用 Java 的寫入，爲了避免跨語言帶來的庫不一致，可能存在的 bloom filter 不同實現導致的命中不一致的問題，可以採用 Redis 擴展版的 bf(bloom filter)功能，在 Redis 服務端實現 bf 功能，保證不同語言調用的數據一致性。
藉助 Redis 來實現人羣命中功能，就可以去掉算法網關，數據中臺側的很多資源也可以因此節省下來。
數據同步
目前圈人平臺的數據更新有 4 種類型：在線、實時、離線單次、離線週期。
目前的圈人策略都是基於離線人羣進行圈定。後續雖然有可能使用在線和實時的情況，不過由於 RTA 廣告圈定的人羣一般較大，實時人羣的變化的比例較低，且媒體端均有緩存，實時性要求不高。使用實時，在線人羣和離線人羣的效果區別不大，所以目前建議只使用離線人羣作爲主要圈人手段，如果對實時性要求較高，可以考慮離線週期爲小時維度的更新(本質上實時性取決於 UDF 更新頻率和觸發方式)。綜合考慮離線週期更新 Redis 的方式。
Serverless 化
爲什麼要 Serverless 化
通過重新劃分應用和平臺的界面，Serverless 使得業務可以專注自身業務邏輯，人人都可以快速開發出一個穩定、安全、彈性、可擴展的分佈式應用成爲可能。
如何實現 Serverless 化
新的技術選型裏，引擎服務需要訪問 Redis。這是一個有着高頻存儲訪問的系統如何 Serverless 化的問題。
一般認爲 Serverless 就是 FaaS+BaaS。FaaS：Function as a Service，函數即服務，一般是各種後端微服務。BaaS：Backend as a Service，就是不適合以 FaaS 形態存在的後端服務，比如存儲服務。
Serverless 化的系統架構對雲存儲提出很高的要求，在可擴展性、延遲和 IOPS 方面，雲存儲需要能夠實現與應用同等/接近的自動擴縮容能力。
阿里雲提供 Redis 企業版服務，集羣架構版本提供多種實例規格，支持最高 2G 總帶寬，6000 萬的 QPS。支持調整實例的架構、規格等，以滿足不同的性能和容量需求。可實現無感擴縮容。可以滿足引擎服務 Serverless 化之後對存儲的要求。
而 FaaS 是目前後端微服務 Serverless 化最常見的技術選型。阿里雲函數計算 FC 是 Forrester 測評認定的全球領先的函數計算產品，在公有云和集團內都積累了豐富的應用 Serverless 化經驗，是合適的選擇。
高性能要求
RTA 廣告投放系統作爲爲外部媒體提供相關服務的系統，具有大流量，延遲要求高的特點，是典型的高性能要求場景。這樣的場景裏，客戶端設置的超時時間一般都很短，一旦超時，接口調用就會失敗。採用 Serverless 的架構之後，請求的流量會先打入阿里雲函數計算 FC 的系統，然後轉發到函數實例進行處理。在這個場景裏，要求函數計算 FC 的多租戶、大流量的情況下，將請求處理的系統耗時（不包括函數自身執行時間）的平均值、P99 值控制在很低的水平，才能保證請求成功率 SLA 的要求。
落地方案
系統架構
新架構裏，中臺生成人羣后，調用 Redis 的 BF.INSERT 等指令，生成 bf。引擎側拿到設備 ID 後，通過 Redis 的 BF.EXISTS 指令，判斷是否在對應的人羣中。
特點：
- 去除網關，減少鏈路長度
- 設置緩存，離線系統和在線系統解耦，提升性能
- 數據壓縮，減少內存佔用
- 系統 Serverless 化，實現實時彈性和免運維，加快應用迭代速度
請求調度
前面我們提到高德 RTA 廣告投放系統具有流量大，延遲要求高的特點，是典型的高性能要求場景。而阿里雲函數計算 FC 是一個典型的多租系統，一個集羣內不單單有高德 RTA 廣告投放函數，還有非常多其它業務的函數。對函數計算 FC 的請求調度提出非常高要求：
- 單函數 QPS 無上限，大量長尾函數不消耗資源
- 調度服務要保證高可用，單點故障對服務無影響
- 請求處理所需的系統耗時要控制在平均值小於 2ms， P99 值小於 10ms
我們來看看函數計算 FC 是怎麼做到的。
爲了實現實時彈性，當函數的請求到達函數計算 FC 的前端機之後，前端機會找調度節點（Partitionworker）要一個處理請求的實例，並將請求轉發給它。調度節點接收到請求之後，如果有實例可用，則根據負載均衡策略獲取一個實例並返回給前端機；如果沒有，則實時創建一個，並返回給前端機。實例的創建時間可以達到百毫秒級別。
- 爲了保證高可用和橫向可擴展，調度節點採用分區架構
- 同一個用戶/函數的請求映射在連續的分片區域內
- 單函數請求可跨越多個分片，橫向擴展
- 調度節點（Partitionworker）通過心跳向分片管理器（Partitionmaster）彙報分片和節點狀態
- Partition master 通過移動/分裂/合併分片進行負載均衡
- 調度 100 萬函數，單函數最大峯值 20 萬 TPS，調度延時小於 1ms
- 任何節點故障，請求會被路由到其他 Partitionworker 上，對可用性無影響
我們看到一個請求需要通過前端機和調度節點的處理之後，才轉發給具體的函數實例。因此請求處理的系統耗時包括前端機的處理時間、調度節點的處理時間、前端機和調度節點的通信時間以及前端機和函數實例的通信時間，過去一年，我們對函數計算 FC 的前端機、調度系統針對性的做了很多的優化，保證了系統在超大流量的情況下，請求處理的請求處理所需的系統耗時要控制在平均值小於 2ms，P99 值小於 10ms。
資源交付
Serverless 的場景下，業務不再需要關心資源的管理了，平臺負責資源的管理和調度。業務流量上漲了，平臺需要有能力快速剛性交付業務需要的計算資源；而當流量下降之後，平臺需要將空閒的資源自動釋放掉。
爲了保證包括高德 RTA 廣告投放函數在內的函數的資源剛性交付，阿里雲函數計算 FC 持續優化了資源管理的實現。
Serverless 新底座：神龍裸金屬+安全容器
一開始，阿里雲函數計算 FC 採用 Docker 容器的形式來交付函數計算實例。因爲 Docker 存在容器逃逸存等這樣的安全問題，爲了保證安全性，一臺宿主機只會部署一個租戶的函數。由於函數計算 FC 存在大量的長尾函數，函數實例的規格也往往比較小，比如只有 128M/0.1 核，這限制了資源利用率的提升。
爲了解決這個問題，阿里雲函數計算 FC 和相關團隊合作，將資源底座全面升級到神龍裸金屬+安全容器，藉助神龍裸金屬軟硬一體化技術帶來的虛擬化效率提升和安全容器安全性保障後實現的多租戶高密混部，大幅提升了資源的利用率。
獨立的資源管控
由於 K8s 集羣的 Pod 產出效率很難滿足 Serverless 每分鐘幾萬個實例的創建需求，所以函數計算 FC 與相關團隊合作，實現了 Pod 內的計算資源的進一步細分，由函數計算 FC 直接對 Pod 裏面的容器進行管控，從而實現了高密部署，以及高頻創建的能力。
毫秒級資源交付速度
相比較 K8s 分鐘級以上的資源交付速度要求，Serverless 的場景需要將資源的交付速度提升到秒級、毫秒級。爲了解決 K8s 基礎設施啓動耗時和函數計算 FC 對極致彈性強烈訴求之間的矛盾，阿里雲函數計算 FC 實現了 Pod 資源池化、鏡像加速、鏡像預熱、計算實例 Recycle 等等技術，保證了極速的資源交付速度。
高可用
爲了實現高可用，阿里雲函數計算 FC 的資源在每個 region 不止分佈在一個K8s集羣，而是多個 K8s 集羣，做到了任何一個 K8s 集羣出現問題，會自動地切換到正常集羣的能力。每個集羣都有多種資源池類型：獨佔資源池、混跑資源池和可搶佔資源池。函數計算 FC 根據業務的特點，進行統一調度，從而把成本進一步的降低。
交付SLA
在資源的交付總量方面，目前阿里雲函數計算 FC 已經有了單函數交付幾萬個實例的案例，由於函數計算 FC 有資源池池化動態補充的能力，理論上，函數計算 FC 單函數可以交付的實例數遠不止幾萬個實例。在資源的交付速度方面，函數計算 FC 可以做到百毫秒級別的實例創建速度。遇到 burst 的情況，函數計算 FC 從以下兩個維度來控制資源交付速度：
- 突增實例數：可立即創建的實例數（默認 300）；
- 實例增長速度：超過突增實例數後每分鐘可增加的實例數（默認每分鐘 300）。
以上參數爲可調整。
下圖展示了在一個調用量快速增長的場景下函數計算 FC 的流控行爲：
多機房部署
系統採用三單元部署，保證外部媒體都可以就近訪問，降低網絡時延。
業務效果
系統架構升級後，節省了幾千核的機器資源，實現了全面 Serverless 化，調用鏈路變短了，系統變得更加彈性、健壯和易於維護，取得了很好的業務效果。
展望
在過去的 2022 年，高德在 Serverless 領域中已經取得了長足的進展， 然而這不是終點，而只是剛剛開始，後續阿里雲函數計算 FC 會和高德一起推進應用的全面 Serverless 化，期望幫助高德在更多的場景去使用 Serverless，喫透 Serverless 給帶來的技術紅利 ！
新書推薦
點擊此處，下載 Serverless 電子書！