[譯] 無容器下的雲端計算

• 原文地址：Cloud Computing without Containers
• 原文作者：Zack Bloom
• 譯文出自：掘金翻譯計劃
• 本文永久連結：github.com/xitu/gold-m…
• 譯者：TrWestdoor
• 校對者：tonylua

Cloudflare 有一個雲端計算平臺稱為 Workers。不像據我所知道的其它雲端計算平臺所必須的那樣，它無需容器或虛擬機器。我們相信這將是無伺服器和雲端計算的未來，我也將努力說服你這是為什麼。

Isolate

兩年前我們面臨一個問題。受限於應當在內部建立多少特性和選項，我們需要為使用者找到一個方法來使得他們能自己完成構建。因此我們著手尋找一個方法可以讓人們在我們部署在全球各地的伺服器上（我們有一百多個資料中心，截止本文寫作時這個數字為 155）寫程式碼。我們的系統需要可以安全且低開銷的執行不可信的程式碼。我們坐在上千萬的站點前，每秒執行數百萬個請求，同時還要求必須執行得非常非常快。

之前我們使用的 Lua 並不在沙盒中執行；使用者不能在沒有我們監督的情況下寫他們自己的程式碼。像 Kubernetes 這種傳統的虛擬化和容器技術對每個相關使用者來說都格外昂貴。在單一位置執行數千個 Kubernetes pods 將會是資源密集型的，在 155 個地方執行則將更糟。相比於沒有管理系統，擴充套件他們會更容易些，但也絕非易事。

最後我們用上了由 Google Chrome 團隊構建的一項為其瀏覽器中的 Javascript 引擎提供動力的技術 — V8: Isolates。

Isolates 是一個輕量的上下文，包含了被分組過的若干變數及用來改變它們的程式碼。更重要的是，一個單一的程式可以執行成百上千個 Isolates，並且在它們之間無縫切換。這使得在一個作業系統程式上執行來自不同使用者的不可信程式碼成為可能。它們被設計的可以快速啟動（有幾個不得不在你的瀏覽器中啟動，這僅僅是為你載入這個網頁），並且不允許一個 Isolate 訪問其它 Isolate 的記憶體。

我們承擔一次 Javascript 的執行開銷，然後基本上可以無限執行這個指令碼，並且幾乎無需再單獨承擔某次的開銷。啟動任何給定的 Isolate 都比在我的機器上啟動 Node 程式快一百倍。更重要的是，它們比該程式所需的記憶體消耗要少一個數量級。

它們具有所有友善的功能即服務（function-as-a-service）的人體工程學，只需要編寫程式碼而不必擔心它如何執行或縮放。與此同時，它們不使用虛擬機器或容器，這意味著你實際上以一種我所知的其他任何一種雲端計算方式都更接近裸金屬的方式執行著。我相信這種模型更接近在裸金屬上執行程式碼的經濟型，但卻執行在完全無伺服器的環境中。

本文並不是 Workers 的一個軟廣，但是我想要展示一個圖表來反映差別有多麼明顯，以展示為什麼我認為這不是一個迭代式的改進，而是一個實際的模式轉換：

這個資料反映了從最近的資料中心執行請求的反應時間（包括網路延遲），這個資料中心部署了所有的功能，按照 CPU 密集型執行。來源

冷啟動

並非所有人都充分理解類似於 Lambda 這樣的傳統無伺服器平臺是如何工作的。它給你的程式碼構建一個容器程式。相比於在你自己的機器上執行 Node，它不會在一個更輕量級的環境中執行你的程式碼。它所做的是自動縮放這些程式（稍顯笨拙）。這個自動縮放過程則會導致冷啟動。

冷啟動是指你的程式碼的新副本必須在一個機器上啟動時而發生的事情。在 Lambda 的世界中，這相當於構建一個新的容器程式，這大概會花費500毫秒到10秒的時間。任何來自於你的請求都會被掛起十秒之多，相當糟糕的使用者體驗。一個 Lambda 在某一時刻只能處理一個請求，所以每次有額外的併發請求時一個新的 Lambda 就必須冷啟動了。這意味著延遲請求可能會一再發生。如果你的 Lambda 沒有及時收到請求，它將被關閉然後再重頭開始。無論何時你部署新程式碼這都會重新發生，因為每個 Lambda 必須被重新部署。這常被認為是無伺服器化並非吹噓的那麼好的原因。

因為 Workers 無需開始一個程式，Isolates 在5毫秒內啟動，這個時間是令人難以察覺的。同樣的，Isolates 測量和部署的非常快，完全消除了現有無伺服器技術面臨的問題。

上下文切換

作業系統的一個關鍵特性是允許你一次執行多個程式。它在任何時刻你想執行的程式碼的程式上透明地切換。為了實現這一點而將其稱之為‘上下文切換’：將一個程式所需的記憶體全部移出，並將下一個程式所需的記憶體載入進來。

上下文切換大概需要花費 100 多毫秒。當該時間與執行在你的 Lambda 伺服器上的所有 Node、Python 或 Go 程式相乘時，會導致繁重的開銷，這意味著 CPU 們的算力並沒有全部應用到使用者的程式碼執行上來，因為它被花費在了上下文切換中。

基於 Isolate 的系統會在一個程式中執行完所有程式碼，並且使用自己的機制來保證安全的記憶體訪問。這意味著無需在上下文切換中花費過多，機器實際上將幾乎所有時間都用來執行你的程式碼。

記憶體

Node 或 Python 的執行時旨在執行於獨立使用者的自有伺服器上。這些程式碼從來沒有被考慮過將其執行在多租戶環境中，這種環境有成千上萬個其他使用者程式碼和嚴格的記憶體要求。一個基本的 Node Lambda 執行的記憶體消耗大約是 35 MB。當你像我們這樣在所有 Isolates 之間共享執行時的時候，這個數字會降到大約 3 MB。

記憶體常常是執行使用者程式碼時最大的成本消耗（甚至高過 CPU），降低它一個數量級可以極大程度改善經濟性。

基本的 V8 被設計成多租戶模式。它被設計成在單個程式的隔離環境中，在你的瀏覽器的多個標籤裡執行程式碼。Node 和類似的執行時則並非如此，它顯示在構建在其上的多租戶系統中。

安全性

在同一個程式裡面執行多個使用者的程式碼顯然需要仔細注意安全性。對於 Cloudflare 來說，自己構建這個隔離層既沒有生產力也沒有效率。它需要大量的測試、模糊、滲透測試，以及建立一個真正安全且如此複雜的系統所需要的資源。

使得這一切可行的唯一原因就是 V8 的開源性，以及它作為或許是世界上最好的安全測試軟體的地位。我們也構建了少量的安全層，包括對定時攻擊的各種保護，但是 V8 才是確保這個計算模型可行的真正奇蹟。

計費

這並不意味著要對 AWS 的計費進行公投，但是卻有一個很有趣的經濟現象值得簡單提一下。Lambda 的計費是按照它們的執行時間來計算的。該計費被四捨五入到最近的 100 毫秒，這意味著人們每次平均執行達到 50 毫秒就要多付錢。更糟的是，他們給你開的賬單是整個 Lambda 的執行時間，即使時間是花費在等待外部請求的完成。由於外部請求的時間一般都是數百上千毫秒，你最終可能會支付一個很荒謬的價錢。

Isolates 只佔有非常少量的記憶體空間，這樣至少我們僅僅會為你的程式碼的實際執行時間開具賬單。

在我們的例子中，由於更低的開銷，Workers 最終在每個 CPU 週期上可以便宜 3 倍。一個 Worker 對每百萬請求提供 50 毫秒 CPU 的價錢是 0.50 美元，同樣的 Lambda 對每百萬請求的價錢是 1.84 美元。我相信降低 3 倍的成本可以有效的推動公司們轉向基於 Isolate 的提供商。

網路就是電腦

亞馬遜有一個名為 Lambda@Edge 的產品，它被部署在他們的 CDN 資料中心。不幸的是，它比傳統的 Lambda 要貴三倍，並且它需要在初次部署時花費大約 30 分鐘。它還不允許任意請求，將其用途限制為與 CDN 類似的用途。

相反，正如我提到的，使用 Isolate 我們可以將原始檔部署到 155 個資料中心，並且在經濟性上比亞馬遜做的更好。實際上在 155 個 Isolates 上執行比在一個容器中執行要更加便宜，也或許是亞馬遜在向市場收取一個大家能承受但是比他們的成本高得多的費用。我不知道亞馬遜的經濟狀況，我只知道我們對我們自己的很滿意。

很久以前人們就確定，要有一個真實可靠的系統那它必須部署在地球上的多個地方。但 Lambda 執行在一個單一的有效區，單一的區域和一個單一的資料中心。

缺陷

沒有技術是完美無瑕的，每一次轉變都會伴隨一些缺陷。基於 Isolate 的系統不能任意編譯程式碼。程式級隔離允許你的 Lambda 擁有任何它需要的二進位制檔案。在一個 Isolate 空間中，你必須使用 Javascript 來編寫你的程式碼（我們使用了大量的 TypeScript），或者使用像 Go 或 Rust 這種針對 WebAssembly 的語言。

如果你不能重新編譯程式，你就不能在一個 Isolate 中執行它們。這或許意味著基於 Isolate 的無伺服器化只能用於更新的、更現代化的、當下流行的應用程式。它也可能意味著遺留的應用程式僅僅能將最敏感的部件移動到 Isolate 的初始化中。社群也在尋找更新更好的方法來將現有的應用程式轉到 WebAssembly，使得這些問題還有討論的餘地。

我們需要你

我希望你可以嘗試一下 Workers並且讓我們和社群知道你的經歷。仍然有很多需要我們去完善建立的內容，我們可以利用你的反饋來做這些。

我們同樣需要一些對這感興趣並想將其應用到新方向的工程師和產品經理。如果你是在舊金山，奧斯丁或者倫敦，請加入我們吧。

如果發現譯文存在錯誤或其他需要改進的地方，歡迎到 掘金翻譯計劃 對譯文進行修改並 PR，也可獲得相應獎勵積分。文章開頭的 本文永久連結 即為本文在 GitHub 上的 MarkDown 連結。

---

掘金翻譯計劃 是一個翻譯優質網際網路技術文章的社群，文章來源為 掘金 上的英文分享文章。內容覆蓋 Android、iOS、前端、後端、區塊鏈、產品、設計、人工智慧等領域，想要檢視更多優質譯文請持續關注 掘金翻譯計劃、官方微博、知乎專欄。