無伺服器將像智慧手機終結PC時代帶來革命變化！ -ACM

banq發表於2021-05-07
伺服器ACM

無伺服器Severless計算儘管在不斷髮展，但是在定義其抽象和實現方面都存在許多懸而未決的問題。我們（大膽地）總結了下一個十年對無伺服器計算的五種預測：
  1. 當今的FaaS和BaaS分類將消失，讓位於更廣泛的抽象，我們將其歸類為通用無伺服器計算或特定於應用程式的無伺服器計算。
  2. 新的通用無伺服器抽象能夠支援幾乎所有用例。它們將支援狀態管理以及使用者建議或自動推斷的最佳化，以實現與伺服器計算相當或更高的效率。
  3. 隨著不斷的發展和普及，幾乎任何應用程式（無論是小型應用程式還是大規模應用程式）使用無伺服器計算都不會花費更多費用，反而可能更少。
  4. 機器學習將在無伺服器實現中扮演關鍵角色，從而允許雲提供商在提供簡單的程式設計介面的同時最佳化大規模分散式系統的執行。
  5. 用於無伺服器計算的計算機硬體將比當今為其提供支援的傳統x86伺服器更加異構。

如果這些預測成立，則無伺服器計算將成為雲時代的預設計算範例，在很大程度上取代有伺服器的計算，從而結束客戶端-伺服器C/S時代，就像智慧​​手機帶動了PC時代的終結一樣。
 

無伺服器計算的抽象模型
無伺服器提供一種隱藏伺服器的抽象，從而簡化了程式設計和運營模型。
傳統現有的雲端計算幾乎沒有改變程式設計師的工作方式，尤其是與它對運營商的影響相比，在雲中執行的許多軟體與在傳統資料中心中執行的軟體完全相同。將當今最需要的程式設計技能與10年前所需的程式設計技能進行比較，您會注意到，即使隨著特定技術的出現和發展，核心技能集的變化也很小。
相比之下，運維工作發生了巨大變化。安裝和維護伺服器，儲存和網路已經成為過去，而不再是透過雲提供者API來管理虛擬化基礎架構，而是被DevOps運動所取代，後者著重於變更管理的技術和組織方面。
是什麼使得在雲中進行程式設計變得困難？
大多數雲程式設計實際變成了分散式系統程式設計。在編寫分散式系統時，程式設計師必須考慮資料中心的空間範圍，各種區域性故障模式以及所有安全威脅。這些關注表示“意外複雜性”，它是由實現環境引起的，與“基本複雜性”形成對比，後者是應用程式提供的功能中固有的。
當初高階語言正在取代組合語言，從而使程式設計師無需再考慮複雜的機器詳細資訊，例如暫存器分配或記憶體中的資料佈局。就像高階語言隱藏了CPU工作方式的許多細節一樣，無伺服器計算也隱藏了構建可靠，可伸縮且安全的分散式系統所需要花費的許多細節。
 

雲端計算的兩個階段
簡而言之，雲端計算第一階段的目標是簡化系統管理員工作，第二階段的目標應該是針對程式設計師。這一變化要求雲提供商承擔良好執行應用程式所需的許多運營職責。

  1. 自己租車和打計程車比較雲端計算兩個階段：要參加遠端會議，您可以租用汽車或呼叫計程車來從機場到達酒店。自己租車就像伺服器計算一樣，無論您使用多少，都必須排隊等候，簽訂合同，在整個逗留期間預訂汽車，自己開車，前往酒店，支付停車費並填滿汽車在返回之前先加油。
  2. 打計程車就像無伺服器計算一樣，您只需要提供酒店名稱並付費即可。計程車服務提供訓練有素的駕駛員，他們可以導航，乘車收費並給油箱加油。計程車可以簡化交通，因為您無需知道如何操作汽車即可到達酒店。此外，計程車比出租汽車獲得更高的利用率，從而降低了計程車公司的成本。

在無伺服器計算中，程式設計師使用雲提供商提供的高階抽象來建立應用程式。例如，他們可以定義雲函式，一種“無狀態”函式，可以選擇語言如JavaScript和Python程式設計，然後指定函式如何執行，無論是在響應Web請求或觸發事件。他們還可以使用無伺服器物件儲存、訊息佇列、鍵值儲存資料庫或移動客戶端資料同步等等，這些服務集合稱為後端即服務（BaaS）。託管雲函式服務也稱為函式即服務（FaaS），如今統稱為無伺服器雲端計算= FaaS + BaaS
 

無伺服器抽象模型的應用
讓我們研究大資料處理中的一個示例：一個可能在電子商務環境中出現的簡單查詢：使用從一百萬個類別派生的權重計算平均超過100億條記錄。這種工作負載具有大量並行性的潛力，因此它受益於無限資源的無伺服器。
我們提供了兩種適合該示例的特定於應用程式的無伺服器產品，並說明了該類別如何提供多種方法：

  1. 可以使用AWS Athena大資料查詢引擎（一種使用SQL（結構化查詢語言）程式設計的工具）對物件儲存中的資料執行查詢。SQL特別適合於分析，並且可以用一條語句來表示此計算。
  2. 或者，可以使用Google Cloud Dataflow提供的框架。這樣做需要編寫一個簡單的MapReduce樣式，使用Java或Python的程式，具有兩個功能：一個功能為某些資料塊計算加權平均值，另一個功能為單獨的資料塊將加權平均值合併為一個聯合值。該框架負責將資料管道傳入和傳出這些功能，以及自動縮放，可靠性和其他分散式系統問題。與基於SQL的工具相比，此抽象可以執行任意程式碼，從而使其適合於更廣泛的分析問題。

為我們的大資料示例提供高效能解決方案的通用無伺服器抽象尚不存在。雲函式似乎可以提供一種解決方案，因為它們允許使用者編寫任意程式碼，並且對於某些工作負載，但由於限制，它們的效能有時會比其他方法差很多。
如果我們使用雲函式，而不是使用特定應用的框架，例如雲資料流實現我們的榜樣。藉助雲函式，提供商無需考慮應用程式的通訊模式即可在各種VM例項之間分配工作，從而簡化了自動擴充套件，但增加了網路流量。
 

雲函式增強
我們建議了兩種增強雲函式的途徑，以便它們在更廣泛的應用程式中良好執行，有可能將它們轉變為通用的無伺服器抽象。
首先，我們假設程式設計師可能需要如何獲得更好的效能。可能需要描述應用程式通訊模式（例如，廣播或全部減少），或建議任務放置關聯。這種方法在編譯器中具有先例（例如，分支預測，對齊和預取提示）。
其次，更令人信服的是，我們設想透過自動最佳化來消除效率低下的問題。在我們的示例中，雲提供商可能會承諾從觀察到的通訊模式中推斷出位置最佳化。在某些情況下，也可以基於對程式的分析來靜態地進行此類推斷。在單機環境中，這在現代編譯器和語言執行時所做的工作中已有很多先例，並且人們可能會認為這種形式的無伺服器計算是對分散式系統的語言支援。
 

相關文章