◆胡聰叢

無服務(wù)器計算的現(xiàn)狀以及所面臨的挑戰(zhàn)

◆胡聰叢

（中國五礦集團(tuán)有限公司 北京 100010）

無服務(wù)器計算已經(jīng)成為應(yīng)用和服務(wù)部署領(lǐng)域的新技術(shù)規(guī)范。它代表了云編程模型、抽象和平臺的最新演化成果。本文將從技術(shù)角度闡述無服務(wù)器計算的發(fā)展現(xiàn)狀以及其面臨的諸多挑戰(zhàn)。

無服務(wù)器計算；架構(gòu)；事件處理系統(tǒng)

無服務(wù)器計算是一個由業(yè)界創(chuàng)造的術(shù)語[1]。它描述了這樣一種編程模型和架構(gòu)：小代碼片段在云中執(zhí)行，無須管控運(yùn)行所需的任何資源?！盁o服務(wù)器”并不是不需要服務(wù)器的意思，它只是強(qiáng)調(diào)開發(fā)人員應(yīng)該將大多數(shù)運(yùn)維問題（如資源供應(yīng)、監(jiān)控、維護(hù)、可擴(kuò)展性和容錯性）留給云提供商[2]。

從基礎(chǔ)設(shè)施即服務(wù)（Infrastructure-as-a-Service，IAAS）使用者的角度來看，這種范式轉(zhuǎn)換既帶來了機(jī)會，也帶來了風(fēng)險[2]。一方面，無服務(wù)器計算為開發(fā)人員提供了一個簡化的編程模型，用于創(chuàng)建云應(yīng)用程序——抽象了大部分（并非全部）運(yùn)維操作；它按執(zhí)行時間計費(fèi)而不是按使用資源計費(fèi)，從而降低了部署成本。另一方面，在無服務(wù)器平臺中部署此類應(yīng)用程序具有挑戰(zhàn)性。應(yīng)用無服務(wù)器計算需要放棄一些平臺設(shè)計策略。例如，服務(wù)質(zhì)量（QoS）監(jiān)控，擴(kuò)展和容錯屬性等。

從云服務(wù)供應(yīng)商的角度來看，無服務(wù)器計算帶了一個額外的機(jī)會去控制整個開發(fā)棧，通過優(yōu)化和管理云資源來降低運(yùn)營成本。無服務(wù)器計算相當(dāng)于提供了一個平臺并鼓勵使用其生態(tài)中的其他服務(wù)，并且減少了創(chuàng)建和管理云規(guī)模應(yīng)用所需付出的努力[3]。

1 無服務(wù)器計算的現(xiàn)狀

1.1 無服務(wù)器計算的定義

作為一種近幾年流行的新型技術(shù)，很難簡單地定義術(shù)語“無服務(wù)器”，因為該定義與其他術(shù)語（如PaaS和軟件即服務(wù)（SaaS））重疊[4]。闡釋無服務(wù)器的一個角度是，考慮不同級別的開發(fā)人員對云基礎(chǔ)架構(gòu)的控制?；A(chǔ)設(shè)施即服務(wù)（IaaS）模型是開發(fā)人員對云計算中的應(yīng)用程序代碼和操作基礎(chǔ)設(shè)施擁有最多控制權(quán)的模型。在這里，開發(fā)人員負(fù)責(zé)硬件或虛擬機(jī)，并可以自定義應(yīng)用程序部署和執(zhí)行的各個方面。另一個極端是PaaS和SaaS模型，開發(fā)者不知道任何基礎(chǔ)設(shè)施，因此不再能夠控制基礎(chǔ)設(shè)施。相反，開發(fā)人員可以訪問預(yù)打包的組件或完整的應(yīng)用程序，還可以在這里托管代碼，盡管代碼可能與平臺緊密耦合。

1.2 無服務(wù)器計算的架構(gòu)

人們對“無服務(wù)器”這個名稱有很多誤解。服務(wù)器仍然是需要的，但開發(fā)人員不必管理這些服務(wù)器[5]。服務(wù)器數(shù)量及其性能等由平臺負(fù)責(zé)決策，服務(wù)器容量依工作負(fù)載自動分配。

無服務(wù)器平臺的核心功能是事件處理系統(tǒng)。服務(wù)必須管理一組用戶預(yù)定義的函數(shù)，處理通過HTTP發(fā)送或從事件源接收的事件，確定將事件發(fā)送到哪個函數(shù)，查找函數(shù)的現(xiàn)有實例或創(chuàng)建新實例，將事件發(fā)送到函數(shù)實例，等待響應(yīng)、收集執(zhí)行日志、使響應(yīng)對用戶可用，并在不再需要時停止該函數(shù)。

各種無服務(wù)器平臺之間存在許多共性。它們有相似的定價，部署和編程模型。它們之間的主要區(qū)別在于云生態(tài)系統(tǒng)：當(dāng)前的無服務(wù)器平臺只能使用它們自己生態(tài)中的服務(wù)，平臺的選擇可能會迫使開發(fā)人員使用該平臺的原生服務(wù)。但是這種情況正在發(fā)生變化，因為開放源碼解決方案也能在多個云平臺上很好地工作。

1.3 無服務(wù)器計算的應(yīng)用

亞馬遜在2014年的Re：invent會議“AWS lambda入門”中推廣了無服務(wù)器計算。其他供應(yīng)商也在2016年推出了Google Cloud Function、Microsoft AzureFunction和IBM OpenWhisk。其中一些服務(wù)商甚至提供了“云函數(shù)”，即能夠使移動應(yīng)用程序在服務(wù)器端運(yùn)行一些代碼，而無須管理服務(wù)器。這種服務(wù)的一個例子是Facebook的Parse Cloud Code。然而該技術(shù)只能在移動應(yīng)用程序領(lǐng)域?qū)崿F(xiàn)相當(dāng)有限的功能。

無服務(wù)器計算已經(jīng)被用來支持更廣泛的應(yīng)用程序[6]。從功能視角來看，無服務(wù)器和更傳統(tǒng)的架構(gòu)可以互換。決定何時采用無服務(wù)器可能會受到非功能性需求的影響，例如運(yùn)維量、成本以及應(yīng)用負(fù)載等特性。從成本視角來看，無服務(wù)器架構(gòu)的最大優(yōu)勢展現(xiàn)在高并發(fā)、計算密集場合。從編程模型的視角來看，無服務(wù)器函數(shù)的無狀態(tài)特性使其自身結(jié)構(gòu)類似于函數(shù)式反應(yīng)編程。主要用于事件驅(qū)動和流式處理模式的應(yīng)用程序。

2 無服務(wù)器計算所面臨的挑戰(zhàn)

無服務(wù)器計算作為一種新興技術(shù)，在實踐的過程中仍然面臨諸多挑戰(zhàn)。本文將重點從“系統(tǒng)層面的挑戰(zhàn)”以及“編程模型和DevOps挑戰(zhàn)”兩個方面進(jìn)行闡述。

2.1 系統(tǒng)層面的挑戰(zhàn)

無服務(wù)器計算面臨的系統(tǒng)層面挑戰(zhàn)主要來自成本、冷啟動、資源限制、可擴(kuò)展性等幾個方面。成本是無服務(wù)器計算當(dāng)前最基本的一項挑戰(zhàn)。包括最小化無服務(wù)器函數(shù)的資源消耗（包括在執(zhí)行時和在空閑時）。無服務(wù)器的一個核心能力是能夠支持零擴(kuò)展（Scaling to zero），或者在空閑時間不向客戶收費(fèi)。然而，零擴(kuò)展會帶來冷啟動的問題，導(dǎo)致需要花費(fèi)代價來使無服務(wù)器代碼做好運(yùn)行準(zhǔn)備。在零擴(kuò)展的同時最小化冷啟動的技術(shù)是非常重要的。無服務(wù)器系統(tǒng)需要資源限制來確保平臺能夠處理負(fù)載峰值和應(yīng)對攻擊。無服務(wù)器函數(shù)上能夠設(shè)置的資源限制包括內(nèi)存、執(zhí)行時間、帶寬和CPU使用率。最后，隨著無服務(wù)器越來越受歡迎，可能有多個無服務(wù)器平臺和多個無服務(wù)器服務(wù)需要協(xié)同工作。如何在系統(tǒng)層面對各個系統(tǒng)進(jìn)行調(diào)整也是無服務(wù)器技術(shù)發(fā)展不得不面臨的問題。

2.2 編程模型和DevOps挑戰(zhàn)

無服務(wù)器計算面臨的編程模型和DevOps挑戰(zhàn)來在于調(diào)試、工具、部署、以及可組合性等多個方面。由于開發(fā)人員不再能夠訪問服務(wù)器，無服務(wù)器服務(wù)和工具需要關(guān)注開發(fā)人員的生產(chǎn)效率。無服務(wù)器函數(shù)運(yùn)行的時間較短，相應(yīng)它們的數(shù)量級會較多，這使得定位問題和瓶頸變得更困難。當(dāng)函數(shù)執(zhí)行完畢時，它們留下的唯一跟蹤就是無服務(wù)器平臺監(jiān)視記錄的內(nèi)容。傳統(tǒng)的開發(fā)工具并不適合于無服務(wù)器架構(gòu)，目前急需全新的開發(fā)方法。無服務(wù)器計算需要更高的開發(fā)技能，如重構(gòu)功能（如拆分和合并功能）、版本恢復(fù)等，并且需要與無服務(wù)器平臺完全集成。開發(fā)人員需要能夠使用聲明性方法來控制部署和支持工具。

3 總結(jié)

本文探討了無服務(wù)器計算的模式架構(gòu)和它的發(fā)展歷史。雖然無服務(wù)器計算的發(fā)展面臨許多挑戰(zhàn)，但是大多數(shù)大型云計算服務(wù)提供商已經(jīng)發(fā)布了他們的無服務(wù)器平臺，并且在這個行業(yè)中進(jìn)行了大量的投資和投入。無服務(wù)器體系的廣泛應(yīng)用最終會推動新的編程模型、語言和架構(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.