來源 | 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 等服務時，一定要為每個面向公眾的終端設置單獨的併發限制和節流策略。這類服務一般在雲平臺中會為整個區域設置全局併發配額。如果你沒有基於端點的限制，攻擊者只需要將一個單一的端點作為攻擊目標，就可以耗盡你的配額，並讓你在該區域的整個系統癱瘓。

翻譯：OrangeJ
原文鏈接：https://dzone.com/articles/microservices-and-serverless-winning-strategies-an