作者 | 西流 阿里云技術專家

導讀：阿里云Serverless 產品函數計算可以作為粘合劑， 串聯其他云服務提供端到端解決方案， 從而簡化編程模型， 快速實現最上層的業務目標。

傳統單體應用的拆解

首先我們來看下單體應用里面常見的兩個編程模型，如上圖所示，一種是 UI-driven，另外一種是 Message-driven。單體應用這種體系結構，客戶端可能相對不那么智能，系統中的許多邏輯（比如身份驗證、頁面導航、搜索、交易等）由服務器應用程序實現，隨著業務邏輯復雜度的增長，服務端的應用程序會越發膨脹和難以維護。

而在 Message-driven 異步消息處理這種模式中，需要用戶實現一個常駐的、彈性高可用的消費者服務。為了更專注具體業務邏輯的開發，對一個龐大的單體應用進行拆解，充分利用云服務體系結構是一個非常好的解決方案。在這里，最大的關鍵是如何為應用程序的各個組件選擇和使用正確的云服務，而通過函數作為粘合劑來串聯云上的托管服務，就是一個非常好的實踐。

如上圖所示，UI-driven 切換到 Serverless 架構以后：

• 第三方 BaaS 服務取代認證邏輯；
• 允許客戶端通過臨時 token 直接訪問架構與第三方上的數據子庫（BaaS）；
• 寵物商店服務端的邏輯可以轉移到客戶端中，例如跟蹤用戶訪問，讀取數據庫轉化為可視視圖等，客戶端則慢慢轉化為單頁面應用；
• CPU 密集型或者需要訪問大量數據，比如搜索，使用 FaaS 實現，無需一直運行的 server；
• 購買功能使用另外一個 FaaS 實現，因為安全原因放在服務端。

Message-driven 切換到 Serverless 架構以后：

與單體應用示例相比，這里改動很小，同時使用 FaaS 功能替換了長期存在的消息消費者應用程序，消息消費的高可用性交給了云平臺去負責。

事件驅動與編排助力完整 Serverless 應用

目前，在很多的人的第一印象中，一般將 FaaS，也就是 Fucntion as a Service（函數即服務）等同于 Serverless， 比如阿里云的函數計算、AWS 的 Lambda，但是實際上有許多其他的云服務也是 Serverless，他們和 FC 一起構建成完整的 Serverless 應用，讓用戶完全聚焦他最上層和核心的原始業務。比如，用戶直接使用 API 網關， 就可以從 API 限流、鑒權等許多 API 層面上需要考慮的繁雜工作中解放出來；直接使用 Serverless 的 NoSQL 數據庫 TableStore 或者對象存儲 OSS 來持久化數據，替代自己管理數據庫實例；使用 SLS 或者 Datahub 從外部系統收集數據流；使用消息服務 MNS/MQ 來管理消息等。

用戶可以使用一個個函數將這些 Serverless 服務串聯起來，從而達到構建具體復雜的業務邏輯和應用的目標。在這里，用戶也可以選擇 Serverless 工作流來編排函數和其他云服務，簡化了開發和運行業務流程（比如自己去編寫代碼進行任務協調、狀態管理、錯誤處理以及重試等繁瑣工作），讓用戶聚焦業務邏輯開發。當然，用戶也可以使用阿里云提供的開發工具鏈來簡化自動化部署和持續集成。使用這些開箱即可使用的工具可以幫助用戶快速達到想要的目標和效果。

如果是一個龐大復雜的單體應用或者是一個面向服務體系的架構，開發者需要負責所有的事情，包括代碼的編寫、管理和部署數據庫以及其他相關的后端服務等，切換到 Servrless 架構， 可以看到：特定的的模塊交由特定的托管云服務去處理， 之后再使用實現了具體業務代碼的函數將它們串聯起來， 也實現了解耦。 為了使這種架構運轉的更有效率， 事件驅動是一個必不可少的特性， 比如用戶嘗試往 OSS 上傳一個文件或者更新表格存儲會自動做一些邏輯處理，對于開發者來說， 最關心的是什么樣的事件可以觸發我的編寫邏輯。

Serverless 粘合云服務示例

這里有一個有趣的例子：

如上圖所示，用戶上傳圖片文件，產生消息事件觸發了 FC 函數執行，處理生成了圖片縮略圖，并將縮略圖存儲至對象存儲 OSS，之后觸發了另一個 FC 函數將圖片產生的更新信息寫入表格存儲數據庫，最后再觸發一個 FC 函數完成搜索模塊的更新。整個過程中文件處理存儲、搜索服務、表格存儲數據庫服務被幾個 FC 函數粘合為一個業務處理邏輯。

參考文章：https://martinfowler.com/articles/serverless.html

《新程序員》：云原生和全面數字化實踐50位技術專家共同創作，文字、視頻、音頻交互閱讀

總結

以上是生活随笔為你收集整理的函数粘合云服务提供端到端解决方案的全部內容，希望文章能夠幫你解決所遇到的問題。

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