作者：洛浩

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

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

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

函數(shù)計(jì)算的落地實(shí)踐

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

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

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

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

FC 沒辦法常駐進(jìn)程，擔(dān)心彈性效率不足，影響響應(yīng)耗時(shí)。

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

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

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

函數(shù)計(jì)算的優(yōu)化升級(jí)

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

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

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

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

總結(jié)和展望

FC 在降本增效方面，有著非常不錯(cuò)的吸引力。尤其是對(duì)有波峰波谷和需要極速?gòu)椥缘臉I(yè)務(wù)，是非常好的選型。另外像鏡像部署、鏡像加速、可觀測(cè)等能力的增強(qiáng)，可以讓分眾更好的駕馭業(yè)務(wù)。

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

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

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。