作者：洛浩
分眾傳媒誕生於 2003 年，建立了電梯媒體廣告模式，2005 年成為首家在美國納斯達克上市的中國廣告傳媒股，2015 年分眾傳媒迴歸 A 股，市值破千億。分眾傳媒營收超百億關鍵在於，抓住了【電梯】這個核心場景。電梯是城市的基礎設施，電梯這個日常的生活場景代表著四個詞：主流人群、必經、高頻、低干擾，而這四個詞正是今天引爆品牌的核心稀缺資源。
分眾獨有的價值是在主流城市主流人群必經的電梯空間中每天形成了高頻次有效到達，從而形成了強大的品牌引爆的能力。分眾電梯媒體，覆蓋 3.1 億中國城市主流消費人群，超過 260 萬個電梯終端。除了電梯終端外，還會印發大量的廣告海報，怎樣確保這些靜態資源的張貼效果，成為分眾的重要業務指標之一。因此，分眾自研了圖片識別處理系統。當工作人員更換好海報後，會通過 APP 端拍照上傳到後臺服務端。而每個週末，靜態海報會批量進行更換，後臺系統就會迎來處理高峰，大概需要集中處理幾百萬張圖片。工作日的時候，更換頻次相對較低，後臺系統就會相對空閒。週末和工作日的流量峰值平均相差 10 倍以上，如下圖所示，如果按照週末的峰值保有資源，會導致工作日產生大量的閒置資源。
隨著業務規模的增長，業務方對後臺服務的彈性訴求也越來越強，怎樣能讓後臺系統能更加從容應對波峰波谷，又能平衡資源開銷成為最大的痛點。其實早在 2019 年年底，分眾就接觸了函式計算 FC，同時也在摸索容器的使用方式。經過一段時間的探索，發現函式計算的模式更適合業務的發展。對於業務方來講，主要關注點在業務和演算法，不想接觸太多的底層基礎設施概念，容器的上手門檻和後期維護要比函式計算更高一些。
函式計算的落地實踐
分眾最早是採用單體架構來處理圖片識別功能，切到函式計算後，採用前後端分離的架構，後端部分使用 API 閘道器 + FC，使用 API 閘道器是為了規範化 API。但是當時 FC 的使用上也並不是一帆風順，首先對函式計算 FC 的穩定性、易用性、效能等方面也有諸多疑慮，而 FC 當時也的確存在一些限制，比如：
- 沒辦法提供 CPU 使用率和記憶體使用率等監控；
- 最大規格只能提供 2C3GB，擔心複雜演算法下，2C 支撐不了演算法的資源要求；
- 最大程式碼包支援 50MB，而圖片識別演算法動輒上 GB，最小的壓縮包也有幾百 MB；
- FC 沒辦法常駐程式，擔心彈性效率不足，影響響應耗時。
經過和分眾的溝通測試，發現 FC 執行原理和雲主機其實是不一樣的，一些擔憂點都可以被解決。對於 FC，每個請求都可以獨佔例項資源，通過水平彈性擴充套件來承載大流量。比如同時有 10 個請求到 FC，那麼 FC 就可以同時啟動 10 個同規格的容器來執行請求，當前請求執行完後才會接下個請求，因此可以保障每個請求的 CPU 資源都是獨佔的，而且請求間還可以做到故障隔離。
經過實際測試，發現 2G/約 1.33C 的資源規格可以滿足大部分的圖片識別場景，部分操作如加水印，還可以縮減到 512MB/約 0.33C（最小規格 128MB 記憶體/約 0.1C），達到最佳的資源使用配比，以節省費用。而針對體積較大的演算法包，通過掛 NAS 盤的方式，也可以解決。在彈性方面，函式計算可以做到百毫秒級的彈性伸縮（冷啟動），對 APP 端的 API 介面，端到端平均響應大約在 300ms 左右，基本可以滿足；對圖片識別來講，因為是非同步呼叫，所以對延遲並不敏感。最終上線後，大致的業務架構如下：
經過一段時間的線上執行，函式計算比較好的承載了線上的業務，彈效能力和響應耗時基本都符合業務訴求。業務峰值的時候，會擴容 7K 多個容器例項同時處理圖片識別，峰谷的時候，例項會自動回縮。相比之前雲主機的使用方式，費用節省至少在 50% 以上。另外還有個顯著的好處是，函式計算對釋出部署效率的提升，釋出時間大概縮短了一個數量級，而且更加便捷。之前採用雲主機部署的方式，全量更新程式碼需要寫指令碼每臺機器上執行一遍，而 FC 只用上傳一次程式碼後，底層的機器會自動替換成最新的程式碼，業務還能不中斷。
函式計算的優化升級
但是隨著業務的不斷髮展，峰值處理圖片的數量也在一直變大，一向穩如泰山的 FC 在業務高峰期，逐漸開始產生一些流控和超時的報錯，如下圖：
經過排查發現，原來 FC + NAS 掛載演算法依賴的方式執行程式碼，在業務高峰時，會遇到頻寬瓶頸，導致部分請求執行耗時變大，加劇了併發的消耗，最終導致被流控和執行超時。如監控顯示，原來在 NAS 中放置的程式碼依賴大概有 1GB 多，當併發被陡然拉起時，大量的 FC 例項會去 NAS 載入依賴，造成網路擁堵。最直接的辦法是直接升級 NAS 例項的頻寬，但是治標不治本。而經過 1 年多的發展，函式計算也增加了非常多的實用功能，和分眾溝通後，推薦直接用映象的方式來部署。對比原先 ZIP 包的部署方式，會增加一步打映象的操作，但是帶來的收益更加明顯，首先依賴包和業務程式碼可以一起部署維護，映象的方式更加標準；另外也可以省掉 NAS 盤，降低了網路依賴和單點故障風險。
部署過程當中也面臨另外個問題，映象太大！Python 3.8 基礎映象接近 1GB，所有演算法依賴接近 3GB，最終生成的映象有 4.2GB。直接部署到 FC，冷啟動過程當中單單載入映象就要 1 分多鐘，幸好 FC 提供了映象加速能力，載入時間極大的縮短到了 10 秒左右，如下是加速效果的對比。
另外，FC 也支援了大規格例項，可以直接部署16C32GB大規格例項，對一些強依賴CPU資源的演算法，也可以直接部署到FC上執行。還有個比較好的功能，是 FC 在可觀測方面的增長，像之前提到的CPU和記憶體使用率，也都開放支援了。在服務配置功能裡，開啟例項級別的監控後，在函式的監控檢視下，就可以看到例項的 CPU 使用率、記憶體使用率、網路頻寬情況等。這個對對分眾的業務來講，非常有用，針對不同的圖片處理演算法，可以根據 CPU 使用情況，來調整 FC 執行的規格，可以最大化的平衡成本和效能。
總結和展望
- FC 在降本增效方面，有著非常不錯的吸引力。尤其是對有波峰波谷和需要極速彈性的業務，是非常好的選型。另外像映象部署、映象加速、可觀測等能力的增強，可以讓分眾更好的駕馭業務。
- FC 最近還發布支援了 GPU 掛載能力，在業界也是首創，對後續需要依賴 GPU 推理加速的演算法模型，也是個不錯的選擇。利用 Serverless 彈性伸縮和按需付費的優勢，可以大大降低 GPU "用不起" 的現狀。
- 阿里雲的 Serverless 不僅有函式計算平臺，針對微服務應用，也在業界最先推出了 Serverless 應用引擎 SAE，對目前分眾基於 K8s 部署的後臺微服務也有著明顯的優勢：可以顯著降低資源維護成本，提升整體研發效能，而且可以做到零程式碼改造平遷。後續會和分眾一起探索微服務 On Serverless 的最佳實踐。