詳解 Serverless 架構的 6 大應用場景

Serverless 架構將成為未來雲計算領域重要的技術架構，將會被更多的業務所採納。進一步深究，Serverless 架構在什麼場景下有優秀的表現，在什麼場景下可能表現得並不是很理想呢？或者說，有哪些場景更適合 Serverless 架構呢？ ...

Serverless 架構將成為未來雲計算領域重要的技術架構，將會被更多的業務所採納。進一步深究，Serverless 架構在什麼場景下有優秀的表現，在什麼場景下可能表現得並不是很理想呢？或者說，有哪些場景更適合 Serverless 架構呢？

Serverless 架構的應用場景

Serverless 架構的應用場景通常是由其特性決定的，所支持的觸發器決定具體場景。如圖 1-1 所示，CNCF Serverless Whitepaper v1.0 描述的關於 Serverless 架構所適合的用戶場景如下。

非同步併發，組件可獨立部署和擴展的場景。
突發或服務使用量不可預測的場景。
短暫、無狀態的應用，對冷啟動時間不敏感的場景。
需要快速開發、迭代的業務。

1-1 CNCF Serverless Whitepaper v1.0 描述的 Serverless 架構所適合的用戶場景

CNCF 除基於 Serverless 架構的特性給出 4 個適用的用戶場景之外，還結合常見的觸發器提供了詳細的例子。

響應資料庫更改（插入、更新、觸發、刪除）的執行邏輯。
對物聯網感測器輸入消息（如 MQTT 消息）進行分析。
執行流處理（分析或修改動態數據）。
數據單次提取、轉換和存儲需要在短時間內進行大量處理（ETL）。
通過聊天機器人界面提供認知計算（非同步）。
調度短時間內執行的任務，例如 CRON 或批處理的調用。
機器學習和人工智慧模型。
持續集成管道，按需為構建作業提供資源。

CNCF Serverless Whitepaper v1.0 基於 Serverless 架構的特點，從理論上描述了 Serverless 架構適合的場景或業務。雲廠商則站在自身業務角度來描述 Serverless 架構的典型應用場景。

通常情況下，當對象存儲作為 Serverless 相關產品觸發器時，典型的應用場景包括視頻處理、數據 ETL 處理等；API 網關更多會為用戶賦能對外的訪問鏈接以及相關聯的功能等，當 API 網關作為 Serverless 相關產品的觸發器時，典型的應用場景就是後端服務，包括 App 後端服務、網站後端服務甚至微信小程式等相關產品的後端服務。

一些智能音箱也會開放相關介面，這個介面也可以通過 API 網關觸發雲函數，獲得相應的服務等；除了對象存儲觸發以及 API 網關觸發，常見的觸發器還有消息隊列觸發器、Kafka 觸發器、日誌觸發器等。

1. Web 應用或移動應用後端

如果 Serverless 架構和雲廠商所提供的其他雲產品結合，開發者能夠構建可彈性擴展的移動應用或 Web 應用程式，輕鬆創建豐富的無伺服器後端。而且這些程式在多個數據中心可用。圖 1-2 所示為 Web 應用後端處理示例。

1-2 Web 應用後端處理示例

2.實時文件/數據處理

在視頻應用、社交應用等場景下，用戶上傳的圖片、音視頻往往總量大、頻率高，對處理系統的實時性和併發能力都有較高要求。此時，對於用戶上傳的圖片，我們可以使用多個函數對其分別處理，包括圖片的壓縮、格式轉換等，以滿足不同場景下的需求。圖 1-3 所示為實時文件處理示例。

1-3 實時文件處理示例

我們可以通過 Serverless 架構所支持的豐富的事件源、事件觸發機制、代碼和簡單的配置對數據進行實時處理，例如：對對象存儲壓縮包進行解壓、對日誌或資料庫中的數據進行清洗、對 MNS 消息進行自定義消費等。圖 1-4 所示為實時數據處理示例。

1-4 實時數據處理示例

3.離線數據處理

通常，要對大數據進行處理，我們需要搭建 Hadoop 或者 Spark 等相關的大數據框架，同時要有一個處理數據的集群。但通過 Serverless 技術，我們只需要將獲得到的數據不斷存儲到對象存儲，並且通過對象存儲配置的相關觸發器觸發數據拆分函數進行相關數據或者任務的拆分，然後再調用相關處理函數，之後存儲到雲資料庫中。

例如：某證券公司每 12 小時統計一次該時段的交易情況並整理出該時段交易量 top5；每天處理一遍秒殺網站的交易流日誌獲取因售罄而產生的錯誤，以便準確分析商品熱度和趨勢等。函數計算近乎無限擴容的能力可以使用戶輕鬆地進行大容量數據的計算。

利用 Serverless 架構可以對源數據併發執行 mapper 和 reducer 函數，在短時間內完成工作。相比傳統的工作方式，使用 Serverless 架構更能避免資源的閑置，從而節省成本。

數據 ETC 處理流程可以簡化為圖 1-5。

1-5 數據 ETL 處理示例

4.人工智慧領域

在 AI 模型完成訓練，對外提供推理服務時，基於 Serverless 架構，將數據模型包裝在調用函數中，在實際用戶的請求到達時再運行代碼。

相對於傳統的推理預測，這樣做的好處是無論是函數模塊還是後端的 GPU 伺服器，以及對接的其他相關機器學習服務，都可以進行按量付費以及自動伸縮，從而在保證性能的同時確保服務的穩定。圖 1-6 為機器學習（AI 推理預測）處理示例。

1-6 機器學習（AI 推理預測）處理示例

5.物聯網（IoT）領域

目前，很多廠商都在推出自己的智能音箱產品—用戶對智能音箱說一句話，智能音箱通過互聯網將這句話傳遞給後端服務，然後得到反饋結果，再返給用戶。通過 Serverless 架構，廠商可以將 API 網關、雲函數以及資料庫產品結合起來，以替代傳統的伺服器或者虛擬機等。

Serverless 架構一方面可以確保資源能按量付費，即用戶只有在使用的時候，函數部分才會計費；另一方面當用戶量增加時，通過 Serverless 架構實現的智能音箱系統的後端也會進行彈性伸縮，保證用戶側的服務穩定，且對其中某個功能的維護相當於對單個函數的維護，並不會給主流程帶來額外風險，相對來說會更加安全、穩定等。圖 1-7 為 IoT 後端處理示例。

圖1-7 IoT 後端處理示例

6.監控與自動化運維

在實際生產中，我們經常需要做一些監控腳本來監控網站服務或者 API 服務是否健康，包括是否可用、響應速度等。傳統的方法是通過一些網站監控平臺（例如 DNSPod 監控、360 網站服務監控，以及阿裡雲監控等）進行監控和告警。

這些監控平臺的原理是用戶自己設置要監控的網站和預期的時間閾值，由監控平臺部署在各地區的伺服器定期發起請求，進而判斷網站或服務的可用性。當然，這些伺服器雖然說通用性很強，但實際上並不一定適合。

例如，現在需要監控某網站狀態碼和不同區域的延時，同時設置一個延時閾值，當網站狀態異常或者延時過大時，平臺通過郵件等進行通知和告警。目前，針對這樣一個定製化需求，大部分監控平臺很難直接實現，所以開發一個網站狀態監控工具就顯得尤為重要。

除此之外，在實際生產運維中，對所使用的雲服務進行監控和告警也非常有必要。例如：在使用 Hadoop、Spark 時要對節點的健康進行監控；在使用 Kubernetes 時要對 API Server、ETCD 等的指標進行監控；在使用 Kafka 時要對數據積壓量，以及 Topic、Consumer 等的指標進行監控。

對於這些服務的監控，我們往往不能通過簡單的 URL 以及某些狀態進行判斷。在傳統的運維中，我們通常會在額外的機器上設置一個定時任務，以對相關服務進行旁路監控。

Serverless 架構的一個很重要的應用場景就是運維、監控與告警，即通過與定時觸發器結合使用，實現對某些資源健康狀態的監控與感知。圖 1-8 為網站監控告警示例。