◆胡聰叢
無服務器計算的現(xiàn)狀以及所面臨的挑戰(zhàn)
◆胡聰叢
(中國五礦集團有限公司 北京 100010)
無服務器計算已經(jīng)成為應用和服務部署領(lǐng)域的新技術(shù)規(guī)范。它代表了云編程模型、抽象和平臺的最新演化成果。本文將從技術(shù)角度闡述無服務器計算的發(fā)展現(xiàn)狀以及其面臨的諸多挑戰(zhàn)。
無服務器計算;架構(gòu);事件處理系統(tǒng)
無服務器計算是一個由業(yè)界創(chuàng)造的術(shù)語[1]。它描述了這樣一種編程模型和架構(gòu):小代碼片段在云中執(zhí)行,無須管控運行所需的任何資源?!盁o服務器”并不是不需要服務器的意思,它只是強調(diào)開發(fā)人員應該將大多數(shù)運維問題(如資源供應、監(jiān)控、維護、可擴展性和容錯性)留給云提供商[2]。
從基礎設施即服務(Infrastructure-as-a-Service,IAAS)使用者的角度來看,這種范式轉(zhuǎn)換既帶來了機會,也帶來了風險[2]。一方面,無服務器計算為開發(fā)人員提供了一個簡化的編程模型,用于創(chuàng)建云應用程序——抽象了大部分(并非全部)運維操作;它按執(zhí)行時間計費而不是按使用資源計費,從而降低了部署成本。另一方面,在無服務器平臺中部署此類應用程序具有挑戰(zhàn)性。應用無服務器計算需要放棄一些平臺設計策略。例如,服務質(zhì)量(QoS)監(jiān)控,擴展和容錯屬性等。
從云服務供應商的角度來看,無服務器計算帶了一個額外的機會去控制整個開發(fā)棧,通過優(yōu)化和管理云資源來降低運營成本。無服務器計算相當于提供了一個平臺并鼓勵使用其生態(tài)中的其他服務,并且減少了創(chuàng)建和管理云規(guī)模應用所需付出的努力[3]。
作為一種近幾年流行的新型技術(shù),很難簡單地定義術(shù)語“無服務器”,因為該定義與其他術(shù)語(如PaaS和軟件即服務(SaaS))重疊[4]。闡釋無服務器的一個角度是,考慮不同級別的開發(fā)人員對云基礎架構(gòu)的控制。基礎設施即服務(IaaS)模型是開發(fā)人員對云計算中的應用程序代碼和操作基礎設施擁有最多控制權(quán)的模型。在這里,開發(fā)人員負責硬件或虛擬機,并可以自定義應用程序部署和執(zhí)行的各個方面。另一個極端是PaaS和SaaS模型,開發(fā)者不知道任何基礎設施,因此不再能夠控制基礎設施。相反,開發(fā)人員可以訪問預打包的組件或完整的應用程序,還可以在這里托管代碼,盡管代碼可能與平臺緊密耦合。
人們對“無服務器”這個名稱有很多誤解。服務器仍然是需要的,但開發(fā)人員不必管理這些服務器[5]。服務器數(shù)量及其性能等由平臺負責決策,服務器容量依工作負載自動分配。
無服務器平臺的核心功能是事件處理系統(tǒng)。服務必須管理一組用戶預定義的函數(shù),處理通過HTTP發(fā)送或從事件源接收的事件,確定將事件發(fā)送到哪個函數(shù),查找函數(shù)的現(xiàn)有實例或創(chuàng)建新實例,將事件發(fā)送到函數(shù)實例,等待響應、收集執(zhí)行日志、使響應對用戶可用,并在不再需要時停止該函數(shù)。
各種無服務器平臺之間存在許多共性。它們有相似的定價,部署和編程模型。它們之間的主要區(qū)別在于云生態(tài)系統(tǒng):當前的無服務器平臺只能使用它們自己生態(tài)中的服務,平臺的選擇可能會迫使開發(fā)人員使用該平臺的原生服務。但是這種情況正在發(fā)生變化,因為開放源碼解決方案也能在多個云平臺上很好地工作。
亞馬遜在2014年的Re:invent會議“AWS lambda入門”中推廣了無服務器計算。其他供應商也在2016年推出了Google Cloud Function、Microsoft AzureFunction和IBM OpenWhisk。其中一些服務商甚至提供了“云函數(shù)”,即能夠使移動應用程序在服務器端運行一些代碼,而無須管理服務器。這種服務的一個例子是Facebook的Parse Cloud Code。然而該技術(shù)只能在移動應用程序領(lǐng)域?qū)崿F(xiàn)相當有限的功能。
無服務器計算已經(jīng)被用來支持更廣泛的應用程序[6]。從功能視角來看,無服務器和更傳統(tǒng)的架構(gòu)可以互換。決定何時采用無服務器可能會受到非功能性需求的影響,例如運維量、成本以及應用負載等特性。從成本視角來看,無服務器架構(gòu)的最大優(yōu)勢展現(xiàn)在高并發(fā)、計算密集場合。從編程模型的視角來看,無服務器函數(shù)的無狀態(tài)特性使其自身結(jié)構(gòu)類似于函數(shù)式反應編程。主要用于事件驅(qū)動和流式處理模式的應用程序。
無服務器計算作為一種新興技術(shù),在實踐的過程中仍然面臨諸多挑戰(zhàn)。本文將重點從“系統(tǒng)層面的挑戰(zhàn)”以及“編程模型和DevOps挑戰(zhàn)”兩個方面進行闡述。
無服務器計算面臨的系統(tǒng)層面挑戰(zhàn)主要來自成本、冷啟動、資源限制、可擴展性等幾個方面。成本是無服務器計算當前最基本的一項挑戰(zhàn)。包括最小化無服務器函數(shù)的資源消耗(包括在執(zhí)行時和在空閑時)。無服務器的一個核心能力是能夠支持零擴展(Scaling to zero),或者在空閑時間不向客戶收費。然而,零擴展會帶來冷啟動的問題,導致需要花費代價來使無服務器代碼做好運行準備。在零擴展的同時最小化冷啟動的技術(shù)是非常重要的。無服務器系統(tǒng)需要資源限制來確保平臺能夠處理負載峰值和應對攻擊。無服務器函數(shù)上能夠設置的資源限制包括內(nèi)存、執(zhí)行時間、帶寬和CPU使用率。最后,隨著無服務器越來越受歡迎,可能有多個無服務器平臺和多個無服務器服務需要協(xié)同工作。如何在系統(tǒng)層面對各個系統(tǒng)進行調(diào)整也是無服務器技術(shù)發(fā)展不得不面臨的問題。
無服務器計算面臨的編程模型和DevOps挑戰(zhàn)來在于調(diào)試、工具、部署、以及可組合性等多個方面。由于開發(fā)人員不再能夠訪問服務器,無服務器服務和工具需要關(guān)注開發(fā)人員的生產(chǎn)效率。無服務器函數(shù)運行的時間較短,相應它們的數(shù)量級會較多,這使得定位問題和瓶頸變得更困難。當函數(shù)執(zhí)行完畢時,它們留下的唯一跟蹤就是無服務器平臺監(jiān)視記錄的內(nèi)容。傳統(tǒng)的開發(fā)工具并不適合于無服務器架構(gòu),目前急需全新的開發(fā)方法。無服務器計算需要更高的開發(fā)技能,如重構(gòu)功能(如拆分和合并功能)、版本恢復等,并且需要與無服務器平臺完全集成。開發(fā)人員需要能夠使用聲明性方法來控制部署和支持工具。
本文探討了無服務器計算的模式架構(gòu)和它的發(fā)展歷史。雖然無服務器計算的發(fā)展面臨許多挑戰(zhàn),但是大多數(shù)大型云計算服務提供商已經(jīng)發(fā)布了他們的無服務器平臺,并且在這個行業(yè)中進行了大量的投資和投入。無服務器體系的廣泛應用最終會推動新的編程模型、語言和架構(gòu)的出現(xiàn),它將給軟件工程領(lǐng)域帶來令人振奮的提升。
[1]Bryan,D.A.,B.B. Lowekamp,and C. Jennings. SOSIMPLE:A Serverless,Standards-based,P2P SIP Communication System. in International Workshop on Advanced Architectures & Algorithms for Internet Delivery & Applications. 2005.
[2]Jia,A.L.and D.M. Chiu,Designs and Evaluation of a Tracker in P2P Networks. 2008.
[3]Nastic,S.,et al.,A Serverless Real-Time Data Analytics Platform for Edge Computing. IEEE Internet Computing,2017,21(4):64-71.
[4]Lara,E.D.,et al. Poster Abstract:Hierarchical Serverless Computing for the Mobile Edge. in Edge Computing. 2016.
[5]érez,A.,et al.,Serverless computing for container-based architectures. Future Generation Computer Systems,2018(83):50-59.
[6]Douceur,J.R. and R.P. Wattenhofer. Optimizing file availability in a secure serverless distributed file system. in IEEE Symposium on Reliable Distributed Systems. 2001.