編譯| OrangeJ

作者| Mariliis Retter

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

有人說(shuō)微服務(wù)與 Serverless 是相背離的，雖然我們可以基于 Serverless 后端來(lái)構(gòu)建微服務(wù)，但在微服務(wù)和 Serverless 之間并不存在直接的路徑。

也有人說(shuō)，因?yàn)?Serverless 內(nèi)含的 Function 可以視為更小的、原子化的服務(wù)，天然地契合微服務(wù)的一些理念，所以 Serverless 與微服務(wù)是天作之合。

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

微服務(wù)在 Serverless 中的優(yōu)勢(shì)

Serverless

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

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

2.細(xì)粒度的資源分配

因?yàn)榭蓴U(kuò)展性和并發(fā)性可以自主選擇，用戶可以細(xì)粒度控制資源分配的優(yōu)先級(jí)。在 Lambda functions 中，每個(gè)微服務(wù)都可以根據(jù)其需求，擁有不同級(jí)別的內(nèi)存分配。比如，面向客戶的服務(wù)可以擁有更高的內(nèi)存分配，因?yàn)檫@將有助于加快執(zhí)行時(shí)間；而對(duì)于延遲不敏感的內(nèi)部服務(wù)，就可以用優(yōu)化的內(nèi)存設(shè)置來(lái)進(jìn)行部署。

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

3.松耦合

這是微服務(wù)的一般屬性，并不是 Serverless 的獨(dú)有屬性，這個(gè)特性讓系統(tǒng)中不同功能的組件更容易解耦。

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

Serverless 功能的配置、部署和執(zhí)行的簡(jiǎn)易性，為基于多個(gè)運(yùn)行時(shí)的系統(tǒng)提供了可能性。

雖然 Node.js （JavaScript 運(yùn)行時(shí)）是后端 Web 應(yīng)用最流行的技術(shù)之一，但它不可能成為每一項(xiàng)任務(wù)的最佳工具。對(duì)于數(shù)據(jù)密集型任務(wù)、預(yù)測(cè)分析和任何類型的機(jī)器學(xué)習(xí)，你可能選擇 Python 作為編程語(yǔ)言；像 SageMaker 這樣的專用平臺(tái)更適合大項(xiàng)目。

有了 Serverless 基礎(chǔ)架構(gòu)，你無(wú)需在操作方面花費(fèi)額外的精力就可以直接為常規(guī)后端 API 選擇 Node.js，為數(shù)據(jù)密集型工作選擇 Python。顯然，這可能會(huì)給你的團(tuán)隊(duì)帶來(lái)代碼維護(hù)和團(tuán)隊(duì)管理的額外工作。

5.開(kāi)發(fā)團(tuán)隊(duì)的獨(dú)立性

不同的開(kāi)發(fā)者或團(tuán)隊(duì)可以在各自的微服務(wù)上工作、修復(fù) bug、擴(kuò)展功能等，做到互不干擾。比如 AWS SAM、Serverless 框架等工具讓開(kāi)發(fā)者在操作層面更加獨(dú)立。而 AWS CDK 構(gòu)架的出現(xiàn)，可以在不損害高質(zhì)量和運(yùn)維標(biāo)準(zhǔn)的前提下，讓開(kāi)發(fā)團(tuán)隊(duì)擁有更高的獨(dú)立性。

微服務(wù)在 Serverless 中的劣勢(shì)

Serverless

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

在 Serverless 帶來(lái)的眾多挑戰(zhàn)中，監(jiān)控和調(diào)試可能是最有難度的。因?yàn)橛?jì)算和存儲(chǔ)系統(tǒng)分散在許多不同的功能和數(shù)據(jù)庫(kù)中，更不用說(shuō)隊(duì)列、緩存等其他服務(wù)了，這些問(wèn)題都是由微服務(wù)本身引起的。不過(guò)，目前已經(jīng)有專業(yè)的平臺(tái)可以解決所有這些問(wèn)題。那么，專業(yè)的開(kāi)發(fā)團(tuán)隊(duì)是否要引入這些專業(yè)平臺(tái)也應(yīng)該基于成本進(jìn)行考量。

2.可能經(jīng)歷更多冷啟動(dòng)

當(dāng) FaaS 平臺(tái)（如 Lambda）需要啟動(dòng)一個(gè)新的虛擬機(jī)來(lái)運(yùn)行函數(shù)代碼時(shí)，就會(huì)發(fā)生冷啟動(dòng)。如果你的函數(shù) Workload 對(duì)延遲敏感，就很可能會(huì)遇到問(wèn)題。因?yàn)槔鋯?dòng)會(huì)在總啟動(dòng)時(shí)間中增加幾百毫秒到幾秒的時(shí)間，當(dāng)一個(gè)請(qǐng)求完成后，F(xiàn)aaS 平臺(tái)通常會(huì)讓 microVM 空閑一段時(shí)間，等待下一個(gè)請(qǐng)求，然后在 10-60 分鐘后關(guān)閉（是的，變化很大）。結(jié)果是：你的功能執(zhí)行的越頻繁，microVM 就越有可能為傳入的請(qǐng)求而啟動(dòng)并運(yùn)行（避免冷啟動(dòng)）。

當(dāng)我們將應(yīng)用分散在數(shù)百個(gè)或數(shù)千個(gè)微服務(wù)中時(shí)，我們可能在每個(gè)服務(wù)中分散調(diào)用時(shí)間，導(dǎo)致每個(gè)函數(shù)的調(diào)用頻率降低。注意 “可能會(huì)分散調(diào)用”。根據(jù)業(yè)務(wù)邏輯和你的系統(tǒng)行為方式，這種負(fù)面影響可能很小，或者可以忽略不計(jì)。

3.其他缺點(diǎn)

微服務(wù)概念本身還存在其他固有的缺點(diǎn)。這些并不是與 Serverless 有內(nèi)在聯(lián)系的。盡管如此，每一個(gè)采用這種類型架構(gòu)的團(tuán)隊(duì)都應(yīng)該謹(jǐn)慎，以降低其潛在的風(fēng)險(xiǎn)和成本。

• 確定服務(wù)邊界并非易事，可能會(huì)招致架構(gòu)問(wèn)題。

• 更廣泛的攻擊面

• 服務(wù)編排費(fèi)用問(wèn)題

• 同步計(jì)算和存儲(chǔ)（在需要的時(shí)候）是不容易做到高性能和可擴(kuò)展

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

Serverless

1.Serverless 中微服務(wù)應(yīng)該多大？

人們?cè)诶斫?Serverless 時(shí)，"Function as a Services（FaaS） " 的概念很容易與編程語(yǔ)言中的函數(shù)語(yǔ)句相混淆。目前，我們正在處在一個(gè)沒(méi)有辦法劃出完美界限的時(shí)期，但經(jīng)驗(yàn)表明，使用非常小的 Serverless 函數(shù)并不是一個(gè)好主意。

當(dāng)你決定將一個(gè)（微）服務(wù)分拆成獨(dú)立的功能時(shí)，你就將不得不面對(duì) Serverless 難題。因此，在此提醒，只要有可能，將相關(guān)的邏輯保持在一個(gè)函數(shù)中會(huì)好很多。

當(dāng)然，決策過(guò)程也應(yīng)該考慮擁有一個(gè)獨(dú)立的微服務(wù)的優(yōu)勢(shì)

你可以這樣設(shè)想：“如果我把這個(gè)微服務(wù)分拆出來(lái)......”

• 它能讓不同的團(tuán)隊(duì)獨(dú)立工作嗎？
• 能否從細(xì)粒度的資源分配或選擇性的擴(kuò)展能力中獲益？

如果不能，你應(yīng)該考慮將這個(gè)服務(wù)與另一個(gè)需要類似資源、上下文關(guān)聯(lián)并執(zhí)行相關(guān) Workload 的服務(wù)捆綁在一起。

2.松耦合的架構(gòu)

通過(guò)組成 Serverless 函數(shù)來(lái)協(xié)調(diào)微服務(wù)的方法有很多。

當(dāng)需要同步通信時(shí)，可以直接調(diào)用(即 AWS Lambda RequestResponse 調(diào)用方法)，但這會(huì)導(dǎo)致高度耦合的架構(gòu)。更好的選擇是使用 Lambda Layers 或 HTTP API，這樣可以讓以后的修改或遷移服務(wù)對(duì)客戶端不構(gòu)成影響。

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

3.跨組件隔離

理想情況下，微服務(wù)不應(yīng)向使用者暴露細(xì)節(jié)。像 Lambda 這樣的 Serverless 平臺(tái)會(huì)提供一個(gè) API 來(lái)隔離函數(shù)。但這本身就是一種實(shí)現(xiàn)細(xì)節(jié)的泄露，理想情況下，我們會(huì)在函數(shù)之上添加一個(gè)不可知的 HTTP API 層，使其真正隔離。

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

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

譯文鏈接：

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

有道無(wú)術(shù)，術(shù)可成；有術(shù)無(wú)道，止于術(shù)
歡迎大家關(guān)注Java之道公眾號(hào)

好文章，我在看??