作者：吳松

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

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

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

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

云服務(wù)則用到 SLB、MQDT、轉(zhuǎn)碼服務(wù)、IoT 等等。先說一下 IoT，我們現(xiàn)在所有屏端都是用的都是阿里云的 IoT 服務(wù)。這項(xiàng)服務(wù)帶來的最大優(yōu)勢是屏端連通率大概可以保持在 95% 左右，這大大提升了團(tuán)隊(duì)工作效率。因?yàn)橐郧拔覀兊钠炼硕际且斯とゲ蹇ㄉ峡?，現(xiàn)在接入 IoT 之后，我們的業(yè)務(wù)量從原來的 50% 提升到了現(xiàn)在的 95%，也就是說，在外面 100 臺設(shè)備有 95 臺設(shè)備連網(wǎng)，這可以很好地支撐我們的業(yè)務(wù)，給我們的技術(shù)實(shí)現(xiàn)帶來了很大的價(jià)值。 

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

Serverless 的探索實(shí)踐

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

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

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

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

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

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

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

因此我們最后選擇了函數(shù)計(jì)算，因?yàn)樗幸韵?3 個(gè)突出優(yōu)勢：

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

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

• 可提供大規(guī)模的識別能力：當(dāng)我們請求每天上刊人員在早上六點(diǎn)、七點(diǎn)、八點(diǎn)上刊時(shí)，背后能夠?qū)崟r(shí)的，在固定時(shí)間提供算力；
  

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

 

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

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

All On Serverless 轉(zhuǎn)繁為簡

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

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

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

總結(jié)和思考

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

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

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