作者：吳松

本文總結于分眾傳媒研發(fā)總監(jiān)吳松在阿里云云原生實戰(zhàn)峰會上的分享，從三個方面講述了對 Serverless 技術的探索。

分眾傳媒的業(yè)務現(xiàn)狀

分眾傳媒的業(yè)務場景很簡單，就是廣告主買量，然后進行投放排期和統(tǒng)計，最后進行效果展示。業(yè)務場景前期要做廣告設計、視頻處理，后期還有一個廣告投放、效果展示，可能會給客戶提供各種各樣的數(shù)據(jù)展示。分眾傳媒主要的業(yè)務形態(tài)有靜態(tài)海報（市場占有率超過 73%），電梯屏幕 30 萬塊，覆蓋 91% 中高檔的寫字樓。 

 我們把云原生應用架構應用于手機 APP 和視頻終端，而業(yè)務應用則有很多，比如員工接入、CRM、視頻處理、圖片識別、數(shù)據(jù)上報、數(shù)據(jù)分析、視頻直播。其中，視頻直播是新開發(fā)的業(yè)務，就是為了把直播視頻實時推到分眾傳媒的屏端上。

云服務則用到 SLB、MQDT、轉碼服務、IoT 等等。先說一下 IoT，我們現(xiàn)在所有屏端都是用的都是阿里云的 IoT 服務。這項服務帶來的最大優(yōu)勢是屏端連通率大概可以保持在 95% 左右，這大大提升了團隊工作效率。因為以前我們的屏端都是要人工去插卡上刊，現(xiàn)在接入 IoT 之后，我們的業(yè)務量從原來的 50% 提升到了現(xiàn)在的 95%，也就是說，在外面 100 臺設備有 95 臺設備連網(wǎng)，這可以很好地支撐我們的業(yè)務，給我們的技術實現(xiàn)帶來了很大的價值。 

另外，我們有 200 萬個靜態(tài)的電梯海報，每周都需要上刊，在上刊之后會有圖片處理的流程。這塊目前使用的是自動識別處理，每次上刊之后需要判斷圖片是否上錯或者圖片有沒有放反。這一系列操作現(xiàn)在全部可以實時通知到上刊人員，一旦出現(xiàn)上刊之后圖片放錯、放反的問題，可以及時通過手機短信通知到相關負責人，提醒他們立刻采取措施去解決，保證在一個小時之內(nèi)完成。

Serverless 的探索實踐

傳統(tǒng)服務器無法滿足我們的業(yè)務高速增長，主要有三大痛點。耗時太長、資源利用率低、運維復雜，對人員技能要求高。 

• 耗時太長：以前的人工上刊無法及時知道上刊是否正確或者錯誤，需要花費很多時間去核對和修改；

• 資源利用率低：上刊的主要業(yè)務是集中在周六和周日，因此所有資源基本在周六周日使用，大部分時間段是不需要使用服務器資源的；

• 運維復雜、人員技能要求高：大家都會遇到的常規(guī)痛點，由于業(yè)務的復雜度對相關業(yè)務人員的技能要求也高，同時也需要招聘更高級的人員來支持對應的運維工作。

于是，對于我們來說，上云有兩個選擇。第一個是用 K8s 服務自己搭建一套容器集群，第二個是用函數(shù)計算 FC。那我們是如何選擇的呢？

在選擇 Serverless 時，其實我們也有一些擔憂。第一是大規(guī)模的實踐案例，第二是圖象識別的算法往往很大，函數(shù)計算 FC 能否適用？第三，F(xiàn)C 最高規(guī)格只能支持 2C3GB，這對我們業(yè)務有很大的考驗。第四，是否可以提供 CPU 使用和內(nèi)存使用的監(jiān)控等等。這些都是我們很擔憂的一些問題。 

K8s 和 Serverless 運行原理的差異大家可以從上圖中看到，如果用 K8s 請求云主機，我們需要自己搭建 K8s，通過對外的 API 來提供請求；而使用 Serverless 計算平臺，我們不需要關心用了多少服務器或者多少人力，我們只需要關心每一次 API 請求是否正確到達和觸達，就可以確認每次的圖象識別是否有確切識別到圖片，并把識別錯誤的東西發(fā)出來，通知到上刊人員。 

因此我們最后選擇了函數(shù)計算，因為它有以下 3 個突出優(yōu)勢：

• 自動彈性收縮：比如只需要告訴他每周六每周日有兩百萬處理量，要在兩天完成，其中高峰是早上九到十點或者下午三到四點，就可以實現(xiàn)資源的自動彈性收縮；
  

• 資源免運維：解決我們需要請專業(yè)人員來負責支持運維的痛點；
  

• 可提供大規(guī)模的識別能力：當我們請求每天上刊人員在早上六點、七點、八點上刊時，背后能夠實時的，在固定時間提供算力；
  

我們用到很多開發(fā)語言，例如 PHP、C++、Python，如果用 K8s 去改造，難度很大。但如果用 Serverless，改造成本就小很多。

 

我們在圖片識別系統(tǒng)進行了的初步試水，就是剛才說的我們分眾有兩百萬電梯海報，每周上刊需要每張圖片精準送達。所以說我們在上線圖片識別系統(tǒng)時，每一張圖片都會上傳 OSS，通過 OSS 打通我們 MNS 服務，再把消息發(fā)送到函數(shù)計算 FC，然后再對消息進行處理，之后就可以對圖片進行加水印、圖象識別、圖片匹配了，從而可以精準地告訴正在上刊的工人，你的圖片上刊成功了，可以上刊下一張圖片了。 

在這個業(yè)務峰值圖上可以看到，F(xiàn)C 支持一分鐘內(nèi)擴充到 7000+ 的實例。如果我們自己部署 K8s 會牽扯到很多人力和物力，因此我們最終選擇了 Serverless。

All On Serverless 轉繁為簡

2021 年年底我們對 Serverless 進行了業(yè)務升級。以前服務是在 NAS 上，這會導致我們們必須實時關注 NAS 有沒有掛掉，因為 NAS 掛掉的話，F(xiàn)C 業(yè)務就啟動不起來了。比如我們周末排查業(yè)務時發(fā)現(xiàn) NAS 掛掉了，導致算法接不進這類問題。于是，我們對服務端就進行了升級，把業(yè)務放在容器里，通過鏡像來部署，這樣可以提高緩存，解決很大的高峰時的業(yè)務問題，鏡像啟動比以前通過 NAS 掛載要快很多，這是對業(yè)務提升最大的地方。 

升級后的 Serverless 提供了豐富的監(jiān)控指標提升監(jiān)控效率，提升了很多錯誤統(tǒng)計、CPU 效率等指標，可以基于監(jiān)控數(shù)據(jù)快速定位到現(xiàn)在業(yè)務運行狀態(tài)。通過Serverless的實踐，可以讓我們的開發(fā)更關注到業(yè)務開發(fā)里，比如可以讓圖象識別的開發(fā)人員更關注圖象識別的識別率，把更多運維工作交給 FC 去處理，所以說 Serverless 給我們提供了極致彈性、自動擴容、應對流量突增、讓開發(fā)更加關注業(yè)務等益處。

我們用了 Serverless 之后，可以看到團隊的開發(fā)運維效率提升了 80%，計算成本下降了 50%。以前我們會部署很多的服務器，以及 GPU 服務器去實現(xiàn)我們的圖像算法的一塊業(yè)務，現(xiàn)在我們都不用了，彈性效果提升了十倍以上。

總結和思考

我們現(xiàn)在將 Serverless 主要應用于圖象識別算法上，他具有 CPU 密集型、對彈性有極致要求的特點。此外，Serverless 也適用于事件驅動的業(yè)務模型，來簡化架構復雜度，從而不需要關注背后的東西。如果用 K8s，這會牽扯到很多的業(yè)務邏輯。 

后續(xù)，我們還會考慮將 Serverless 和 Kafka 進行結合，用在大數(shù)據(jù)的處理上，這樣的效率會更的，簡化Flink的使用成本。視頻直播業(yè)務上，直播流實時推送到視頻終端的部分，也是我們嘗試使用 Serverless 來解決。 

微服務方面，我們也正在考慮另一款 Serverless 形態(tài)的產(chǎn)品——Serverless 應用引擎 SAE，來簡化我們的運維、提高效率，值得期待。