作者：洛浩

分眾傳媒誕生于 2003 年，創(chuàng)建了電梯媒體廣告模式，2005 年成為首家在美國納斯達克上市的中國廣告?zhèn)髅焦?#xff0c;2015 年分眾傳媒回歸 A 股，市值破千億。分眾傳媒營收超百億關鍵在于，抓住了【電梯】這個核心場景。電梯是城市的基礎設施，電梯這個日常的生活場景代表著四個詞：主流人群、必經、高頻、低干擾，而這四個詞正是今天引爆品牌的核心稀缺資源。

分眾獨有的價值是在主流城市主流人群必經的電梯空間中每天形成了高頻次有效到達，從而形成了強大的品牌引爆的能力。分眾電梯媒體，覆蓋 3.1 億中國城市主流消費人群，超過 260 萬個電梯終端。除了電梯終端外，還會印發(fā)大量的廣告海報，怎樣確保這些靜態(tài)資源的張貼效果，成為分眾的重要業(yè)務指標之一。因此，分眾自研了圖片識別處理系統(tǒng)。當工作人員更換好海報后，會通過 APP 端拍照上傳到后臺服務端。而每個周末，靜態(tài)海報會批量進行更換，后臺系統(tǒng)就會迎來處理高峰，大概需要集中處理幾百萬張圖片。工作日的時候，更換頻次相對較低，后臺系統(tǒng)就會相對空閑。周末和工作日的流量峰值平均相差 10 倍以上，如下圖所示，如果按照周末的峰值保有資源，會導致工作日產生大量的閑置資源。

隨著業(yè)務規(guī)模的增長，業(yè)務方對后臺服務的彈性訴求也越來越強，怎樣能讓后臺系統(tǒng)能更加從容應對波峰波谷，又能平衡資源開銷成為最大的痛點。其實早在 2019 年年底，分眾就接觸了函數計算 FC，同時也在摸索容器的使用方式。經過一段時間的探索，發(fā)現函數計算的模式更適合業(yè)務的發(fā)展。對于業(yè)務方來講，主要關注點在業(yè)務和算法，不想接觸太多的底層基礎設施概念，容器的上手門檻和后期維護要比函數計算更高一些。

函數計算的落地實踐

分眾最早是采用單體架構來處理圖片識別功能，切到函數計算后，采用前后端分離的架構，后端部分使用 API 網關 + FC，使用 API 網關是為了規(guī)范化 API。但是當時 FC 的使用上也并不是一帆風順，首先對函數計算 FC 的穩(wěn)定性、易用性、性能等方面也有諸多疑慮，而 FC 當時也的確存在一些限制，比如：

沒辦法提供 CPU 使用率和內存使用率等監(jiān)控；

最大規(guī)格只能提供 2C3GB，擔心復雜算法下，2C 支撐不了算法的資源要求；

最大代碼包支持 50MB，而圖片識別算法動輒上 GB，最小的壓縮包也有幾百 MB；

FC 沒辦法常駐進程，擔心彈性效率不足，影響響應耗時。

經過和分眾的溝通測試，發(fā)現 FC 運行原理和云主機其實是不一樣的，一些擔憂點都可以被解決。對于 FC，每個請求都可以獨占實例資源，通過水平彈性擴展來承載大流量。比如同時有 10 個請求到 FC，那么 FC 就可以同時啟動 10 個同規(guī)格的容器來運行請求，當前請求執(zhí)行完后才會接下個請求，因此可以保障每個請求的 CPU 資源都是獨占的，而且請求間還可以做到故障隔離。

經過實際測試，發(fā)現 2G/約 1.33C 的資源規(guī)格可以滿足大部分的圖片識別場景，部分操作如加水印，還可以縮減到 512MB/約 0.33C（最小規(guī)格 128MB 內存/約 0.1C），達到最佳的資源使用配比，以節(jié)省費用。而針對體積較大的算法包，通過掛 NAS 盤的方式，也可以解決。在彈性方面，函數計算可以做到百毫秒級的彈性伸縮（冷啟動），對 APP 端的 API 接口，端到端平均響應大約在 300ms 左右，基本可以滿足；對圖片識別來講，因為是異步調用，所以對延遲并不敏感。最終上線后，大致的業(yè)務架構如下：

經過一段時間的線上運行，函數計算比較好的承載了線上的業(yè)務，彈性能力和響應耗時基本都符合業(yè)務訴求。業(yè)務峰值的時候，會擴容 7K 多個容器實例同時處理圖片識別，峰谷的時候，實例會自動回縮。相比之前云主機的使用方式，費用節(jié)省至少在 50% 以上。另外還有個顯著的好處是，函數計算對發(fā)布部署效率的提升，發(fā)布時間大概縮短了一個數量級，而且更加便捷。之前采用云主機部署的方式，全量更新代碼需要寫腳本每臺機器上運行一遍，而 FC 只用上傳一次代碼后，底層的機器會自動替換成最新的代碼，業(yè)務還能不中斷。

函數計算的優(yōu)化升級

但是隨著業(yè)務的不斷發(fā)展，峰值處理圖片的數量也在一直變大，一向穩(wěn)如泰山的 FC 在業(yè)務高峰期，逐漸開始產生一些流控和超時的報錯，如下圖：

經過排查發(fā)現，原來 FC + NAS 掛載算法依賴的方式運行代碼，在業(yè)務高峰時，會遇到帶寬瓶頸，導致部分請求運行耗時變大，加劇了并發(fā)的消耗，最終導致被流控和運行超時。如監(jiān)控顯示，原來在 NAS 中放置的代碼依賴大概有 1GB 多，當并發(fā)被陡然拉起時，大量的 FC 實例會去 NAS 加載依賴，造成網絡擁堵。最直接的辦法是直接升級 NAS 實例的帶寬，但是治標不治本。而經過 1 年多的發(fā)展，函數計算也增加了非常多的實用功能，和分眾溝通后，推薦直接用鏡像的方式來部署。對比原先 ZIP 包的部署方式，會增加一步打鏡像的操作，但是帶來的收益更加明顯，首先依賴包和業(yè)務代碼可以一起部署維護，鏡像的方式更加標準；另外也可以省掉 NAS 盤，降低了網絡依賴和單點故障風險。

部署過程當中也面臨另外個問題，鏡像太大！Python 3.8 基礎鏡像接近 1GB，所有算法依賴接近 3GB，最終生成的鏡像有 4.2GB。直接部署到 FC，冷啟動過程當中單單加載鏡像就要 1 分多鐘，幸好 FC 提供了鏡像加速能力，加載時間極大的縮短到了 10 秒左右，如下是加速效果的對比。

另外，FC 也支持了大規(guī)格實例，可以直接部署16C32GB大規(guī)格實例，對一些強依賴CPU資源的算法，也可以直接部署到FC上運行。還有個比較好的功能，是 FC 在可觀測方面的增長，像之前提到的CPU和內存使用率，也都開放支持了。在服務配置功能里，開啟實例級別的監(jiān)控后，在函數的監(jiān)控視圖下，就可以看到實例的 CPU 使用率、內存使用率、網絡帶寬情況等。這個對對分眾的業(yè)務來講，非常有用，針對不同的圖片處理算法，可以根據 CPU 使用情況，來調整 FC 運行的規(guī)格，可以最大化的平衡成本和性能。

總結和展望

FC 在降本增效方面，有著非常不錯的吸引力。尤其是對有波峰波谷和需要極速彈性的業(yè)務，是非常好的選型。另外像鏡像部署、鏡像加速、可觀測等能力的增強，可以讓分眾更好的駕馭業(yè)務。

FC 最近還發(fā)布支持了 GPU 掛載能力，在業(yè)界也是首創(chuàng)，對后續(xù)需要依賴 GPU 推理加速的算法模型，也是個不錯的選擇。利用 Serverless 彈性伸縮和按需付費的優(yōu)勢，可以大大降低 GPU “用不起” 的現狀。

阿里云的 Serverless 不僅有函數計算平臺，針對微服務應用，也在業(yè)界最先推出了 Serverless 應用引擎 SAE，對目前分眾基于 K8s 部署的后臺微服務也有著明顯的優(yōu)勢：可以顯著降低資源維護成本，提升整體研發(fā)效能，而且可以做到零代碼改造平遷。后續(xù)會和分眾一起探索微服務 On Serverless 的最佳實踐。

總結

以上是生活随笔為你收集整理的费用节省 50%，函数计算 FC 助力分众传媒降本增效的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。