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

◆胡聰叢

無服務器計算的現(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]。

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

1.1 無服務器計算的定義

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

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

人們對“無服務器”這個名稱有很多誤解。服務器仍然是需要的，但開發(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ā)生變化，因為開放源碼解決方案也能在多個云平臺上很好地工作。

1.3 無服務器計算的應用

亞馬遜在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ū)動和流式處理模式的應用程序。

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

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

2.1 系統(tǒng)層面的挑戰(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ā)展不得不面臨的問題。

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

無服務器計算面臨的編程模型和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ā)人員需要能夠使用聲明性方法來控制部署和支持工具。

3 總結(jié)

本文探討了無服務器計算的模式架構(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.