來(lái)源|Serverless
責(zé)編|晉兆雨
頭圖|付費(fèi)下載于視覺(jué)中國(guó)
“Serverless能取代微服務(wù)嗎？”這是知乎上Serverless分類(lèi)的高熱話題。
有人說(shuō)微服務(wù)與Serverless是相背離的，雖然我們可以基于Serverless后端來(lái)構(gòu)建微服務(wù)，但在微服務(wù)和Serverless之間并不存在直接的路徑。
也有人說(shuō)，因?yàn)镾erverless內(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ì)
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è)分析和任何類(lèi)型的機(jī)器學(xué)習(xí)，你可能選擇Python作為編程語(yǔ)言；像SageMaker這樣的專(zhuān)用平臺(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ì)
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)有專(zhuān)業(yè)的平臺(tái)可以解決所有這些問(wèn)題。那么，專(zhuān)業(yè)的開(kāi)發(fā)團(tuán)隊(duì)是否要引入這些專(zhuān)業(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è)采用這種類(lèi)型架構(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í)踐
1.Serverless中微服務(wù)應(yīng)該多大？
人們?cè)诶斫釹erverless時(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è)需要類(lèi)似資源、上下文關(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é)流策略。這類(lèi)服務(wù)一般在云平臺(tái)中會(huì)為整個(gè)區(qū)域設(shè)置全局并發(fā)配額。如果你沒(méi)有基于端點(diǎn)的限制，攻擊者只需要將一個(gè)單一的端點(diǎn)作為攻擊目標(biāo)，就可以耗盡你的配額，并讓你在該區(qū)域的整個(gè)系統(tǒng)癱瘓。
