趙慶傑（阿里雲函式計算）、林雪清（阿里雲函式計算）、杜玲玲（高德）、王壁成（高德）
## 導言
2023年春節，經歷了三年的疫情後，我們終於在春天迎來了曙光。國人的出行熱情空前高漲：回家看看父母親；心心念唸的旅行終於可以成行了。按照高德的估計，2023年春節出行的峰值流量將比2022年同期和2022年十一都有相當大比例的增長。然而，就在不久前，受疫情的影響，系統的流量還在相對低位執行。

如何在短時間內快速完成春節出行的備戰準備工作，保障系統在春節流量高峰下平穩執行，讓民眾出行所必需的導航等資訊服務訪問可以絲般順滑，成為了擺在技術人員眼前的迫切事情。要在流量變化很大的情況下保障系統平穩執行，同時做到降本增效，怎麼做到呢？

過去幾年，高德一直在堅定、持續地推進應用的Serverless化。經過深入的研究和選型，最終選擇阿里雲函式計算（Aliyun FC）作為其應用的的Serverless計算平臺。過去的一年，更是取得了長足的進展。

高德在Serverless上的遠見幫助他們以更加敏捷、經濟的方式應對不確定性以及強勁復甦的春節出行：不用費心考慮流量變化帶來的資源變化，無需提前按照峰值流量準備大量的計算資源，不用擔心資源是否足夠，經濟成本大幅下降、研發和運維效率明顯提升。

基於之前的Serverless成果，高德相關業務快速完成了春節出行備戰準備工作，春節保障順暢完成。

我們一起來看一個典型的案例：在去年FC是如何助力高德RTA廣告投放系統實現架構升級的。
## 業務背景
### 什麼是RTA
RTA 是一種實時的廣告程式介面，透過發揮媒體與廣告主雙方的資料、模型能力，實現實時的廣告優選；RTA 是一種介面技術，更是一種策略導向的投放能力。

廣告媒體透過高德的RTA介面，來詢問是否要投廣告，R他的服務透過查詢高德自己的人群資訊，返回投放結果。這樣媒體投放廣告可以更精準。
### 原系統的架構&問題
![image.png](https://intranetproxy.alipay.com/skylark/lark/0/2023/png/75552/1675909049282-0fd4555a-2895-46ad-8f9f-7edb28ba79ff.png#clientId=u3cc4a1c6-628d-4&from=paste&height=351&id=u6f60d9e8&name=image.png&originHeight=531&originWidth=962&originalType=binary&ratio=1&rotation=0&showTitle=false&size=31314&status=done&style=none&taskId=u7438e87e-5454-4f57-881a-228e1d56b25&title=&width=636)
原系統伺服器佔用較多，依賴鏈路較長，每次擴容，依賴服務也需相應擴容，造成資源佔用較多。
## 技術選型
### 人群命中功能
人群命中功能，本質可以歸結為 **檢索某個元素是否在一個集合中** 的問題。

這類問題，業界常用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化
![serverful vs serverless (3).svg](https://intranetproxy.alipay.com/skylark/lark/0/2023/svg/75552/1676008084364-398849d3-c18f-4abf-bd79-16b671cf0ce1.svg#clientId=uc15b2f61-9128-4&from=ui&height=286&id=ub23f2727&name=serverful%20vs%20serverless%20%283%29.svg&originHeight=370&originWidth=916&originalType=binary&ratio=2&rotation=0&showTitle=false&size=16217&status=done&style=none&taskId=u8a4dda66-60e9-40d7-b77a-5efbfdb48bf&title=&width=708)
透過重新劃分應用和平臺的介面，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化最常見的技術選型。阿里雲函式計算是Forrester測評認定的全球領先的函式計算產品，在公有云和集團內都積累了豐富的應用Serverless化經驗，是合適的選擇。
### 高效能要求
RTA廣告投放系統作為為外部媒體提供相關服務的系統，具有大流量，延遲要求高的特點，是典型的高效能要求場景。這樣的場景裡，客戶端設定的超時時間一般都很短，一旦超時，介面呼叫就會失敗。採用Serverless的架構之後，請求的流量會先打入FC的系統，然後轉發到函式例項進行處理。在這個場景裡，要求FC的多租戶、大流量的情況下，將請求處理的系統耗時（不包括函式自身執行時間）的平均值、P99值控制在很低的水平，才能保證請求成功率SLA的要求。
## 落地方案
### 系統架構
![RTA.svg](https://intranetproxy.alipay.com/skylark/lark/0/2023/svg/75552/1676000303727-7e1b8828-cad6-488c-8fe8-ae79cf233baa.svg#clientId=u063e8ebd-4592-4&from=ui&height=275&id=u25a99820&name=RTA.svg&originHeight=338&originWidth=738&originalType=binary&ratio=2.200000047683716&rotation=0&showTitle=false&size=9670&status=done&style=none&taskId=u7be67aa4-5f58-40b2-9bc8-6da16e3c8b2&title=&width=599.98291015625)
新架構裡，中臺生成人群后，呼叫Redis的BF.INSERT 等指令，生成bf。 引擎側拿到裝置ID後，透過Redis的BF.EXISTS 指令，判斷是否在對應的人群中。

**特點：**

1. **去除閘道器，減少鏈路長度**
2. **設定快取，離線系統和線上系統解耦，提升效能**
3. **資料壓縮，減少記憶體佔用**
4. **系統Serverless化，實現實時彈性和免運維，加快應用迭代速度**
### 請求排程
前面我們提到高德RTA廣告投放系統具有流量大，延遲要求高的特點，是典型的高效能要求場景。而FC是一個典型的多租系統，一個叢集內不單單有高德RTA廣告投放函式，還有非常多其它業務的函式。對FC的請求排程提出非常高要求：

- 單函式QPS無上限，大量長尾函式不消耗資源
- 排程服務要保證高可用，單點故障對服務無影響
- 請求處理所需的系統耗時要控制在平均值小於2ms，P99值小於10ms

我們來看看FC是怎麼做到的。
![排程.png](https://intranetproxy.alipay.com/skylark/lark/0/2023/png/75552/1675844363901-051e3880-69fb-43e3-b871-fc2ab97de5e2.png#clientId=u83201149-05d7-4&from=drop&height=430&id=u4075baae&name=%E8%B0%83%E5%BA%A6.png&originHeight=685&originWidth=1050&originalType=binary&ratio=1&rotation=0&showTitle=false&size=176836&status=done&style=none&taskId=udc3ce793-1eff-403b-a23e-d397fa70f49&title=&width=658.991455078125)
為了實現實時彈性，當函式的請求到達函式計算的前端機之後，前端機會找排程節點（Partitionworker）要一個處理請求的例項，並將請求轉發給它。排程節點接收到請求之後，如果有例項可用，則根據負載均衡策略獲取一個例項並返回給前端機；如果沒有，則實時建立一個，並返回給前端機。例項的建立時間可以達到百毫秒級別。

- 為了保證高可用和橫向可擴充套件，排程節點採用分割槽架構
- 同一個使用者/函式的請求對映在連續的分片區域內
- 單函式請求可跨越多個分片，橫向擴充套件
- 排程節點（Partitionworker）透過心跳向分片管理器（Partitionmaster）彙報分片和節點狀態
- Partition master 透過移動/分裂/合併分片進行負載均衡
- 排程 100 萬函式，單函式峰值 20 萬TPS，排程延時小於 1ms
- 任何節點故障，請求會被路由到其他 Partitionworker 上，對可用性無影響

我們看到一個請求需要透過前端機和排程節點的處理之後，才轉發給具體的函式例項。因此請求處理的系統耗時包括前端機的處理時間、排程節點的處理時間、前端機和排程節點的通訊時間以及前端機和函式例項的通訊時間，過去一年，我們對函式計算的前端機、排程系統針對性的做了很多的最佳化，保證了系統在超大流量的情況下，請求處理的請求處理所需的系統耗時要控制在平均值小於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實現了Pod資源池化、映象加速、映象預熱、計算例項Recycle等等技術，保證了極速的資源交付速度。
#### 高可用
為了實現高可用，FC的資源在每個region不止分佈在一個 K8s 叢集，而是多個 K8s 叢集，做到了任何一個 K8s 叢集出現問題，會自動地切換到正常叢集的能力。每個叢集都有多種資源池型別：獨佔資源池、混跑資源池和可搶佔資源池。FC根據業務的特點，進行統一排程，從而把成本進一步的降低。
![資源池.svg](https://intranetproxy.alipay.com/skylark/lark/0/2023/svg/75552/1675999717778-16788b3b-032c-4c13-9a2d-e1935cbddf5a.svg#clientId=u8c05013b-bda0-4&from=ui&id=u7c41cea1&name=%E8%B5%84%E6%BA%90%E6%B1%A0.svg&originHeight=346&originWidth=1040&originalType=binary&ratio=2.200000047683716&rotation=0&showTitle=false&size=22345&status=done&style=none&taskId=u19d3cb61-3550-42ed-9878-084a7699b5d&title=)
#### 交付SLA
在資源的交付總量方面，目前FC已經有了單函式交付幾萬個例項的案例，由於FC有資源池池化動態補充的能力，理論上，FC單函式可以交付的例項數遠不止幾萬個例項。在資源的交付速度方面，FC可以做到百毫秒級別的例項建立速度。遇到burst的情況，FC從以下兩個維度來控制資源交付速度：

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

以上引數為可調整。

下圖展示了在一個呼叫量快速增長的場景下FC的流控行為：
![image.png](https://intranetproxy.alipay.com/skylark/lark/0/2023/png/75552/1675860039242-4fb97ced-a577-418a-bb61-18df5eac89b1.png#clientId=u83201149-05d7-4&from=paste&height=264&id=u329dd976&name=image.png&originHeight=809&originWidth=1500&originalType=binary&ratio=1&rotation=0&showTitle=false&size=1366053&status=done&style=none&taskId=u823944a8-b24e-45db-8db1-81bb8948d60&title=&width=488.99432373046875)
### 多機房部署 
系統採用三單元部署，保證外部媒體都可以就近訪問，降低網路時延。

![未命名檔案.svg](https://intranetproxy.alipay.com/skylark/lark/0/2023/svg/75552/1676008814670-866a5384-898a-42b0-856e-80f679b22256.svg#clientId=u66838763-285b-4&from=ui&id=ue2a21af8&name=%E6%9C%AA%E5%91%BD%E5%90%8D%E6%96%87%E4%BB%B6.svg&originHeight=232&originWidth=765&originalType=binary&ratio=2&rotation=0&showTitle=false&size=11771&status=done&style=none&taskId=u34344a32-764e-4795-8b2c-b6a1c3a639a&title=)
## 業務效果
系統架構升級後，節省了幾千核的機器資源，實現了全面Serverless化，呼叫鏈路變短了，系統變得更加彈性、健壯和易於維護，取得了很好的業務效果。
## 展望
在過去的2022年，高德在 Serverless 領域中已經取得了長足的進展， 然而這不是終點，而只是剛剛開始，後續FC會和高德一起推進應用的全面 Serverless 化，期望幫助高德在更多的場景去使用 Serverless，吃透 Serverless 給帶來的技術紅利 ！

阿里雲函式計算助力高德 RTA 廣告投放系統架構升級

相關文章