北京米連科技有限公司成立於 2015 年，是國家高新技術企業，旗下品牌伊對 App 上線於 2018 年，專注於移動端交友和

相親，將影片、直播和線上紅娘創造性地融合在一起，開闢了影片戀愛社群的獨立賽道，為單身人群提供了全新的社交體驗。

截至 2020 年，伊對 App 註冊使用者已達 1 億，每月撮合線上相親活動約 1000 萬場，成為影片戀愛社交垂直領域最具影響力

的品牌之一。

業務需求

隨著伊對 App 業務的快速增長，核心應用的系統規模和系統複雜度也在經歷著翻天覆地的變化。伊對 App 技術團隊透過引

進新的技術手段，維護整套系統架構的技術先進性，以更好地支援業務需求，降低 IT 成本。從成立以來，伊對 App 的核心

系統架構完成了多次重大的升級，涉及微服務化、容器化、分散式資料庫、大資料和人工智慧等重要的技術，特別在 

Serverless 技術的探索方面，伊對 App 投入了很大精力，以充分享受到雲端計算時代資源快速彈性伸縮的價值。

在伊對 App 的業務場景裡面，影片直播是最為重要的環節，基於影片直播這個骨架，可以融入線上紅娘等多類創新業務模

式，這也對影片直播的內容安全提出了極高的要求。不論是自身透過 AI 技術對影片直播內容進行智慧分析，還是應對監管

的要求，都需要在每一路影片直播流開始後，根據固定頻率對影片進行截幀，並透過統一的稽核服務對截幀生成的圖片進行

處理。

在這個需求裡面，截幀服務承擔著關鍵職責，這個服務不僅需要透過 FFmpeg 命令對每一路直播影片流進行截幀操作，還

需要將生成的圖片儲存到物件儲存 OSS，並將截幀資訊寫入到 Kafka。這樣下游的截幀服務就能從 Kafka 上拉取截幀資訊，

並從截幀資訊中得到圖片在 OSS 中的地址，從而完成對於圖片的稽核。在這個架構中，引入 Kafka 是為了透過非同步處理機

制緩解稽核服務在業務高峰期的負載。

 業務痛點

FFmpeg 截幀命令使用非常簡單，但這是一個對於 CPU 算力要求非常高的操作。根據伊對 App 技術團隊的多次試驗，採

用 ECS 部署截幀服務，是一個相對成本最優的選擇。如果按照每秒鐘1次截幀的固定頻繁，1 臺 ECS 能夠同時支撐大約數百

路直播影片流的截幀任務。為了保障業務高峰期的資源儲備，伊對 App 準備了大量 ECS 來部署截幀服務。跟絕大多數互聯

網應用一樣，伊對 App 的負載也存在著波峰波谷，這樣的波動對伊對 App 整體的資源規劃帶來了極高的挑戰，如果按照固

定的 ECS 叢集規模來部署截幀服務，會存在兩個非常明顯的弊端：

• 為了支援業務高峰，必須按照高峰期的使用者量來評估叢集規模，在業務低峰期就會造成巨大的浪費。

  
  

• 在某些場景下，比如節假日效應的帶動，業務量會有突增，有可能需要對叢集進行臨時擴容，這種情況下往往擴容速度

  會 滯後於業務流的增速，造成部分業務的降級處理。

為了節省資源成本，伊對 App 也探索過很多種彈性伸縮策略，比如透過彈性 ECS 例項配合容器化的方式部署應用，以實現

叢集規模能動態適配真實業務量的變化。但這些策略的實現都比較複雜，彈性伸縮能力都相對滯後。其中根本的原因是在傳

統的服務架構中，一個應用啟動後都是長期保持執行的，在執行期間會併發會處理多個業務需求，不管業務量如何變化，這

個應用佔據的計算力都不會有本質的變化。

有沒有一種直截了當的方式，可以在一路直播影片流開啟後，拉起對應的計算力承接截幀任務，而在影片流關閉後，自動將

計算力釋放呢？這樣的方式不需要應用例項長駐，可以實現真正的計算資源按需分配，也不需要藉助額外的手段動態調整截

幀服務的叢集規模，是一種最為理想的方案。

作為雲原生 Serverless 技術的代表，阿里雲函式計算 FC 就正好實現了這樣的思路。

函式計算 FC 有哪些獨特之處

阿里雲自研的 Serverless 產品函式計算 FC 是事件驅動的全託管計算服務，完美契合了伊對 App 的需求和痛點。使用函式

計算，使用者無需採購與管理伺服器等基礎設施，只需編寫並上傳程式碼。函式計算會自動準備好計算資源，彈性地、可靠地運

行任務，並提供日誌查詢、效能監控和報警等功能。藉助函式計算 FC，可以快速構建任何型別的應用和服務，並且只需為任

務實際消耗的資源付費。

函式計算 FC 提供了一種事件驅動的計算模型，函式的執行是由事件驅動的。函式的執行可以透過函式使用者自己觸發，也可

以由其它一些事件源來觸發。可以在指定函式中建立觸發器，該觸發器描述了一組規則，當某個事件滿足這些規則，事件源就

會觸發相應的函式。比如對於 HTTP 觸發起而言，使用者的一次 HTTP 請求就能觸發一個函式；而對於 OSS 觸發器而言，OSS

 上新增或修改一個檔案就能觸發一個函式。在伊對 App 的影片截幀場景中，函式只需要在每一個直播流開始推送之前，透過

業務程式主動觸發一個截幀函式就可以了。因此之前截幀業務的架構只需要做很小的調整，就能遷移到函式計算平臺上來，以

享受 Serverless 的價值。

解決方案及優勢

1、支援多種程式語言的 Runtime

伊對 App 的技術團隊第一次和阿里雲溝通 Serverless 方案的時候，阿里雲的技術人員推薦使用 Python 語言實現截幀函式，

因為函式計算 FC 對於 Node.js、Python、PHP、Java 等語言提供了原生的執行環境，而且像 Python 這樣的指令碼語言可以

實現在函式計算平臺上直接修改排程程式碼，使用非常簡單。

其實函式計算 FC 對於開發語言沒有要求，任何主流的開發語言都可以很好的支援。透過函式計算 FC 提供的 Custom 

Runtime，可以為任務語言建立自定義的執行環境。Custom Runtime 本質上是一個 HTTP Server，這個 HTTP Server 

接管了函式計算系統的所有請求，包括來自事件呼叫或者 HTTP 函式呼叫。

 2、極致彈性和高可用性

由於在 Serverless 架構下，每一路直播影片流都會拉起新的計算資源來承接截幀任務，因此並不需要採用高規格的 ECS 

例項同時併發處理多個截幀任務。透過反覆的測試，伊對 App 採取了最適合的函式計算例項來完成每路影片流的截幀任務。

函式計算 FC 在計算資源的啟動方面做了大量最佳化，配合雲化的資源池，能夠在 100 毫秒的時間內排程大量計算例項，以承

載特殊情況下突增的業務流量。

為了更進一步的適配伊對 App 的業務場景，阿里雲函式計算團隊還專門為伊對 App  提供了定時預熱的方式，以最大程度

的保障業務高峰期冷啟動計算資源的效能。這樣極致的彈性伸縮能力是 Serverless 的專長，傳統的應用架構的彈性伸縮依

賴於底層計算資源的排程，以及複雜的初始化工作，在計算例項的啟動速度上遠遠達不到這個水平。

正常情況下，函式計算 FC 上一個普通彈性例項可執行時長為 10 分鐘，此外還提供了效能例項，以應對更高的資源需求，

效能例項在可執行時長上也提升到了數小時。在伊對 App 的截幀場景中，單例項並不需要有很高的效能，但有必要伴隨著

直播影片流長期執行，因此阿里雲也為伊對 App 適當放開了彈性例項的執行時長限制：達到 1 小時。

對於超過 1 小時的直播，同樣可以支援：在截幀場景中，當一個函式例項將要達到執行時長限制的時候，只需要再拉起一個

新的函式例項對截幀任務進行接力就可以了，對於截幀業務的正常執行不會有任何影響。

 3、節省資源，降本增效

函式計算 FC 在實現計算資源按需排程，按量計費的同時，還透過預留例項的模型更進一步降低使用成本。根據初步的評估，

在直播截幀這個業務場景上，透過基於函式計算 FC 的 Serverless 架構，能夠幫助伊對 App 減少 20% 以上的資源成本 開支。 

此外，由於函式計算 FC 不需要預留計算資源，也不需要對底層的軟硬體進行維護，極大程度降低了運營成本，可以讓伊

對 App 的技術團隊更專注在複雜業務邏輯的實現上，這也是 Serverless 技術為廣大企業和開發者帶來的巨大價值之一。  

總結

在直播截幀場景試點 Serverless 技術成功後，伊對 App 繼續在更多業務領域發掘 Serverless 技術的匹配場景。未來，

伊對 App 將繼續基於自身的技術特點不斷深入探索 Serverless 架構，在擁抱新技術的同時，也能充分享受到雲端計算的紅利。