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

 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 為網站監控告警示例，

                                                                               1-8 網站監控告警示例

來 源 | 阿里云Serverless團隊

本文來自博客園，作者：古道輕風，轉載請注明原文鏈接：https://www.cnblogs.com/88223100/p/Detailed-explanation-of-6-major-application-scenarios-of-Serverless-architecture.html

標籤：其他

上一篇：設計模式之（7）——裝飾設計模式

下一篇：設計模式之（6）——建造者模式