雖然許多人認(rèn)為，無(wú)服務(wù)器技術(shù)是一個(gè)新的概念。但是，如果追根溯源，那就是 2006 年 Zimki PaaS 和 Google App Engine 對(duì)無(wú)服務(wù)器框架的探索。
近幾年，一些人預(yù)測(cè)無(wú)服務(wù)器計(jì)算將迎來(lái)蓬勃發(fā)展，讓?xiě)?yīng)用無(wú)需操作系統(tǒng)就能執(zhí)行。雖然有人說(shuō)這種框架將會(huì)解決在可擴(kuò)展性上存在的許多問(wèn)題，但事實(shí)并非如此。因?yàn)闊o(wú)服務(wù)器模型僅在特定場(chǎng)景下發(fā)揮效用，但在被更廣泛采用的道路上依然存在諸多問(wèn)題。
服務(wù)器已死，服務(wù)器永存！為無(wú)服務(wù)器革命搖旗吶喊的聲音正此起彼伏。如果快速回顧過(guò)去幾年內(nèi)的一些行業(yè)新聞，很容易得出結(jié)論說(shuō)傳統(tǒng)服務(wù)器模型已失效，而且在未來(lái)幾年內(nèi)無(wú)服務(wù)器架構(gòu)將統(tǒng)治一切。
但真正的業(yè)內(nèi)人士都知道，也正如我們?cè)凇盁o(wú)服務(wù)器計(jì)算現(xiàn)狀”中所指出的，事實(shí)并非如此。盡管有許多文章對(duì)無(wú)服務(wù)器革命的優(yōu)點(diǎn)侃侃而談，但這些優(yōu)點(diǎn)依然尚未落地。事實(shí)上，最近有研究表明這一革命可能處于停滯不前，數(shù)量驚人的受訪者表示對(duì)無(wú)服務(wù)器范例并不感興趣。
https://www.infoq.com/news/2020/06/oreilly-cloud-report/
必需承認(rèn)，無(wú)服務(wù)器模型的部分承諾已經(jīng)實(shí)現(xiàn)，但也只是一小部分而已。盡管在一些具有明確定義的特定場(chǎng)景中，無(wú)服務(wù)器模型確實(shí)體現(xiàn)了巨大的實(shí)用性，但此類(lèi)系統(tǒng)看上去缺乏敏捷性和靈活性，且阻礙了它們的廣泛采用。
對(duì)初次接觸無(wú)服務(wù)器概念的人而言，無(wú)服務(wù)器計(jì)算指應(yīng)用或應(yīng)用的某一部分在通常是遠(yuǎn)程托管的執(zhí)行環(huán)境中按需運(yùn)行的架構(gòu)。換句話說(shuō)，無(wú)服務(wù)器系統(tǒng)也可以內(nèi)部托管。過(guò)去幾年，構(gòu)建有彈性的無(wú)服務(wù)器系統(tǒng)一直是系統(tǒng)管理員和 SaaS 公司的主要關(guān)注點(diǎn)。據(jù)稱該架構(gòu)提供了如下關(guān)鍵優(yōu)勢(shì)，所以優(yōu)于“傳統(tǒng)”的服務(wù)器和客戶端模型：
無(wú)服務(wù)器模型無(wú)需用戶自身去維護(hù)操作系統(tǒng)，甚至無(wú)需去構(gòu)建兼容特定操作系統(tǒng)的應(yīng)用。相反，開(kāi)發(fā)人員可以生成通用的代碼，上傳到無(wú)服務(wù)器框架，看著它運(yùn)行就好了。
在無(wú)服務(wù)器框架上使用資源通常是按分鐘計(jì)費(fèi)，甚至可按秒計(jì)費(fèi)，這意味著客戶只需為他們代碼的實(shí)際運(yùn)行時(shí)間付費(fèi)。這與傳統(tǒng)的基于云的虛擬機(jī)形成了鮮明對(duì)比。在傳統(tǒng)的基于云的虛擬機(jī)上，用戶最終會(huì)為一臺(tái)大量時(shí)間閑置的計(jì)算機(jī)付費(fèi)。
可擴(kuò)展性也是一大優(yōu)勢(shì)。無(wú)服務(wù)器框架中的資源支持動(dòng)態(tài)分片，這意味著能應(yīng)對(duì)突發(fā)的需求峰值。
簡(jiǎn)而言之，上述優(yōu)勢(shì)表明無(wú)服務(wù)器模型應(yīng)該能提供靈活、便宜、可擴(kuò)展的解決方案。考慮及此，人們難免會(huì)對(duì)如此好的新理念相見(jiàn)恨晚。
事實(shí)上，它早已存在。用戶只需為代碼實(shí)際運(yùn)行時(shí)間付費(fèi)的理念，早在 2006 年就作為 Zimki PaaS 的一部分提供，Google App Engine 大體在同一時(shí)間也給出了非常相似的解決方案。
事實(shí)上，現(xiàn)在所說(shuō)的“無(wú)服務(wù)器”模型要比當(dāng)前許多稱為“云原生”的技術(shù)歷史更加悠久，并且可以實(shí)現(xiàn)相同的目的。正如有人指出，無(wú)服務(wù)器模型本質(zhì)上只是已存在數(shù)十年的 SaaS 業(yè)務(wù)模型的擴(kuò)展。
需要注意的是，無(wú)服務(wù)器模型并非“函數(shù)”即服務(wù)（FaaS）架構(gòu)，盡管二者之間存在一定關(guān)聯(lián)。FaaS 本質(zhì)上是無(wú)服務(wù)器架構(gòu)中側(cè)重于計(jì)算的部分，因此是無(wú)服務(wù)器的一個(gè)組成部分，代表不了整個(gè)系統(tǒng)。
那么，為什么無(wú)服務(wù)器在現(xiàn)在受到熱捧？
這主要是因?yàn)殡S著互聯(lián)網(wǎng)滲透到發(fā)展中國(guó)家的速度持續(xù)提高，對(duì)計(jì)算資源的需求也隨之水漲船高。例如，許多電子商務(wù)行業(yè)發(fā)展迅速的國(guó)家，根本不具備處理運(yùn)行這些平臺(tái)應(yīng)用的計(jì)算基礎(chǔ)架構(gòu)。這就產(chǎn)生了租用無(wú)服務(wù)器平臺(tái)的需求。
問(wèn)題在于，無(wú)服務(wù)器模型本身就有問(wèn)題。不要誤會(huì)，我并不是說(shuō)無(wú)服務(wù)器模型本身是不好的，或是在某些情況下無(wú)法為某些公司提供可觀的價(jià)值。
但是，無(wú)服務(wù)器將迅速取代傳統(tǒng)架構(gòu)這一“革命”的核心主張是永遠(yuǎn)不會(huì)發(fā)生的。
大多數(shù)無(wú)服務(wù)器平臺(tái)僅支持運(yùn)行特定語(yǔ)言編寫(xiě)的應(yīng)用。這嚴(yán)重地限制了系統(tǒng)的敏捷性和適應(yīng)性。
誠(chéng)然，大多數(shù)的無(wú)服務(wù)器平臺(tái)都提供了對(duì)大部分主流編程語(yǔ)言的支持。AWS Lambda 和 Azure Functions 還提供包裝器功能，能使用未受系統(tǒng)支持的語(yǔ)言運(yùn)行應(yīng)用和“函數(shù)”，雖然通常會(huì)在性能上付出代價(jià)。因此，對(duì)于大多數(shù)機(jī)構(gòu)而言，語(yǔ)言上的限制在大多數(shù)情況下并沒(méi)有什么影響。但是，這就是問(wèn)題所在。無(wú)服務(wù)器模型的一個(gè)優(yōu)勢(shì)就是支持以更便捷的方式運(yùn)行那些非主流、不常使用的程序，只需為程序的執(zhí)行時(shí)間付費(fèi)。而這些非主流、不常使用的程序，常常使用一些并不常用、晦澀難懂的編程語(yǔ)言編寫(xiě)。
這導(dǎo)致無(wú)服務(wù)器模型的一個(gè)主要優(yōu)勢(shì)無(wú)法發(fā)揮。
無(wú)服務(wù)器平臺(tái)（或至少以目前的實(shí)現(xiàn)方式看）的第二個(gè)問(wèn)題是，在運(yùn)維層面上，很少存在彼此相似的平臺(tái)。在“函數(shù)”的編寫(xiě)、部署和管理方式上，幾乎不存在跨平臺(tái)的標(biāo)準(zhǔn)。這意味著將“函數(shù)”從一個(gè)特定于供應(yīng)商的平臺(tái)遷移到另一個(gè)平臺(tái)是非常耗時(shí)的。
遷移到無(wú)服務(wù)器的最大難處，并非那些通常只是一些代碼片段的計(jì)算“函數(shù)”（譯者注：在譯文中統(tǒng)一使用“函數(shù)”表示”Function“，指相比微服務(wù)更加細(xì)小的程序單元），而是應(yīng)用中與關(guān)聯(lián)系統(tǒng)糾纏不清的對(duì)象存儲(chǔ)、身份管理和隊(duì)列等方式。應(yīng)用中的“函數(shù)“是可以遷移的，但應(yīng)用的其余部分卻不那么容易移植。這與無(wú)服務(wù)器所承諾的廉價(jià)、敏捷的平臺(tái)是完全背道而馳的。
難免有些人會(huì)爭(zhēng)辯說(shuō)，無(wú)服務(wù)器模型是新的理念，還沒(méi)有時(shí)間去標(biāo)準(zhǔn)化它們的工作方式。但正如我在上文中指出的，無(wú)服務(wù)器并非什么新理念。而且，容器等其他許多云原生技術(shù)已經(jīng)通過(guò)開(kāi)發(fā)和廣泛采用基于社區(qū)的強(qiáng)大標(biāo)準(zhǔn)變得更具可用性。
無(wú)服務(wù)器平臺(tái)的計(jì)算性能難以衡量，部分原因在于提供此類(lèi)服務(wù)的公司出于一些既得利益會(huì)隱藏該信息。大多數(shù)服務(wù)提供商宣稱，如果無(wú)法避免的延遲問(wèn)題不存在，那么在遠(yuǎn)程無(wú)服務(wù)器平臺(tái)上運(yùn)行”函數(shù)“可達(dá)到與內(nèi)部服務(wù)器上相同的運(yùn)行速度。
但一些事實(shí)證據(jù)卻給出了相反結(jié)論。如果某個(gè)”函數(shù)“之前未在特定平臺(tái)上運(yùn)行過(guò)，或是在一段時(shí)間內(nèi)未運(yùn)行，那么就需要耗費(fèi)一些時(shí)間做初始化?？赡苁且?yàn)檫@些代碼已經(jīng)被遷移到那些不常訪問(wèn)的存儲(chǔ)介質(zhì)中。和性能統(tǒng)計(jì)一樣，大多數(shù)無(wú)服務(wù)器計(jì)算廠商對(duì)此也不會(huì)公布具體情況。
當(dāng)然，該問(wèn)題有多種解決方法。一種方法是使用任何一種無(wú)服務(wù)器平臺(tái)所運(yùn)行的云原生語(yǔ)言對(duì)”函數(shù)“進(jìn)行優(yōu)化，但這在一定程度上破壞了平臺(tái)所宣稱的“敏捷性”。
另一種方法是確保調(diào)度頻繁運(yùn)行那些對(duì)性能要求高的程序，以保持它們的“新鮮度”。當(dāng)然，考慮到用戶會(huì)為程序的運(yùn)行時(shí)間付費(fèi)，這種方法與無(wú)服務(wù)器平臺(tái)更具成本效益的說(shuō)法產(chǎn)生了矛盾。云服務(wù)提供商引入了一些降低冷啟動(dòng)的新方法，但許多提供商都需要“縮為一體”的模型，這破壞了 FaaS 初衷。
內(nèi)部運(yùn)行的無(wú)服務(wù)器系統(tǒng)會(huì)降低“冷啟動(dòng)”問(wèn)題，但該做法本身就引入了額外成本，是僅適用于資源豐富團(tuán)隊(duì)的一個(gè)小眾選擇。
為何無(wú)服務(wù)器架構(gòu)不會(huì)很快取代傳統(tǒng)模型？最后也可能是最關(guān)鍵的一個(gè)原因在于，用戶通常無(wú)法在無(wú)服務(wù)器系統(tǒng)上運(yùn)行整個(gè)應(yīng)用。
或者更確切地說(shuō)，雖然可以，但是這種做法并不劃算。一個(gè)良好運(yùn)行的單體應(yīng)用或許不應(yīng)變成一個(gè)連接到八個(gè)網(wǎng)關(guān)、四十個(gè)隊(duì)列和數(shù)十個(gè)數(shù)據(jù)庫(kù)實(shí)例的一系列”函數(shù)“。因此，無(wú)服務(wù)器適用于那些尚未開(kāi)發(fā)的領(lǐng)域。幾乎沒(méi)有將現(xiàn)有應(yīng)用（架構(gòu)）移植過(guò)來(lái)的案例。因此，雖然可遷移，但最好是從零開(kāi)始。
這意味著在大多數(shù)情況下，無(wú)服務(wù)器平臺(tái)將用作內(nèi)部服務(wù)器的一個(gè)補(bǔ)充，去執(zhí)行需大量計(jì)算資源的任務(wù)。這使得無(wú)服務(wù)器與容器、虛擬機(jī)這兩種云原生技術(shù)存在很大差異，后兩者都支持整體執(zhí)行遠(yuǎn)程計(jì)算。這是從是從微服務(wù)過(guò)渡到無(wú)服務(wù)器的一個(gè)難點(diǎn)。
當(dāng)然，這也不一定是個(gè)問(wèn)題。在許多機(jī)構(gòu)中，偶爾會(huì)使用大量計(jì)算資源，也無(wú)需采購(gòu)在內(nèi)部實(shí)現(xiàn)功能所需的硬件。無(wú)服務(wù)器的確能真正和持久地發(fā)揮優(yōu)勢(shì)。但是，管理部分運(yùn)行在內(nèi)部服務(wù)器上、部分運(yùn)行在無(wú)服務(wù)器云架構(gòu)上的應(yīng)用運(yùn)行，會(huì)給應(yīng)用部署帶來(lái)另一個(gè)層面上的復(fù)雜性。
原本無(wú)服務(wù)器是一種大家希望的新技術(shù)，但是很少有人去談它的不利之處。
Bernard Brode 總結(jié)了上述無(wú)服務(wù)器所存在的問(wèn)題之后，馬上在 Hacker News 引來(lái)了好幾百條互動(dòng)，其中有很多人表示對(duì)當(dāng)前的無(wú)服務(wù)技術(shù)“愛(ài)不起來(lái)”.....
有人舉例說(shuō)自己剛接手了一個(gè)無(wú)服務(wù)器項(xiàng)目，但是”我們不能在本地運(yùn)行它，因?yàn)槭种叩拇a無(wú)法在模擬器中運(yùn)行。內(nèi)存限制錯(cuò)誤對(duì)于我們來(lái)說(shuō)是完全不透明的，我們無(wú)法單步執(zhí)行并觀察中斷結(jié)果。只能通過(guò)日志來(lái)分析問(wèn)題。而且費(fèi)用太高、太瘋狂了。所以現(xiàn)實(shí)就是：你如果使用了無(wú)服務(wù)器，就意味著你無(wú)法控制代碼和所發(fā)生的事情?！?/p>
另一位程序員也說(shuō)道自己對(duì)無(wú)服務(wù)技術(shù)并不買(mǎi)賬：“我曾參加了一個(gè) webdev 大會(huì)，這場(chǎng)會(huì)議最終成了炒作無(wú)服務(wù)器技術(shù)的現(xiàn)場(chǎng)。無(wú)服務(wù)器的行業(yè)專家出于利益原因上臺(tái)演講，但卻告訴我們他們無(wú)法現(xiàn)場(chǎng)調(diào)試或運(yùn)行代碼。他們?yōu)槲覀冋故玖朔浅：?jiǎn)單的用例，然后花了一個(gè)小時(shí)來(lái)解釋如何進(jìn)行非 ACID 事務(wù)處理。而且，你只能使用 3-5 種語(yǔ)言，并且使用的每個(gè) import 語(yǔ)句都有與其對(duì)應(yīng)的金額?！?/p>
他強(qiáng)調(diào)說(shuō)，“更重要的是，你開(kāi)發(fā)中所有的這些技能都與亞馬遜或其他巨頭相關(guān)。你編寫(xiě)的所有代碼均受其約束。你遇到的任何問(wèn)題都取決于他們的支持。那么我們應(yīng)該賭上數(shù)百或數(shù)千個(gè)工時(shí)嗎？“
還有不少人認(rèn)為，雖然正如 Bernard Brode 所指出的，在某些情況下，無(wú)服務(wù)器架構(gòu)可能是一個(gè)好的設(shè)計(jì)范例，但“這個(gè)技術(shù)還比較早期，還遠(yuǎn)不夠成熟“，也不能成為服務(wù)器的直接替代。
原文鏈接：
https://www.infoq.com/articles/serverless-stalled/
聯(lián)系客服
