簡介：?馬上就要 2021 年了，Serverless 是否終將取代微服務？從微服務到 Serverless 需要經過怎樣的路徑？本文將對 Serverless 與微服務在優勢劣勢上進行深度對比。

來源 |?Serverless 公眾號
編譯 | OrangeJ
作者 |?Mariliis Retter

“Serverless 能取代微服務嗎？” 這是知乎上 Serverless 分類的高熱話題。

有人說微服務與 Serverless 是相背離的，雖然我們可以基于 Serverless 后端來構建微服務，但在微服務和 Serverless 之間并不存在直接的路徑。也有人說，因為 Serverless 內含的 Function 可以視為更小的、原子化的服務，天然地契合微服務的一些理念，所以 Serverless 與微服務是天作之合。馬上就要 2021 年了，Serverless 是否終將取代微服務？從微服務到 Serverless 需要經過怎樣的路徑？本文將對 Serverless 與微服務在優勢劣勢上進行深度對比。

從概念上講，微服務完全符合 Serverless 功能結構，微服務可以輕松實現不同服務的部署和運行時隔離。在存儲方面，像 DynamoDB 這樣的服務可以讓每個微服務擁有獨立的數據庫，并獨立地進行擴展。在我們深入探討細節之前，先別急著“站隊”，不妨先基于你團隊的實際情況，真實的去思考是否適合使用微服務，千萬不要因為 "這是趨勢 "而去選擇它。

微服務在 Serverless 環境下的優勢
可選擇的可擴展性和并發性
Serverless 讓管理并發性和可擴展性變得容易。在微服務架構中，我們最大限度地利用了這一點。每一個微服務都可以根據自己的需求對并發性/可擴展性進行設置。從不同的角度來看這非常有價值：比如減輕 DDoS 攻擊可能性，降低云賬單失控的財務風險，更好地分配資源…等等。

細粒度的資源分配
因為可擴展性和并發性可以自主選擇，用戶可以細粒度控制資源分配的優先級。在 Lambda functions 中，每個微服務都可以根據其需求，擁有不同級別的內存分配。比如，面向客戶的服務可以擁有更高的內存分配，因為這將有助于加快執行時間；而對于延遲不敏感的內部服務，就可以用優化的內存設置來進行部署。

這一特性同樣適用于存儲機制。比如 DynamoDB 或 Aurora Serverless 數據庫就可以根據所服務的特定（微）服務的需求，擁有不同級別的容量分配。

松耦合
這是微服務的一般屬性，并不是 Serverless 的獨有屬性，這個特性讓系統中不同功能的組件更容易解耦。

支持多運行環境
Serverless 功能的配置、部署和執行的簡易性，為基于多個運行時的系統提供了可能性。

雖然 Node.js （JavaScript 運行時）是后端 Web 應用最流行的技術之一，但它不可能成為每一項任務的最佳工具。對于數據密集型任務、預測分析和任何類型的機器學習，你可能選擇 Python 作為編程語言；像 SageMaker 這樣的專用平臺更適合大項目。

有了 Serverless 基礎架構，你無需在操作方面花費額外的精力就可以直接為常規后端 API 選擇 Node.js，為數據密集型工作選擇 Python。顯然，這可能會給你的團隊帶來代碼維護和團隊管理的額外工作。

開發團隊的獨立性
不同的開發者或團隊可以在各自的微服務上工作、修復 bug、擴展功能等，做到互不干擾。比如 AWS SAM、Serverless 框架等工具讓開發者在操作層面更加獨立。而 AWS CDK 構架的出現，可以在不損害高質量和運維標準的前提下，讓開發團隊擁有更高的獨立性。

微服務在 Serverless 中的劣勢
難以監控和調試
在 Serverless 帶來的眾多挑戰中，監控和調試可能是最有難度的。因為計算和存儲系統分散在許多不同的功能和數據庫中，更不用說隊列、緩存等其他服務了，這些問題都是由微服務本身引起的。不過，目前已經有專業的平臺可以解決所有這些問題。那么，專業的開發團隊是否要引入這些專業平臺也應該基于成本進行考量。

可能經歷更多冷啟動
當 FaaS 平臺（如 Lambda）需要啟動一個新的虛擬機來運行函數代碼時，就會發生冷啟動。如果你的函數 Workload 對延遲敏感，就很可能會遇到問題。因為冷啟動會在總啟動時間中增加幾百毫秒到幾秒的時間，當一個請求完成后，FaaS 平臺通常會讓 microVM 空閑一段時間，等待下一個請求，然后在 10-60 分鐘后關閉（是的，變化很大）。結果是：你的功能執行的越頻繁，microVM 就越有可能為傳入的請求而啟動并運行（避免冷啟動）。

當我們將應用分散在數百個或數千個微服務中時，我們可能在每個服務中分散調用時間，導致每個函數的調用頻率降低。注意 “可能會分散調用”。根據業務邏輯和你的系統行為方式，這種負面影響可能很小，或者可以忽略不計。

其他缺點
微服務概念本身還存在其他固有的缺點。這些并不是與 Serverless 有內在聯系的。盡管如此，每一個采用這種類型架構的團隊都應該謹慎，以降低其潛在的風險和成本。

確定服務邊界并非易事，可能會招致架構問題。
更廣泛的攻擊面
服務編排費用問題
同步計算和存儲（在需要的時候）是不容易做到高性能和可擴展
微服務在 Serverless 中的挑戰和最佳實踐
Serverless 中微服務應該多大？
人們在理解 Serverless 時，"Function as a Services（FaaS） " 的概念很容易與編程語言中的函數語句相混淆。目前，我們正在處在一個沒有辦法劃出完美界限的時期，但經驗表明，使用非常小的 Serverless 函數并不是一個好主意。

當你決定將一個（微）服務分拆成獨立的功能時，你就將不得不面對 Serverless 難題。因此，在此提醒，只要有可能，將相關的邏輯保持在一個函數中會好很多。

當然，決策過程也應該考慮擁有一個獨立的微服務的優勢

你可以這樣設想："如果我把這個微服務分拆出來…

它能讓不同的團隊獨立工作嗎？
能否從細粒度的資源分配或選擇性的擴展能力中獲益？
如果不能，你應該考慮將這個服務與另一個需要類似資源、上下文關聯并執行相關 Workload 的服務捆綁在一起。

松耦合的架構
通過組成 Serverless 函數來協調微服務的方法有很多。

當需要同步通信時，可以直接調用(即 AWS Lambda RequestResponse 調用方法)，但這會導致高度耦合的架構。更好的選擇是使用 Lambda Layers 或 HTTP API，這樣可以讓以后的修改或遷移服務對客戶端不構成影響。

對于接受異步通信模型，我們有幾種選擇，如隊列（SQS）、主題通知（SNS）、Event Bridge 或者 DynamoDB Streams。

跨組件隔離
理想情況下，微服務不應向使用者暴露細節。像 Lambda 這樣的 Serverless 平臺會提供一個 API 來隔離函數。但這本身就是一種實現細節的泄露，理想情況下，我們會在函數之上添加一個不可知的 HTTP API 層，使其真正隔離。

使用并發限制和節流策略的重要性
為了減輕 DDoS 攻擊，在使用 AWS API Gateway 等服務時，一定要為每個面向公眾的終端設置單獨的并發限制和節流策略。這類服務一般在云平臺中會為整個區域設置全局并發配額。如果你沒有基于端點的限制，攻擊者只需要將一個單一的端點作為攻擊目標，就可以耗盡你的配額，并讓你在該區域的整個系統癱瘓。

原文鏈接
本文為阿里云原創內容，未經允許不得轉載。

總結

以上是生活随笔為你收集整理的都 2021 年了，Serverless 能取代微服务吗？的全部內容，希望文章能夠幫你解決所遇到的問題。

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