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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

廣告

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