都 2021 年了，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 等服務時，必定要爲每一個面向公衆的終端設置單獨的併發限制和節流策略。這類服務通常在雲平臺中會爲整個區域設置全局併發配額。若是你沒有基於端點的限制，***者只須要將一個單一的端點做爲***目標，就能夠耗盡你的配額，並讓你在該區域的整個系統癱瘓。

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