就在大約四年前，我們推出了 Cloudflare Workers，這是一個直接在邊緣執行的無伺服器平台。
在這一週的時間裡，我們將討論 Cloudflare 如何幫助加快 Web 上已經存在的應用程式的速度。但是，如果您是在今天決定將想法變為現實，那麼在 Cloudflare 邊緣構建您的專案並將其直接部署到網際網路管道，是保證您的應用程式對於世界各地的所有使用者都始終保持快速的最佳方式。
自我們上一次談論 Cloudflare Workers 與其他無伺服器平台的效能比較已經過去幾年了，我們認為是時候進行更新了。雖然過去幾年我們在 Workers 平台上的大部分工作都是為了讓平台變得更強大：引入新功能、API、儲存、偵錯和可觀察性工具，但效能並沒有被忽視。
今天，Workers 的速度比三年前提高了 30% (P90)。而且其速度比 Lambda@Edge 快 210%，比 Lambda 快 298%。
對了，我們還消除了冷啟動。
如何衡量無伺服器平台的效能？
過去，我在 CDN 之間執行了數百次效能基準測試，公式很簡單：我們使用一個名為 Catchpoint 的工具，它從世界各地的節點向同一資產發出請求，並報告為每個位置返回回應所花費的時間。
衡量無伺服器效能略有不同，因為您要比較的是運算效能，而不是靜態資產，我們希望確保所有函數都執行相同的操作。
在我們 2018 年有關速度測試的部落格中，我們讓每個函數簡單地傳回當前時間。出於本次測試的目的，無法滿足執行此工作的最低標準的「無伺服器」產品將被取消資格。此輪測試中使用的無伺服器產品執行相同的函數，具有相同的運算複雜度，以確保結果準確且公平。
同樣重要的是要注意我們衡量的是什麼。效能之所以重要，是因為它會影響實際終端客戶的體驗。無論是 DNS、網路壅塞、冷啟動還是別的什麼，延遲的來源是什麼並不重要。客戶並不關心延遲的來源，他們關心的是浪費時間等待應用程式載入。
因此，從端對端的使用者體驗的角度衡量效能非常重要，這就是我們使用全球基準來衡量效能的原因。
以下的結果顯示了從全球 50 個節點執行的測試，範圍覆蓋北美、南美、歐洲、亞洲和大洋洲。
藍色：Cloudflare Workers 紅色：Lambda@Edge 綠色：Lambda
（結果連結。）
從結果中可以看到，無論使用者身在世界何處，就速度而言，Workers 都可以保證為客戶提供最佳體驗。
對於 Workers，開發人員無需付出額外的努力即可在全球範圍內獲得最佳效能。開發人員無需進行任何額外的負載平衡或區域設定。每個部署都會立即在 Cloudflare 廣泛的邊緣網路上生效。
即使您不打算面向全球受眾，並且您的客戶群位於網路便利的美國東海岸，Workers 也能夠保證對所有請求做出最快的回應。
上圖是來自華盛頓特區的結果，盡可能接近 us-east-1。同樣，在沒有任何最佳化的情況下，Workers 的速度要快 34%。
這是為什麼呢？
無伺服器平台的效能由哪些因素決定？
除了程式碼本身的效能外，從終端使用者的角度來看，無伺服器應用程式效能基本上是關於兩個變數的函數：應用程式執行位置與使用者的距離，以及執行階段本身的啟動時間。與使用者的距離正在成為應用程式效能不斷增長的瓶頸，這一認知導致許多無伺服器廠商越來越深入地推向邊緣。在邊緣（即更靠近終端使用者的位置）執行應用程式可提高效能。隨著 5G 的上線，這一趨勢只會繼續加速。
然而，無伺服器領域的許多雲端廠商在解決競爭更快的效能這一問題時遇到了關鍵問題。那就是：他們用於構建其產品的傳統架構無法很好地應對邊緣的固有限制。
由於無伺服器模型背後的目標是有意地抽象化底層架構，因此並不是每個人都清楚像 AWS 這樣的傳統雲端提供者是如何建立像 Lambda 這樣的無伺服器產品的。傳統雲端提供者透過為您的程式碼啟動容器化處理序來提供無伺服器產品。提供者會在後台自動調整所有不同的處理序。每次啟動容器時，整個語言執行階段都會隨之啟動，而不僅僅是您的程式碼。
為了幫助解決第一個圖表，即衡量全球效能，廠商正試圖從他們的大型、集中式架構（幾個大資料中心）轉移到分散式、基於邊緣的世界（世界各地更多的小型資料中心），以縮小應用程式和終端使用者之間的距離。但他們的方法存在一個問題：更小的資料中心意味著更少的機器和更少的記憶體。每次廠商採用大量的小型資料中心策略以在更靠近邊緣的位置營運時，任何單個處理序上發生冷啟動的可能性都會增加。
這實際上為基於容器的架構上的無伺服器應用程式創造了效能上限。如果擁有小型資料中心的傳統廠商將應用程式移到更靠近邊緣（和使用者）的位置，則伺服器和記憶體將更少，並且應用程式更有可能需要冷啟動。為了減少發生這種情況的可能性，他們又回到了更中心化的模式；但這意味著從幾個大型集中式資料中心中的一個執行應用程式。根據定義，這些較大的集中式資料中心幾乎總是會離使用者更遠。
上圖中在 Lambda@Edge 中執行時的測試結果證明了這一點。儘管減少了與終端使用者的距離，p90 的效能仍比 Lambda 慢，因為容器必須更頻繁地啟動。
基於容器構建的無伺服器架構可以在邊界上下移動，但最終，它們無法做太多事情來改變邊界曲線。
是什麼讓 Workers 如此快速？
Workers 專為邊緣優先的無伺服器模型而設計。由於 Cloudflare 是從分散式邊緣網路開始，而不是嘗試將運算從大型集中式資料中心推送到邊緣，因此在這些限制下工作迫使我們進行創新。
在我們之前的一篇部落格文章中，我們討論了這項創新如何轉化為新的典範轉移，Workers 架構建立在輕量級 V8 隔離之上，可以快速啟動，而無需針對每個請求引入冷啟動。
執行隔離不僅為我們帶來了開箱即用的優勢，而且隨著 V8 不斷完善，我們的平台也會如此。例如，當 V8 宣佈推出 WASM 編譯器 Liftoff 時，所有 WASM Workers 的速度都立即變得更快。
同樣，每當對 Cloudflare 的網路（例如，新增新的資料中心）或堆疊（例如，支援新的、更快的通訊協定，如 HTTP/3）進行改進時，Workers 都會立即從中受益。
此外，我們一直在尋求改進 Workers 本身，以使平台更快。例如，去年，我們發佈了一項改進，幫助客戶消除了冷啟動。
可協助 Workers 識別並解決效能差距的一個關鍵優勢是其營運規模。如今，Workers 為世界各地成千上萬的開發人員（從愛好者到企業）提供服務，每秒可處理數百萬個請求。每當我們為單個客戶進行改進時，整個平台都會變得更快。
效能至關重要
無伺服器模型的最終目標是讓開發人員能夠專注於他們最擅長的事情——為使用者構建體驗。選擇能夠立即提供最佳效能的無伺服器平台意味著開發人員少了一件需要擔心的事情。如果您花時間來針對冷啟動進行最佳化，那麼您就沒有時間來為客戶建立最佳功能。
就像開發人員希望透過提高應用程式的效能來為其使用者創造最佳體驗一樣，我們也在不斷努力改善基於 Workers 進行構建的開發人員的體驗。
就像客戶不希望等待緩慢的回應一樣，開發人員也不希望等待緩慢的部署週期。
這就是 Workers 平台再次表現出色的地方。
Cloudflare Workers 上的任何部署都只需不到一秒的時間即可在全球傳播，因此您不必浪費時間等待程式碼部署，而且使用者可以盡快看到變更。
當然，重要的不僅僅是部署時間本身，整個開發週期的效率也很重要，這就是為什麼我們始終在每一步尋求改進：從註冊到偵錯。
不要只是相信我們的話！
很顯然，儘管我們盡量保持中立，但總是會有些偏見。幸運的是，您不必僅僅只是相信我們所說的話。
我們誠邀您立即註冊並部署您的第一個 Worker，只需幾分鐘即可完成！