謹以此記錄文中的一些觀點。Learn english well！
簡而言之，無服務器計算= FaaS + BaaS。在定義中，對於服務被視爲無服務器，它必須自動擴展而無需顯式配置，並根據使用情況進行計費。在任何無服務器平臺中，用戶只需要用高級語言編寫雲功能，選擇應觸發功能運行的事件，隨後就可以讓無服務器系統處理其他所有事情。
無服務器計算和服務器計算之間有三個關鍵區別：
1、解耦計算和存儲。存儲和計算是單獨提供和定價的。通常，存儲由單獨的雲服務提供，且計算是無狀態的。
2、在不管理資源分配的情況下執行代碼。用戶不再請求資源，而是僅提供一段代碼，雲自動提供執行該代碼的資源。
3、按使用資源的比例支付，而不按分配資源的比例支付。按照與執行相關的某個維度進行計費，比如執行時間，而不根據基本雲平臺的維度，比如分配的vm的大小和數量。
無服務器計算的吸引力：
1、對於雲提供商而言，無服務器計算可促進業務增長，因爲使雲更容易編程有助於吸引新客戶並幫助現有的客戶更多地去使用雲產品。
2、無服務器計算還將雲部署級別從x86機器代碼提高到了高級編程語言，這將爲架構創新帶來可能性。雲提供商甚至可以研究面向編程語言的優化和領域特定的體系結構，這些體系結構可以加速用高級編程語言編寫的程序。
3、雲用戶新手可以在不瞭解雲基礎架構的情況下部署一些功能，因此便可以節省開發時間並專注於應用程序獨有的問題。
4、無服務器計算用戶也可以節省資金。
當今無服務器計算平臺的侷限性：
1、用於細粒度操作的存儲不足。無服務器平臺的無狀態特性使得其難以支持具有細粒度狀態共享需求的應用程序，這主要因爲雲提供商現有存儲服務的限制，需要雲提供商開發短暫且持久的無服務器存儲選項
2、缺乏細粒度的協調。爲了擴展對有狀態應用程序的支持，無服務器框架需要爲這些任務提供協調的方法。
3、標準通信模式的性能較差。
4、系統性能。儘管雲功能的啓動延遲比傳統的基於VM的低得多，但啓動新實例時產生的延遲對於某些應用程序來說可能非常高。
無服務器計算面臨的挑戰：
1、抽象挑戰。
（1）資源需求：如今的無服務器產品，開發人員可以指定雲功能的內存大小和執行時間，而不能指定其他資源需求，這阻礙了那些想要控制更多指定資源的人。
解決辦法是提高抽象級別，讓雲提供商推斷資源需求，而不是讓開發人員指定它們。所以，雲提供商可以使用各種方法，從靜態代碼分析，到分析以前的運行，到動態（重新）編譯，以將代碼重新定位到其他體系結構。
（2）數據依賴性：如今的雲功能平臺不瞭解雲功能之間的數據依賴性，更不用說它們之間可能交換的數據量。這種無知可能會導致次優放置，進而導致通信模式效率低下。
解決這一挑戰的一種方法是讓雲提供商公開一個API，該API允許應用程序指定其計算圖，從而實現更好的佈局決策，從而最大限度地減少通信並提高性能。
2、系統挑戰
（1）高性能、經濟實惠、透明調配的存儲：
爲無服務器應用程序提供短暫存儲的一種方法是使用優化的網絡堆棧構建分佈式內存服務，以確保微秒級別的延遲。此類存儲必須跨應用程序提供訪問保護和性能隔離。
提供持久存儲的一種方法是利用基於SSD的分佈式存儲與分佈式內存緩存。
（2）減少啓動時間：啓動時間有三部分：1、調度和啓動資源以運行雲功能2、下載應用軟件環境（例如操作系統、庫）以運行功能代碼3、執行特定於應用程序的啓動任務
可以通過開發新的輕量級隔離機制來縮短部分1的啓動時間；縮短部分2的時間，一種方法是利用單核，另一種方法是在應用程序調用庫時動態地和遞增地加載庫；雲提供商可以提前執行啓動任務進而縮短部分3的時間。
3、網絡挑戰
雲功能會對流行的通信原語（如廣播、聚合和混洗）產生巨大的開銷，應對這一挑戰可能有以下幾種方法。
（1）爲雲功能提供更多的核心；
（2）允許開發人員明確的將雲功能放在同一個VM實例上。
（3）讓應用程序提供一個計算圖，使雲提供商能夠共同定位雲功能，以最大限度地減少通信開銷。
4、安全挑戰
（1）調度隨機化和物理隔離
（2）細粒度的安全環境
（3）無意識的無服務器計算
5、計算機體系結構的挑戰
硬件異構性、定價和便於管理：針對硬件異構性有兩種方法可以應對（1）無服務器可以包含多種實例類型，每個會計單位的價格取決於所使用的硬件。（2）雲提供商可以自動選擇基於語言的加速器和DSA。
對無服務器計算的預測：
（1）我們希望創建新的BaaS存儲服務。這樣的存儲將匹配本地塊存儲的性能，並具有臨時和持久兩種變體。
（2）我們希望無服務器計算比服務器計算更容易安全地編程。
（3）我們預測計費模型將會改變，這樣幾乎任何應用程序在幾乎任何規模上運行，使用無服務器計算的成本都不會增加，甚至更少。
（4）所有云提供商可能將在無服務器計算之上難以編寫的應用程序作爲服務集的一部分提供。
（5）隨着無服務器計算克服目前的侷限性，部分雲計算的相對重要性將下降。
（6）無服務器計算將成爲雲時代的默認計算範式，在很大程度上會取代服務器計算，從而結束客戶機-服務器時代。
感想：無服務器計算必將成爲未來發展的趨勢，其按用戶的使用量來計費，這便可以減少用戶花銷。同時，對於開發人員，其只需要將編寫好的代碼上傳到雲端便可以直接運行，省去之前需要配置服務器環境等步驟，降低了開發和運維的複雜性，縮短了業務系統的交付週期，提升了開發效率。但是無服務器計算所面臨的安全、網絡以及系統等方面的挑戰還有待我們深思、解決。