要說目前軟件架構(gòu)中熱度十二分的話題,當(dāng)屬Serverless。
通常我們會(huì)將其翻譯為“無服務(wù)器架構(gòu)”。
盡管成天被稱為“無服務(wù)器”,但該架構(gòu)與傳統(tǒng)架構(gòu)不同,顯然并不是真的不需要服務(wù)器。
而是選擇將服務(wù)器等基礎(chǔ)設(shè)施的管理“隱藏”起來,計(jì)算資源作為服務(wù)而不是作為服務(wù)器的概念出現(xiàn)。
兼具事件觸發(fā)、短暫以及完全被第三方管理等多重屬性,其中開發(fā)者只需關(guān)注業(yè)務(wù)邏輯即可。
那一年,也就是2012,TA首次出現(xiàn)在技術(shù)人的視野之中。
就在嶄露頭角之后的短短兩年,號(hào)稱云計(jì)算“3A巨頭”之一的AWS,就于當(dāng)年年底正式推出了Lambda 產(chǎn)品,標(biāo)志著Serverless的商業(yè)化進(jìn)程隆重被開啟。
當(dāng)時(shí)的Lambda曾被大家如此描述:這是一種計(jì)算服務(wù),可以根據(jù)時(shí)間來運(yùn)行用戶的代碼,無需關(guān)心底層的計(jì)算資源。
從2012年到2014年,Lambda著實(shí)不算早到。
但就像云計(jì)算PaaS初出茅廬時(shí)的說法一樣:用戶只管業(yè)務(wù)就好,底層IaaS就交給我們吧!
Serverless與PaaS帶給人們的理念是如此驚人的相似。
隨后的兩年時(shí)間內(nèi),Google Cloud Function 和微軟 Azure Function 在技術(shù)圈子的成功,也就順理成章將 Serverless推進(jìn)了熱化階段。
從架構(gòu)變遷聚焦Serverless內(nèi)涵
對(duì)于眾多開發(fā)者而言,顯然僅僅知道“Serverless被定義為無服務(wù)器架構(gòu)”的概念完全不夠,如何將Serverless的理解更具象化一些?
恐怕還是要從軟件應(yīng)用架構(gòu)演進(jìn)的角度說起。
或許你可能了解,在十幾年前,單體應(yīng)用作為最主流的應(yīng)用架構(gòu)形式被廣泛認(rèn)可。
依靠一臺(tái)服務(wù)器外加一個(gè)數(shù)據(jù)庫,就能讓服務(wù)可用性達(dá)到峰值狀態(tài)。
但隨著服務(wù)器老化性能下降甚至自身損壞的情況,再加上企業(yè)業(yè)務(wù)量的逐漸擴(kuò)大,單體架構(gòu)再也不是“一招鮮吃遍天”。
哪怕在流量入口加入負(fù)載均衡器,讓單體應(yīng)用可以部署在多臺(tái)服務(wù)器上來增加彈性,也不能完全解決由代碼無物理邊界所帶來的大量沖突。
至此,單體應(yīng)用架構(gòu)第一次有機(jī)會(huì)進(jìn)化成微服務(wù)架構(gòu),而此時(shí)的架構(gòu)師們也就不得不直面分布式帶來的新挑戰(zhàn)。
例如那些年的緩存服務(wù) Redis、狀態(tài)協(xié)調(diào)服務(wù)ZooKeeper、消息服務(wù) Kafka等。
我們可以簡單理解為,將一個(gè)大系統(tǒng)劃分為多個(gè)業(yè)務(wù)模塊,其中的業(yè)務(wù)模塊又需要分別部署在不同的服務(wù)器上,各個(gè)業(yè)務(wù)模塊之間通過接口進(jìn)行數(shù)據(jù)交互,這件事兒似乎沒那么簡單。
當(dāng)然除了分布式環(huán)境的特殊性以外,微服務(wù)架構(gòu)也給運(yùn)維帶來了不小改變。
具體實(shí)踐中,由于微服務(wù)可以部署在不同的服務(wù)器上,也可以部署在相同的服務(wù)器卻不同的容器上,包括應(yīng)用分發(fā)標(biāo)準(zhǔn)、生命周期標(biāo)準(zhǔn)以及自動(dòng)化彈性等能力在內(nèi)的重要性也就一一凸顯出來。
轉(zhuǎn)眼到了眾所周知的云原生時(shí)代,業(yè)務(wù)直接上云不說,還能提供標(biāo)準(zhǔn)化的應(yīng)用托管服務(wù),包括版本管理、發(fā)布、上線后的觀測、自愈等,價(jià)值紅利得到進(jìn)一步彰顯。
而此時(shí)Serverless也正迎著這波技術(shù)紅利闖入了大眾的視線,得到關(guān)注。
可以看出,在架構(gòu)的演進(jìn)中,無論是研發(fā)還是運(yùn)維人員都逐漸將著眼點(diǎn)從機(jī)器向平臺(tái)系統(tǒng)轉(zhuǎn)移,而不是單純用人去管理,這或許是對(duì)于Serverless原理最樸素的闡釋。
總結(jié)一下,Serverless的出現(xiàn)其實(shí)是將主機(jī)管理、操作系統(tǒng)管理、資源分配等,甚至是應(yīng)用邏輯全部組件都集成為服務(wù)。
如果將其放在當(dāng)下的云計(jì)算場景中,就不能單純狹義理解為“不用關(guān)心服務(wù)器”那么簡單,畢竟上云的資源除了服務(wù)器之外,還涉及基礎(chǔ)計(jì)算、存儲(chǔ)資源、網(wǎng)絡(luò)資源等諸多,也包括數(shù)據(jù)庫、緩存以及消息隊(duì)列等更上層的范疇。
Serverless架構(gòu)類同F(xiàn)aaS,又做何解?
提及 Serverless,很多人的第一反應(yīng)都是 FaaS+BaaS。
的確,這是 Serverless的一種實(shí)現(xiàn)形式,也是一種比較主流的理解。
所謂“FaaS+BaaS ”,其實(shí)就是函數(shù)即服務(wù)與后端即服務(wù)的結(jié)合體。
具體來說,BaaS(Backend as a Service)可以被解釋為“后端即服務(wù)”。
一般是API調(diào)用后端或別人已經(jīng)實(shí)現(xiàn)好的程序邏輯,通常用來管理數(shù)據(jù)。
例如,亞馬遜RDS可以替代自己部署的MySQL,當(dāng)然其中還有各種其它數(shù)據(jù)庫、中間件的作用。
FaaS(Functions as a Service)則是函數(shù)即服務(wù),作為無服務(wù)器計(jì)算的一種形式,當(dāng)前使用最廣泛的當(dāng)屬AWS的Lambada。
經(jīng)過長期實(shí)踐我們認(rèn)為,Serverless架構(gòu)可以提供一種更加“代碼碎片化”的軟件架構(gòu)范式,而所謂的“函數(shù)”(Function),則是提供相比微服務(wù)更加細(xì)小的程序單元。
進(jìn)一步來說,究竟該如何理解“函數(shù)即服務(wù)”的概念?
大致上是開發(fā)者先將函數(shù)定義封裝在容器中,通過調(diào)用函數(shù)來實(shí)現(xiàn)調(diào)用后端存儲(chǔ)等服務(wù)。
本質(zhì)上,F(xiàn)aaS是一種事件驅(qū)動(dòng)的由消息觸發(fā)的服務(wù)。
與傳統(tǒng)的服務(wù)器端軟件的不同,經(jīng)應(yīng)用程序部署到擁有操作系統(tǒng)的虛擬機(jī)或者容器中,一般需要長時(shí)間駐留在操作系統(tǒng)中運(yùn)行。
而FaaS則可以直接將程序部署上到平臺(tái)上,當(dāng)有事件到來時(shí)觸發(fā)執(zhí)行,執(zhí)行完了就可以消滅。
更重要的一點(diǎn),F(xiàn)aaS產(chǎn)品不需要對(duì)特定框架或庫進(jìn)行編碼。
還是以AWS Lambda函數(shù)為例,函數(shù)可以在Javascript、Python、Go等,也就是任何JVM語言(Java,Clojure,Scala等)或.NET語言中實(shí)現(xiàn);但與此同時(shí),Lambda函數(shù)還可執(zhí)行與其部署工件捆綁在一起的另一個(gè)進(jìn)程。
在FaaS環(huán)境中,用戶將函數(shù)功能代碼上傳到FaaS提供商,其中對(duì)的水平擴(kuò)展是完全自動(dòng)彈性的。
而“函數(shù)”還可以代表客戶所要執(zhí)行的每個(gè)操作,即每個(gè)函數(shù)完成一個(gè)相對(duì)簡單的業(yè)務(wù)邏輯,一個(gè)完整的應(yīng)用由若干個(gè)函數(shù)組成,主要包括創(chuàng)建、讀取、更新以及刪除等。
目前,函數(shù)即服務(wù)(Function as a Service,F(xiàn)aaS)是當(dāng)下Serverless實(shí)現(xiàn)的技術(shù)基礎(chǔ)。
因?yàn)镕aaS和Serverless之間關(guān)系密切,所以FaaS的特點(diǎn)也可以被認(rèn)為是Serverless平臺(tái)的特點(diǎn),但如果單純認(rèn)為Serverless就是FaaS,就比較狹義了。
BaaS 時(shí)代僅僅以 API 的方式提供應(yīng)用依賴的后端服務(wù);而在 FaaS 時(shí)期,用戶與開發(fā)者不再關(guān)注底層,這么說Serverless繁榮也是合理有據(jù)的事兒。
使用Serverless,也是一把雙刃劍
據(jù)實(shí)際觀察,一直以來企業(yè)使用 Serverless 通常會(huì)涉及幾方面因素,其中“減少運(yùn)營成本”被認(rèn)為是最直觀有效的原因之一。
的確,應(yīng)用Serverless后,企業(yè)就無需再為潛在的流量高峰買進(jìn)大部分時(shí)間都可能空閑的服務(wù)器機(jī)架,而是根據(jù)流量進(jìn)行自動(dòng)伸縮,采用按請(qǐng)求量來付費(fèi)的靈活方式。
此外“自動(dòng)按需擴(kuò)展”可以發(fā)揮到極致:隨時(shí)擴(kuò)展到當(dāng)前的使用量,消除了意外或者季節(jié)性流量高峰的困擾。
更重要的是,Serverless 不需要關(guān)心內(nèi)存泄露,還具備將云數(shù)據(jù)庫、云消息隊(duì)列等服務(wù)囊括在內(nèi)的完善配套設(shè)施,極大減少工作量。
哪怕企業(yè)中大部分的開發(fā)人員都出身軟件,對(duì)修復(fù)保護(hù)以及管理并不擅長,一樣可以做到專注軟件開發(fā),Serverless絕對(duì)沒問題。
基于此,一直以來國內(nèi)外都有很多企業(yè)致力于提供基于Serverless 框架的能力服務(wù),接受程度更是水漲船高,簡單盤點(diǎn)下,尤其是幾家大型的公有云廠商。
例如里程碑式的AWS Lambda。
作為AWS針對(duì)Serverless架構(gòu)推出的FaaS云服務(wù),AWS Lambda自2014年上線以后就受到廣泛關(guān)注,除了滿足大家對(duì)Serverless的期望之外,更重要的是AWS平臺(tái)的成功。
AWS Lambda的優(yōu)勢可以簡單總結(jié)為:
成熟度高:第一個(gè)在主流公有云平臺(tái)上的Serverless FaaS平臺(tái),已經(jīng)有數(shù)年的發(fā)展和沉淀
用戶基數(shù)大:AWS Lambda有較大的用戶基數(shù),參考案例很多
活躍的社區(qū):目前開源社區(qū)有很多圍繞AWS Lambda展開的開源項(xiàng)目
AWS的整合:AWS Lambda天然和AWS平臺(tái)上的服務(wù)有良好集成
緊隨其后,Microsoft Azure也在2016年推出了事件驅(qū)動(dòng)的函數(shù)式云計(jì)算服務(wù)Azure Functions。
其支持用戶以多種語言進(jìn)行函數(shù)開發(fā),包括Java、Node.js、PHP、C#、F#、Bash及Microsoft Windows的PowerShell腳本等。
此外,Azure Functions除了提供公有云的版本之外,還提供私有化(On-premises)部署的版本Azure Functions Runtime。
產(chǎn)品功能也是可圈可點(diǎn):
完整性:Azure Functions是一個(gè)功能比較完備的Serverless FaaS平臺(tái)
整合:Azure Functions天然與Azure云平臺(tái)上各類服務(wù)有良好的集成
平臺(tái):對(duì)于使用微軟體系產(chǎn)品和工具構(gòu)建IT能力的企業(yè)而言,Azure Functions是Serverless轉(zhuǎn)型的首選平臺(tái)
私有化:提供帶有商業(yè)支持的私有化部署版本,可滿足不同層面的用戶的需求
同樣是在2016年,Google Cloud Platform推出了Google Cloud Functions平臺(tái),也同時(shí)加入Serverless領(lǐng)域的競爭序列。
同為FaaS平臺(tái),Google Cloud Functions與AWS Lambda和Microsoft Azure在功能上最大的區(qū)別有啥?
細(xì)數(shù)以后,可能在于Google Cloud Functions目前僅支持JavaScript作為函數(shù)開發(fā)語言,運(yùn)行環(huán)境為Node.js。
2018年7月,Google又順勢公布了開源項(xiàng)目Knative,定位為Kubernetes的Serverless插件,推出后得到了Pivotal、IBM以及Red Hat的大力支持。
國外爭先恐后,國內(nèi)也是蜂擁而至。阿里云作為國內(nèi)第一批推出Serverless平臺(tái)的公有云廠商,其FaaS平臺(tái)產(chǎn)品被稱為阿里云函數(shù)計(jì)算。
如果從事件觸發(fā)、支持語言以及用戶體驗(yàn)等方面考量,該產(chǎn)品也有很多數(shù)據(jù)值得關(guān)注:
事件觸發(fā):阿里云函數(shù)計(jì)算可以被阿里云上的服務(wù)事件觸發(fā),例如阿里云對(duì)象存儲(chǔ)(OSS)
支持語言:阿里云函數(shù)計(jì)算目前支持的開發(fā)語言為Node.js,并計(jì)劃后續(xù)將支持Java及Python
整個(gè)函數(shù)代碼的部署包大小不能超過50MB,部署包解壓后的代碼不能超過250MB
用戶體驗(yàn):阿里云函數(shù)計(jì)算提供了基于Web的控制臺(tái)和SDK;用戶可以通過Web控制臺(tái)管理函數(shù)應(yīng)用,也可以通過交互式的命令行來操作
服務(wù)規(guī)格:一個(gè)服務(wù)下最多包含50個(gè)函數(shù)和10個(gè)觸發(fā)器。在運(yùn)行時(shí),函數(shù)最長的運(yùn)行時(shí)間為300s,即5min,一個(gè)函數(shù)的最大并發(fā)數(shù)為100
同為國內(nèi)云計(jì)算競爭的翹楚,無服務(wù)器云函數(shù)(Serverless Cloud Function,SCF)是騰訊云推出的函數(shù)式計(jì)算平臺(tái),根據(jù)官方的資料,其發(fā)布時(shí)間是2017年4月26日。
總結(jié)下騰訊云Serverless平臺(tái)的特點(diǎn):
函數(shù)運(yùn)行時(shí):騰訊云SCF目前支持Python、Java及Node.js作為函數(shù)的開發(fā)語言
用戶可以以壓縮包的形式從本地上傳代碼,也可以引用騰訊云對(duì)象存儲(chǔ)中的代碼文件
事件觸發(fā):目前騰訊云SCF支持的事件觸發(fā)源有騰訊云對(duì)象存儲(chǔ)COS、定時(shí)器、騰訊云消息服務(wù)CMQ,以及用戶手動(dòng)通過API及控制臺(tái)觸發(fā)
服務(wù)規(guī)格:每個(gè)函數(shù)將在一個(gè)基于CentOS Linux的環(huán)境中被執(zhí)行。函數(shù)執(zhí)行的內(nèi)存范圍為128MB至1536MB,單個(gè)區(qū)域支持的最大函數(shù)定義數(shù)量為20個(gè),函數(shù)執(zhí)行的最大時(shí)長為300秒,最大的并發(fā)數(shù)為5
以上我們探討的基本是大型公有云服務(wù)商針對(duì)Serverless的技術(shù)實(shí)踐。
其實(shí)與公有云相比,在私有環(huán)境中構(gòu)建Serverless平臺(tái),在技術(shù)上并沒有什么太多障礙,自然也有不少領(lǐng)先的技術(shù)嘗試,對(duì)于此我們會(huì)專門成文詳細(xì)探討。
可以發(fā)現(xiàn),哪怕是擁有世界范圍影響力的公有云服務(wù)商針對(duì)Serverless的技術(shù)探究似乎也出現(xiàn)了缺乏統(tǒng)一認(rèn)知以及相應(yīng)標(biāo)準(zhǔn),無法適應(yīng)所有的云平臺(tái)的情況,例如支持的開發(fā)語言不同,事件觸發(fā)的機(jī)制有差異等。
畢竟Serverless從來都不是一款產(chǎn)品,也不是一個(gè)工具,而是一整套能力的合集。
甚至在實(shí)踐中還會(huì)出現(xiàn)業(yè)務(wù)輕量化困難、難以在秒級(jí)甚至毫秒級(jí)別擴(kuò)容出業(yè)務(wù)實(shí)例;基礎(chǔ)設(shè)施響應(yīng)能力不足導(dǎo)致服務(wù)發(fā)現(xiàn)和日志監(jiān)控系統(tǒng)等問題。
進(jìn)而帶來大量其他web服務(wù)器托管提供商可能會(huì)倒閉,很多SaaS平臺(tái)受到?jīng)_擊以及運(yùn)維和實(shí)施人員的生存空間進(jìn)一步縮小等行業(yè)現(xiàn)象。
但不容規(guī)避的一點(diǎn),Serverless 架構(gòu)的興起使“去服務(wù)器化”真正造福了開發(fā)者,讓基礎(chǔ)設(shè)施管理出現(xiàn)了新契機(jī)。
隨著技術(shù)上對(duì)去中心化以及輕量虛擬化的需求越發(fā)強(qiáng)烈,這種“全云化”的模式似乎預(yù)示著真正的云時(shí)代正在到來,不是嗎?
-
阿里云
+關(guān)注
關(guān)注
3文章
934瀏覽量
42932 -
AWS
+關(guān)注
關(guān)注
0文章
427瀏覽量
24290 -
serverless
+關(guān)注
關(guān)注
0文章
65瀏覽量
4490
發(fā)布評(píng)論請(qǐng)先 登錄
相關(guān)推薦
評(píng)論