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 觸發器、日志觸發器等。

場景一：Web 應用或移動應用後端

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

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

場景二：實時文件/數據處理

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

1-3 實時文件處理示例

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

1-4 實時數據處理示例

場景三：離線數據處理

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

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

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

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

1-5 數據 ETL 處理示例

場景四：人工智能領域

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

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

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

場景五：物聯網（IoT）領域

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

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

圖1-7 IoT 後端處理示例

場景六：監控與自動化運維

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

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

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

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

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

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

1-8 網站監控告警示例

雲計算技術架構 Serverless 的 6 大應用場景丨科普

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!