導讀
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 架構的特點，從理論上描述了 Server less 架構适合的場景或業務。雲廠商則站在自身業務角度來描述 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 為網站監控告警示例。