無服務器計算的現狀以及所面臨的挑戰

◆胡聰叢

無服務器計算的現狀以及所面臨的挑戰

◆胡聰叢

（中國五礦集團有限公司 北京 100010）

無服務器計算已經成為應用和服務部署領域的新技術規范。它代表了云編程模型、抽象和平臺的最新演化成果。本文將從技術角度闡述無服務器計算的發展現狀以及其面臨的諸多挑戰。

無服務器計算；架構；事件處理系統

無服務器計算是一個由業界創造的術語[1]。它描述了這樣一種編程模型和架構：小代碼片段在云中執行，無須管控運行所需的任何資源。“無服務器”并不是不需要服務器的意思，它只是強調開發人員應該將大多數運維問題（如資源供應、監控、維護、可擴展性和容錯性）留給云提供商[2]。

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

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

1 無服務器計算的現狀

1.1 無服務器計算的定義

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

1.2 無服務器計算的架構

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

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

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

1.3 無服務器計算的應用

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

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

2 無服務器計算所面臨的挑戰

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

2.1 系統層面的挑戰

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

2.2 編程模型和DevOps挑戰

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

3 總結

本文探討了無服務器計算的模式架構和它的發展歷史。雖然無服務器計算的發展面臨許多挑戰，但是大多數大型云計算服務提供商已經發布了他們的無服務器平臺，并且在這個行業中進行了大量的投資和投入。無服務器體系的廣泛應用最終會推動新的編程模型、語言和架構的出現，它將給軟件工程領域帶來令人振奮的提升。

[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.