編譯| OrangeJ

作者| Mariliis Retter

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

有人說微服務與 Serverless 是相背離的，雖然我們可以基于 Serverless 后端來構建微服務，但在微服務和 Serverless 之間并不存在直接的路徑。

也有人說，因為 Serverless 內含的 Function 可以視為更小的、原子化的服務，天然地契合微服務的一些理念，所以 Serverless 與微服務是天作之合。

馬上就要 2021 年了，Serverless 是否終將取代微服務？從微服務到 Serverless 需要經過怎樣的路徑？在我們深入探討細節(jié)之前，先別急著“站隊”，不妨先基于你團隊的實際情況，真實的去思考是否適合使用微服務，千萬不要因為 "這是趨勢 "而去做選擇。

微服務在 Serverless 中的優(yōu)勢

Serverless

1.可選擇的可擴展性和并發(fā)性

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

2.細粒度的資源分配

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

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

3.松耦合

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

4.支持多運行環(huán)境

Serverless 功能的配置、部署和執(zhí)行的簡易性，為基于多個運行時的系統提供了可能性。

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

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

5.開發(fā)團隊的獨立性

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

微服務在 Serverless 中的劣勢

Serverless

1.難以監(jiān)控和調試

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

2.可能經歷更多冷啟動

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

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

3.其他缺點

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

• 確定服務邊界并非易事，可能會招致架構問題。

• 更廣泛的攻擊面

• 服務編排費用問題

• 同步計算和存儲（在需要的時候）是不容易做到高性能和可擴展

微服務在 Serverless 中的挑戰(zhàn)和實踐

Serverless

1.Serverless 中微服務應該多大？

人們在理解 Serverless 時，"Function as a Services（FaaS） " 的概念很容易與編程語言中的函數語句相混淆。目前，我們正在處在一個沒有辦法劃出完美界限的時期，但經驗表明，使用非常小的 Serverless 函數并不是一個好主意。

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

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

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

• 它能讓不同的團隊獨立工作嗎？

• 能否從細粒度的資源分配或選擇性的擴展能力中獲益？

如果不能，你應該考慮將這個服務與另一個需要類似資源、上下文關聯并執(zhí)行相關 Workload 的服務捆綁在一起。

2.松耦合的架構

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

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

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

3.跨組件隔離

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

4.使用并發(fā)限制和節(jié)流策略的重要性

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

譯文鏈接：

https://dzone.com/articles/microservices-and-serverless-winning-strategies-an

有道無術，術可成；有術無道，止于術歡迎大家關注Java之道公眾號 好文章，我在看??

總結

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

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