作者：吳松

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

## 分眾傳媒的業務現狀

![在這裡插入圖片描述](https://img-blog.csdnimg.cn/54d6578561954d66a11f736c7c9d4e20.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA6Zi_6YeM5be05be05LqR5Y6f55Sf,size_20,color_FFFFFF,t_70,g_se,x_16#pic_center)

分眾傳媒的業務場景很簡單，就是廣告主買量，然後進行投放排期和統計，最後進行效果展示。業務場景前期要做廣告設計、影片處理，後期還有一個廣告投放、效果展示，可能會給客戶提供各種各樣的資料展示。分眾傳媒主要的業務形態有靜態海報（市場佔有率超過 73%），電梯螢幕 30 萬塊，覆蓋 91% 中高檔的寫字樓。
 
![在這裡插入圖片描述](https://img-blog.csdnimg.cn/4e1c1236198b47129539d05adad2280a.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA6Zi_6YeM5be05be05LqR5Y6f55Sf,size_20,color_FFFFFF,t_70,g_se,x_16#pic_center)

我們把雲原生應用架構應用於手機 APP 和影片終端，而業務應用則有很多，比如員工接入、CRM、影片處理、圖片識別、資料上報、資料分析、影片直播。其中，影片直播是新開發的業務，就是為了把直播影片實時推到分眾傳媒的屏端上。

![在這裡插入圖片描述](https://img-blog.csdnimg.cn/75a2fc3d63b64dc89dbf4a23440d27da.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA6Zi_6YeM5be05be05LqR5Y6f55Sf,size_20,color_FFFFFF,t_70,g_se,x_16#pic_center)

雲服務則用到 SLB、MQDT、轉碼服務、IoT 等等。先說一下 IoT，我們現在所有屏端都是用的都是阿里雲的 IoT 服務。這項服務帶來的最大優勢是屏端連通率大概可以保持在 95% 左右，這大大提升了團隊工作效率。因為以前我們的屏端都是要人工去插卡上刊，現在接入 IoT 之後，我們的業務量從原來的 50% 提升到了現在的 95%，也就是說，在外面 100 臺裝置有 95 臺裝置連網，這可以很好地支撐我們的業務，給我們的技術實現帶來了很大的價值。
 
另外，我們有 200 萬個靜態的電梯海報，每週都需要上刊，在上刊之後會有圖片處理的流程。這塊目前使用的是自動識別處理，每次上刊之後需要判斷圖片是否上錯或者圖片有沒有放反。這一系列操作現在全部可以實時通知到上刊人員，一旦出現上刊之後圖片放錯、放反的問題，可以及時透過手機簡訊通知到相關負責人，提醒他們立刻採取措施去解決，保證在一個小時之內完成。

## Serverless 的探索實踐

![在這裡插入圖片描述](https://img-blog.csdnimg.cn/72a800c6c18a48f2b2d988221c397b4a.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA6Zi_6YeM5be05be05LqR5Y6f55Sf,size_20,color_FFFFFF,t_70,g_se,x_16#pic_center)

傳統伺服器無法滿足我們的業務高速增長，主要有三大痛點。耗時太長、資源利用率低、運維複雜，對人員技能要求高。
 
- 耗時太長：以前的人工上刊無法及時知道上刊是否正確或者錯誤，需要花費很多時間去核對和修改；

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

- 運維複雜、人員技能要求高：大家都會遇到的常規痛點，由於業務的複雜度對相關業務人員的技能要求也高，同時也需要招聘更高階的人員來支援對應的運維工作。
 
於是，對於我們來說，上雲有兩個選擇。第一個是用 K8s 服務自己搭建一套容器叢集，第二個是用函式計算 FC。那我們是如何選擇的呢？

![在這裡插入圖片描述](https://img-blog.csdnimg.cn/e069406e56904070a77f0232c18c2623.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA6Zi_6YeM5be05be05LqR5Y6f55Sf,size_20,color_FFFFFF,t_70,g_se,x_16#pic_center)

在選擇 Serverless 時，其實我們也有一些擔憂。第一是大規模的實踐案例，第二是圖象識別的演算法往往很大，函式計算 FC 能否適用？第三，FC 最高規格只能支援 2C3GB，這對我們業務有很大的考驗。第四，是否可以提供 CPU 使用和記憶體使用的監控等等。這些都是我們很擔憂的一些問題。
 
K8s 和 Serverless 執行原理的差異大家可以從上圖中看到，如果用 K8s 請求雲主機，我們需要自己搭建 K8s，透過對外的 API 來提供請求；而使用 Serverless 計算平臺，我們不需要關心用了多少伺服器或者多少人力，我們只需要關心每一次 API 請求是否正確到達和觸達，就可以確認每次的圖象識別是否有確切識別到圖片，並把識別錯誤的東西發出來，通知到上刊人員。
 
因此我們最後選擇了函式計算，因為它有以下 3 個突出優勢：

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

- **資源免運維**：解決我們需要請專業人員來負責支援運維的痛點；

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

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

![在這裡插入圖片描述](https://img-blog.csdnimg.cn/32e81d71375b425ab328469b4632633e.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA6Zi_6YeM5be05be05LqR5Y6f55Sf,size_20,color_FFFFFF,t_70,g_se,x_16#pic_center)

我們在圖片識別系統進行了的初步試水，就是剛才說的我們分眾有兩百萬電梯海報，每週上刊需要每張圖片精準送達。所以說我們在上線圖片識別系統時，每一張圖片都會上傳 OSS，透過 OSS 打通我們 MNS 服務，再把訊息傳送到函式計算 FC，然後再對訊息進行處理，之後就可以對圖片進行加水印、圖象識別、圖片匹配了，從而可以精準地告訴正在上刊的工人，你的圖片上刊成功了，可以上刊下一張圖片了。
 
在這個業務峰值圖上可以看到，FC 支援一分鐘內擴充到 7000+ 的例項。如果我們自己部署 K8s 會牽扯到很多人力和物力，因此我們最終選擇了 Serverless。

## All On Serverless 轉繁為簡

2021 年年底我們對 Serverless 進行了業務升級。以前服務是在 NAS 上，這會導致我們們必須實時關注 NAS 有沒有掛掉，因為 NAS 掛掉的話，FC 業務就啟動不起來了。比如我們週末排查業務時發現 NAS 掛掉了，導致演算法接不進這類問題。於是，我們對服務端就進行了升級，把業務放在容器裡，透過映象來部署，這樣可以提高快取，解決很大的高峰時的業務問題，映象啟動比以前透過 NAS 掛載要快很多，這是對業務提升最大的地方。
 
升級後的 Serverless 提供了豐富的監控指標提升監控效率，提升了很多錯誤統計、CPU 效率等指標，可以基於監控資料快速定位到現在業務執行狀態。透過Serverless的實踐，可以讓我們的開發更關注到業務開發裡，比如可以讓圖象識別的開發人員更關注圖象識別的識別率，把更多運維工作交給 FC 去處理，所以說 Serverless 給我們提供了極致彈性、自動擴容、應對流量突增、讓開發更加關注業務等益處。

![在這裡插入圖片描述](https://img-blog.csdnimg.cn/b619936f22834b399a00675182af5fb6.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA6Zi_6YeM5be05be05LqR5Y6f55Sf,size_20,color_FFFFFF,t_70,g_se,x_16#pic_center)

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

## 總結和思考

我們現在將 Serverless 主要應用於圖象識別演算法上，他具有 CPU 密集型、對彈性有極致要求的特點。此外，Serverless 也適用於事件驅動的業務模型，來簡化架構複雜度，從而不需要關注背後的東西。如果用 K8s，這會牽扯到很多的業務邏輯。
 
後續，我們還會考慮將 Serverless 和 Kafka 進行結合，用在大資料的處理上，這樣的效率會更的，簡化Flink的使用成本。影片直播業務上，直播流實時推送到影片終端的部分，也是我們嘗試使用 Serverless 來解決。
 
微服務方面，我們也正在考慮另一款 Serverless 形態的產品——Serverless 應用引擎 SAE，來簡化我們的運維、提高效率，值得期待。

點選[此處](https://developer.aliyun.com/community/cloudnative)，前往雲原生子社群檢視更多相關資訊。

開發運維效率提升 80%，計算成本下降 50%，分眾傳媒的 Serverless 實踐

相關文章