![頭圖.png](https://ucc.alicdn.com/pic/developer-ecology/197dbb5be58e4080a0aa35470db80a64.png)
來源 | [Serverless 公眾號](https://mp.weixin.qq.com/s/G7tE6o-02j37RRgAeWp9OQ)
編譯 | OrangeJ
作者 | [Mariliis Retter](https://dzone.com/users/4458058/mariliisretter.html)

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

![1.png](https://ucc.alicdn.com/pic/developer-ecology/ffabd88fa2784e6a95122b842390f7db.png)

有人說微服務與 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](https://dzone.com/articles/microservices-and-serverless-winning-strategies-an)

都 2021 年了，Serverless 能取代微服務嗎？

相關文章