高德地圖如何短時間完成春節出行備戰工作？

　　 導言

　　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 指令，判斷是否在對應的人群中。

　　特點：

　　1. 去除閘道器，減少鏈路長度2. 設定快取，離線系統和線上系統解耦，提升效能3. 資料壓縮，減少記憶體佔用4. 系統 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 從以下兩個維度來控制資源交付速度：

　　1. 突增例項數：可立即建立的例項數（預設 300）；2. 例項增長速度：超過突增例項數後每分鐘可增加的例項數（預設每分鐘 300）。以上引數為可調整。

　　下圖展示了在一個呼叫量快速增長的場景下函式計算 FC 的流控行為：　　

　　多機房部署

　　系統採用三單元部署，保證外部媒體都可以就近訪問，降低網路時延。　　

　　 業務效果

　　系統架構升級後，節省了幾千核的機器資源，實現了全面 Serverless 化，呼叫鏈路變短了，系統變得更加彈性、健壯和易於維護，取得了很好的業務效果。

　　 展望

　　在過去的 2022 年，高德在 Serverless 領域中已經取得了長足的進展， 然而這不是終點，而只是剛剛開始，後續阿里雲函式計算 FC 會和高德一起推進應用的全面 Serverless 化，期望幫助高德在更多的場景去使用 Serverless，吃透 Serverless 給帶來的技術紅利 ！