Serverless應用場景

• Serverless 演進
• Serverless的典型應用有哪些？
• 場景一：事件觸發計算能力
• 場景二：利用彈性擴容（視頻直播多人連麥場景）
• 場景三：物聯網數據處理場景
• 場景四：共享派單系統詳解
• 總結
• 更多信息

Serverless架構是近年來迅速興起的一個技術概念。基于這種架構能構建出多種應用場景，適用于各行各業。只要是對輕計算、高彈性、無狀態等場景有訴求，您都可以通過本文來熟悉一些基礎概念，并從相關場景中獲得啟發。

Serverless 演進

關于Serverless架構的演進，網上比較流行用一張人類形態發展史圖進行說明。從爬行猿人到蹲著的類猿人，再到直立人類，最后到使用工具的新興人類。

人類的每一次進化都伴隨著生產效率的提升。同理，整個IT計算的發展歷程，也是一個逐步提高生產效率的歷程，具體演進圖如下所示：

在這個發展歷程中有以下幾個漸進的里程碑事件：

通過虛擬化技術將大型物理機虛擬成單個的VM資源。

將虛擬化集群搬到云計算平臺上，只做簡單運維。

把每一個VM按照運行空間最小化的原則切分成更細的Docker容器。

基于Docker容器構建不用管理任何運行環境、僅需編寫核心代碼的Serverless架構。

因此，這個發展歷程也是一場IT架構的演進，期間經歷了一系列代際的技術變革，把資源切分得更細，讓運行效率更高，讓硬件軟件維護更簡單。IT架構的演進主要有以下幾個特點：

• 硬件資源使用顆粒度變小
• 資源利用率越來越高
• 運維工作逐步減少
• 業務更聚焦在代碼層面

Serverless架構主要有以下特點：

• 實現了細粒度的計算資源分配。
• 不需要預先分配資源。
• 具備真正意義上的高度擴容和彈性。
• 按需使用，按需計費。

根據Serverless的這些通用特點，歸納出下面幾種典型使用場景，供大家參考。

Serverless的典型應用有哪些？

事件請求場景

• 定制圖片

  網店店家進行商品圖片維護時，需要根據商品陳列位置，將圖片動態切割成不同尺寸，或者打上不同水印。當店家把圖片上傳到對象存儲 OSS上，會通過函數計算上定制的trigger來觸發函數計算。根據計算規則，生成不同尺寸的圖片，滿足在線商品陳列需求，整個過程無需再搭建額外服務器，也無需網站美工干預。

• 物聯網中的低頻請求

  物聯網行業中，物聯網設備傳輸數據量小，且往往是以固定時間間隔進行數據傳輸，因此經常涉及低頻請求場景。例如：物聯網應用程序每分鐘僅運行一次，每次運行 50ms，這意味著CPU的使用率僅為 0.1%/小時，或者說有 1000 個相同的應用可以共享計算資源。而Serverless架構下，用戶可以購買每分鐘 100ms 的資源來滿足計算需求，既能有效解決效率問題，也能降低使用成本。

• 定制事件

  用戶注冊時發郵件驗證郵箱地址，同樣可以通過定制的事件來觸發后續的注冊流程，而無需再配置額外的應用無服務器來處理后續的請求。

• 固定時間觸發

  事件觸發固定時間觸發，例如在夜間或者服務空閑時間來處理繁忙時候的交易數據，或者運行批量數據，來生成數據報表，通過Serverless方式，不用再額外購買利用率并不高的處理資源。

流量突發場景

• 彈性擴展應對突發流量

  移動互聯網應用經常會面對突發流量場景。例如：移動應用的通常流量情況是 QPS 20，但每隔 5 分鐘會有一個持續 10s 的 QPS 200 流量（10 倍于通常流量）。傳統架構下，企業必須擴展 QPS 200 的硬件能力來應對業務高峰，即使高峰時間僅占整個運行時間的4%。

  在Serverless架構下，您可以利用彈性擴展特性，快速構建新的計算能力來滿足當前需求，當業務高峰后，資源能夠自動釋放，有效節省成本。

• 轉碼和流量擴容

  視頻直播某次專場活動，由于無法預估會有多少點播的觀眾視頻接入，把轉碼和流量擴容這部分內容通過Function來處理，無需考慮并發和流量擴容。

處理大數據場景

由于安全審計問題，您需要從OSS（多個地域）過去一年的數據（1 個小時一個文件）中找出特定關鍵字訪問的日志，同時做聚合運算（計算出總值）。如果使用阿里云函數計算，您將高峰期每 2 小時的訪問日志，或者低谷期每 4 小時的訪問日志交給一個計算函數處理，并將處理結果存到RDS中。使用一個函數分派數據給另一個函數，使其執行成千上萬個相同的實例。

這樣會同時運行近千個計算函數（24 x 365 / 10），在不到一分鐘的時間內完成整個工作。同樣的事情交給ECS+計算腳本來做計算，單單為這些instance配置網絡就讓人頭疼（不同地域無法走內網下載OSS文件）：instance的數量可能已經超出了子網中剩余IP地址的數量（比如，您的VPC使用了24位掩碼）。

下面結合阿里云的函數計算產品來講解各個應用場景中地架構以及如何解決場景中的痛點。阿里云的函數計算是基于Serverless這種架構實現的一個全托管產品，用戶只需要上傳核心代碼到函數計算，就可以通過事件源或者SDK&API來運行代碼。函數計算會準備好運行環境，并根據請求峰值來動態擴容運行環境。函數計算是按照執行時間來計費，請求處理完成后，計費停止，對于有業務請求有明顯高峰和低谷的應用來說，相對節省成本。

下圖是函數計算的一個開發者試用操作流程：

開發者編寫代碼，目前支持的語言Java、NodeJS、Python等語言。

把代碼上傳到函數計算上，上傳的方式有通過API或者SDK上傳，也可以通過控制臺頁面上傳上傳，還可以通過命令行工具Fcli上傳。

通過API&SDK來觸發函數計算執行，同樣也可以通過云產品的事件源來觸發函數計算執行。

函數計算在執行過程中，會根據用戶請請求量動態擴容函數計算來保證請求峰值的執行，這個過程對用戶是透明無感知的。

函數執行結束后，可以通過賬單來查看執行費用，根據函數的實際執行時間按量計費，收費粒度精確到100ms。

講解完上面的流程后，下面會詳細講解3個Serverless的應用場景，通過案例分享能讓您對Serverless這種架構有更清晰的認識。

場景一：事件觸發計算能力

場景描述

用戶通過手機終端、Web應用、或者PC工具把各種文件包括圖片、視頻以及文本等上傳到OSS（對象存儲，下同）后，利用OSS的PutObject事件可以觸發函數計算對上傳后的文件進行處理。

典型場景

當用戶把視頻文件上傳到OSS后，觸發函數計算把對象的Meta信息獲取并傳輸給核心算法庫，核心算法庫根據算法把相應的視頻文件推送CDN源站，達到特定視頻熱加載的處理。另外一個場景，視頻文件上傳到OSS后也同時觸發函數計算同步做多轉碼率的處理，并把處理后的視頻文件存儲到OSS中，完成輕量的數據處理。

在多媒體的處理場景中，經常會碰到海量文件上傳到OSS后，還需要對文件進行進一步的加工，例如加水印、轉碼率、獲取文件屬性等操作，這個場景中，用戶在處理的時候會遇到以下需要解決的技術難點：

• 如何接收文件上傳后的動作事件，通常的做法是定制消息通道來接收OSS事件通知，搭建一個運行環境，并編寫相關的代碼來處理事件通知。
• 如何高效的處理完海量上傳的文件。
• 如何無縫的把多個云產品連接起來。

通過函數計算能比較方便解決以上幾個技術難點：

• 函數計算可以設置OSS的觸發器來接收事件通知，在函數計算中編寫業務代碼來處理文件，并通過內網把文件傳輸到OSS中，整個流程簡單易用可擴展。
• 可以把核心代碼部署到函數計算中，通過函數計算來并發處理事件通知。
• 函數計算目前打通了多款產品的內部交互，通過控制臺簡單配置就可以高效的解決產品間連接問題。

事件觸發場景常規做法：

• 設置消息通道接收事件，并編寫業務代碼。
• 購買服務器資源做后端數據處理。
• 設計一套多并發框架完成業務上傳文件峰值的處理。
• 開通多個產品，并調用SDK代碼來完成業務交互。

函數計算解法：

• 在控制臺上配置事件源通知，編寫業務代碼。
• 代碼寫到函數計算里，不需要管理軟硬件環境。
• 業務高峰期函數計算會動態伸縮，無需管理。
• 內置打通多款產品，簡單配置就可以無縫對接。

場景二：利用彈性擴容（視頻直播多人連麥場景）

場景描述

直播間的客戶端把主播和連麥觀眾的音視頻采集發送給函數計算做混流服務，函數計算把數據匯集后交給混流服務進行合成，并把合成畫面視頻流推送給CDN，終端觀眾實時拉取直播流，能實時看到混流合成畫面。

視頻直播應用場景中，有一種場景視頻直播的多人連麥，主播可以同時和多個工作進行連麥，把多個觀眾或者好友畫面接入，并把畫面合成到一個場景中，供給更多觀看直播的觀眾觀看。這個場景中，有幾個技術難度需要關注：

• 連麥的觀眾不固定，需要考慮適度的并發和彈性。
• 直播不可能 24 小時在線，有較為明顯的業務訪問高峰期和低谷期。
• 直播是事件或者公眾點爆的場景，更新速度較快，版本迭代較快，需要快速完成對新熱點的技術升級。

綜合以上幾個特點，可以通過Serverless這種架構來完美地解決以上痛點。

函數計算作為連麥觀眾和主播接入的實時音頻和視頻轉發集群，當并發量過來時，函數計算自動擴容多個執行環境來處理實時數據流；當業務高峰期過去后，會適度縮減資源使用。代碼管理部署在云端，代碼迭代可以隨時進行修改和維護，無需再多管理一套軟件運行環境。

視頻直播場景常規做法：

• 購買負載均衡應付并發。
• 購買計算資源做數據處理。
• 業務低谷期需要想辦法釋放硬件資源來節省成本。
• 多版本要維護多套運行環境。

函數計算解法：

• 把負載分發程序寫到函數里。
• 多版本迭代無需更換運行環境，僅僅替換代碼版本即可。
• 業務訪問按需付費，業務低谷期無費用。

場景三：物聯網數據處理場景

整個架構圖分成 2 部分內容：

• Web應用：模擬一個社交內容更新和數據處理的流程，Web用戶通過API網關把請求轉發到函數計算進行處理，函數計算把處理后的內容更新到數據庫中，并更新索引，另外一個函數計算把索引更新推送的搜索引擎供給外部客戶進行檢索，完成整個數據閉環處理。
• 智能設備：通過IoT網關把設備狀態推送到函數計算處理，函數計算通過API接口把消息通過移動推送服務，推送給移動端進行狀態確認和管理。

在智能設備狀態處理的場景中，同樣也會碰到幾個核心技術問題要解決。當海量設備把狀態發送到IoT平臺后，如何設計一套高效非輪詢的技術框架來處理設備狀態數據；如何把處理后的數據高效透傳其他產品，例如寫數據庫或者推送給移動端。

IoT設備狀態場景常規做法：

• 設置消息通道接收事件，并編寫業務代碼。
• 購買服務器資源做后端數據處理。
• 開通多個產品，并調用SDK代碼來完成業務交互。
• 維護相關硬件軟件環境。

函數計算解法：

• 定制IoT平臺的事件通知，直接把業務代碼寫到函數計算中。
• 不需要維護運行環境，用完即可釋放。
• 控制臺配置，就可以把信息透傳給相關產品。

通過 2 種方式的對比，能看出函數計算的解法更具備通用性，可以大量減少維護工作。

場景四：共享派單系統詳解

客戶通過派單平臺選著某種商家提供的服務，可能是餐飲、商品、或者服務。派單平臺通知最近的騎手到最近的商家拿到服務并派送到客戶手里。一個簡單的流程圖如下：

流程詳解：

客戶通知派單平臺下單某商品。

派單平臺通知最新騎手。

派單平臺同時通知商家商品售賣出去。

騎手到指定的商家獲取商品。

騎手配送到客戶所在地。

這個派單場景中，要解決幾個棘手的技術：

• 整合多種資源，計算資源會涉及到，騎手位置信息、最優路徑規劃、車況情況、調度系統等。
• 低延遲：派單系統對訂單的響應要求很高，從接單到商家在到客戶，整個閉環都需要在段時間內完成。
• 海量數據：涉及到三方面的數據，客戶數據、商家數據、平臺騎手數據、位置信息、商品信息等。
• 請求明顯波峰波谷：派單系統在一天中的資源使用非常不均衡，波峰期，例如外賣，在中午和晚飯達到高峰，平時空閑。

通過技術選型轉化成阿里云產品的解決方案后，函數計算結合其他產品比較完美地解決上述問題，解決方案如下圖所示：

流程詳解：

客戶APP把訂單請求通過API網關透傳給函數計算。

函數計算把處理后的數據傳輸給表格存儲。

表格存儲存放了騎行數據、商家信息、位置信息等。

說明?其中騎行日志會存放到日志服務里，便于后續做報表分析。騎行過程中騎手頭像、隨手拍街景會存放到OSS中，騎手位置可以通過函數計算去拉取第三方地圖信息，例如高德地圖等。

這個方案中，函數計算可以完成動態擴容問題，API網關可以解決鑒權和安全訪問問題，函數計算打通了多款產品，可以無縫使用其他資源和內容。所有處理后的數據可以存放到表格存儲數據庫中，所有日志都可以直接加載到日志服務為后續數據報表服務。

共享派單系統常規做法：

• 購買多臺服務器來支持高峰期的訪問，訪問波谷期自行設置釋放原則。
• 通過編程方式完成多個產品的交互。
• 為了保證負載均衡，需要購買相關的產品來支撐。
• 維護相關硬件軟件環境。

函數計算解法：

• 定制IoT平臺的事件通知，直接把業務代碼寫到函數計算中。
• 不需要維護運行環境，用完即可釋放。
• 控制臺配置，就可以把信息透傳給相關產品。
• 2種解法都能達到目標，從資源利用率和可維護性來看，使用Serverless架構的方式會更優。

總結

通過上面幾個場景的詳解，大致可以得出這樣的結論：通過事件觸發場景；有業務訪問高峰和低谷的場景，迭代次數較多，需要快速打通多款產品場景；通過函數計算能完美地解決成本、效率、聯通等問題。

?函數計算自建計算環境

維護性	內置打通API網關，OSS，Table Store、IoThub、Log Service、Message Service、Datahub等產品，只需要簡單配置。沙箱執行環境，無需配置。 自動伸縮和負載均衡。 觸發條件簡單，入口多。	多款產品鏈接需要自己編寫代碼來實現，有技術門檻。 自建物理環境，需要配置運行環境，消耗人力物力。 需要自行搭建伸縮機制和負載均衡，耗時較多。
可靠性	代碼和配置存放在OSS中，自動多重冗余備份。	受限于硬件可靠性，易出問題，一旦出現運行環境或者數據損壞，容易出現不可逆轉的數據丟失。 人工數據恢復困難、耗時、耗力。
成本	按執行付費，在業務請求波谷期費用低廉。 上行流量免費 無需運維人員和托管費用 阿里云產品內部傳輸無費用 同比計算能力，成本節省1/3	業務請求的波峰需要資源擴容，波谷的時候資源浪費。 需要專人維護運行環境和硬件資源，人力成本較高。 產品之間聯通如果走公網，需要額外支付流量費用。
安全	沙箱運行在阿里云企業級別安全環境里。 多用戶運行是服務器級別隔離機制。 提供多種服務授權和子主賬號。	需要另外購買清洗和黑洞設備 需要單獨實現安全訪問機制。

函數計算雖然適用于很多場景，但也不是覆蓋全部應用場景的萬金油。例如某些業務在一天中沒有明顯的請求波峰波谷，請求相對平緩，那么使用函數計算成本不見得會節省多少。

Serverless框架作為新興的技術，目前相應的支持開發工具較少，整體框架還在探索中。另外，函數計算的執行環境是不記錄狀態的，有些耦合性較強的應用也不太適合用Serverless這種框架。受限于資源大小分配，一些大型的應用程序也不太容易能拆分搬上來。

?

總結

以上是生活随笔為你收集整理的Serverless应用场景的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。