為什么無(wú)服務(wù)器革命停滯不前?

幾年來(lái)，一些人已經(jīng)預(yù)測(cè)無(wú)服務(wù)器計(jì)算將迎來(lái)一個(gè)新的計(jì)算時(shí)代，我們被告知該框架將解決許多可擴(kuò)展性問題, 實(shí)際情況并非如此。盡管許多人將無(wú)服務(wù)器技術(shù)視為一個(gè)新想法，但其根源可以追溯到2006年，而Zimki PaaS和Google App Engine都探索了無(wú)服務(wù)器框架。

在過去的幾年中，構(gòu)建有彈性的無(wú)服務(wù)器系統(tǒng)一直是系統(tǒng)管理員和SaaS公司關(guān)注的主要問題，因?yàn)?據(jù)稱)該體系結(jié)構(gòu)提供了優(yōu)于“傳統(tǒng)”服務(wù)器和客戶端模型的幾個(gè)關(guān)鍵優(yōu)勢(shì)：

無(wú)服務(wù)器模型不需要用戶維護(hù)自己的操作系統(tǒng)，甚至不需要構(gòu)建與特定操作系統(tǒng)兼容的應(yīng)用程序。相反，開發(fā)人員可以生成通用代碼，然后將其上傳到無(wú)服務(wù)器框架，并觀察其運(yùn)行。

無(wú)服務(wù)器框架上使用的資源通常是按分鐘付費(fèi)(甚至按秒付費(fèi))。這意味著客戶只需為他們實(shí)際運(yùn)行代碼的時(shí)間付費(fèi)。這與傳統(tǒng)的基于云的虛擬機(jī)形成了鮮明的對(duì)比。

可伸縮性也是一大吸引力?？梢詣?dòng)態(tài)分配無(wú)服務(wù)器框架中的資源，這意味著它們能夠應(yīng)對(duì)突然的需求高峰。簡(jiǎn)而言之，這意味著無(wú)服務(wù)器模型應(yīng)該提供靈活、便宜、可擴(kuò)展的解決方案。

但是上述架構(gòu)一直存在下面四個(gè)主要缺陷:

1. 有限的編程語(yǔ)言 - 大多數(shù)無(wú)服務(wù)器平臺(tái)僅允許您運(yùn)行以特定語(yǔ)言編寫的應(yīng)用程序。這嚴(yán)重限制了這些系統(tǒng)的敏捷性和適應(yīng)性。

誠(chéng)然，大多數(shù)無(wú)服務(wù)器平臺(tái)都支持大多數(shù)主流語(yǔ)言。AWS Lambda和Azure Functions還提供了包裝器功能，使您可以使用不受支持的語(yǔ)言運(yùn)行應(yīng)用程序和功能，盡管這通常會(huì)帶來(lái)性能成本。因此，對(duì)于大多數(shù)組織而言，在大多數(shù)情況下，此限制不會(huì)帶來(lái)太大變化。這破壞了無(wú)服務(wù)器模型的關(guān)鍵優(yōu)勢(shì)之一。

2. 供應(yīng)商鎖定 - 無(wú)服務(wù)器平臺(tái)(或至少目前實(shí)現(xiàn)方式)的第二個(gè)問題是，在操作級(jí)別上很少有平臺(tái)彼此相似。在編寫，部署和管理功能的方式上，幾乎沒有跨平臺(tái)的標(biāo)準(zhǔn)化，這意味著將功能從一個(gè)特定于供應(yīng)商的平臺(tái)遷移到另一個(gè)平臺(tái)非常耗時(shí)。

遷移到無(wú)服務(wù)器最困難的部分不是計(jì)算功能(通常只是代碼片段)，而是應(yīng)用程序與對(duì)象存儲(chǔ)，身份管理和隊(duì)列之類的已連接系統(tǒng)糾纏在一起的方式。功能可以移動(dòng)，但是應(yīng)用程序的其余部分不那么可移植。這與我們所承諾的廉價(jià)，敏捷的平臺(tái)相反。

我懷疑有些人會(huì)爭(zhēng)辯說，無(wú)服務(wù)器模型是新的，并且還沒有時(shí)間標(biāo)準(zhǔn)化它們的工作方式。但是，正如我上面指出的那樣，它們并不是那么新，而且通過開發(fā)和廣泛采用基于社區(qū)的強(qiáng)大標(biāo)準(zhǔn)，容器等許多其他云原生技術(shù)已經(jīng)變得更加可用 。

3. 性能難以衡量 - 無(wú)服務(wù)器平臺(tái)的計(jì)算性能可能難以衡量，部分原因是出售這些服務(wù)的公司對(duì)隱藏此信息有既得利益。大多數(shù)人會(huì)聲稱，在無(wú)服務(wù)器的遠(yuǎn)程平臺(tái)上運(yùn)行的功能將與內(nèi)部服務(wù)器上的運(yùn)行速度一樣快，除非出現(xiàn)一些不可避免的延遲問題。

然而，軼事證據(jù)卻相反。之前未在特定平臺(tái)上運(yùn)行過的功能，或者未在一段時(shí)間內(nèi)運(yùn)行過的功能需要一些時(shí)間來(lái)初始化。這可能是因?yàn)樗麄兊拇a已經(jīng)轉(zhuǎn)移到了一些訪問性更差的存儲(chǔ)介質(zhì)上，盡管就像它們的性能統(tǒng)計(jì)一樣，大多數(shù)無(wú)服務(wù)器計(jì)算供應(yīng)商在這種情況下也不會(huì)泄漏。

當(dāng)然，有許多方法可以解決此問題。一種方法是針對(duì)無(wú)服務(wù)器平臺(tái)所運(yùn)行的任何一種云本機(jī)語(yǔ)言優(yōu)化功能，但這在一定程度上破壞了這些平臺(tái)“敏捷”的說法。

另一種方法是確保對(duì)性能至關(guān)重要的程序安排為頻繁運(yùn)行，以使它們保持“新鮮”。當(dāng)然，第二種方法與無(wú)服務(wù)器平臺(tái)更具成本效益的說法有些矛盾，因?yàn)槟粸槌绦蜻\(yùn)行時(shí)間付費(fèi)。云提供商已經(jīng)引入了減少冷啟動(dòng)的新方法，但是許多提供商都需要一種“縮放到一個(gè)”的模型，這會(huì)破壞FaaS的初始價(jià)值。

可以通過在內(nèi)部運(yùn)行無(wú)服務(wù)器系統(tǒng)來(lái)減少這種“冷啟動(dòng)”問題，但這本身就產(chǎn)生了成本，對(duì)于資源豐富的團(tuán)隊(duì)而言，這仍然是一個(gè)利基選擇。

4. 無(wú)法運(yùn)行整個(gè)應(yīng)用程序 - 最后，也許最關(guān)鍵的原因就是為什么無(wú)服務(wù)器架構(gòu)不會(huì)在短期內(nèi)取代傳統(tǒng)模型：(通常)您無(wú)法在serverless系統(tǒng)上運(yùn)行整個(gè)應(yīng)用程序。

或更確切地說，您可以，但是這樣做并不劃算。成功的整體應(yīng)用程序可能不應(yīng)成為連接到八個(gè)網(wǎng)關(guān)，四十個(gè)隊(duì)列和一打數(shù)據(jù)庫(kù)實(shí)例的四打功能的系列。因此，無(wú)服務(wù)器適合于未開發(fā)的領(lǐng)域。幾乎沒有現(xiàn)有的應(yīng)用程序(體系結(jié)構(gòu))移植過來(lái)。因此，您可以遷移，但期望從零開始。

這意味著，在大多數(shù)情況下，無(wú)服務(wù)器平臺(tái)將用作內(nèi)部服務(wù)器的附件，以執(zhí)行需要大量計(jì)算資源的任務(wù)。這使得它們與云原生技術(shù)的其他兩種形式(容器和虛擬機(jī))確實(shí)有很大不同，兩者都提供了執(zhí)行遠(yuǎn)程計(jì)算的整體方法。這說明了從微服務(wù)過渡到無(wú)服務(wù)器的困難之一 。

當(dāng)然，這不一定是問題。在許多組織中，偶爾使用大量計(jì)算資源而無(wú)需支付內(nèi)部實(shí)現(xiàn)此功能所需的硬件的能力可能會(huì)帶來(lái)真正而持久的好處。但是，管理應(yīng)用程序的運(yùn)行方式(其中部分運(yùn)行在內(nèi)部服務(wù)器上，其他部分運(yùn)行在無(wú)服務(wù)器云架構(gòu)上)可能會(huì)給這些應(yīng)用程序的部署帶來(lái)更高的復(fù)雜性。

網(wǎng)頁(yè)標(biāo)題：為什么無(wú)服務(wù)器革命停滯不前?
文章路徑：http://www.bm7419.com/news19/201319.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供建站公司、網(wǎng)站策劃、網(wǎng)站導(dǎo)航、靜態(tài)網(wǎng)站、用戶體驗(yàn)、定制開發(fā)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)