[譯] 無容器下的雲計算

• 原文地址：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、前端、後端、區塊鏈、產品、設計、人工智能等領域，想要查看更多優質譯文請持續關注 掘金翻譯計劃、官方微博、知乎專欄。