我們都經歷過網站載入緩慢或應用程式在需要呼叫 API 進行更新時停滯不前的挫敗感。任何不那麼即時的事情都會讓您的思緒飄向別的事情......
一種加快速度的方法是使資源盡可能靠近使用者——這是 Cloudflare 在運算方面一直在做的事情，可在幾毫秒內連線至世界上大多數人口。但是，儘管看起來違反直覺，但有時讓運算更接近使用者實際上反而會減慢應用程式的速度。如果您的應用程式需要連線至不位於終端使用者附近的 API、資料庫或其他資源，則在資源附近而不是使用者附近執行應用程式可能會有更高的效能。
因此，今天我們很高興地宣佈推出適用於 Workers 和 Pages Functions 的 Smart Placement，使每一次互動都盡可能快速。利用 Smart Placement，Cloudflare 透過將運算資源移動到最佳位置，將無伺服器運算引入超級雲端，從而加速應用程式。最棒的是，這是完全自動的，不需要任何額外的輸入（如可怕的「地區」）。
Smart Placement 現已提供公開測試版，供所有 Workers 和 Pages 客戶使用！
請觀看我們的示範，瞭解 Smart Placement 的運作方式！
無伺服器的轉變
Cloudflare 構建的 Anycast 網路可在靠近使用者的位置即時處理請求。這就是 Cloudflare Workers（我們的無伺服器運算產品）對開發人員如此具有吸引力的原因。競爭對手受到「地區」的限制，而 Workers 無處不在——因此我們只有一個地區，那就是地球。完全由 Workers 處理的請求可以立即處理，而無需到達來源伺服器。
雖然無伺服器的概念最初被認為適用於輕量級工作，但無伺服器運算近年來一直在轉變。它被用來取代依賴來源伺服器和自我管理基礎架構的傳統架構，而不是簡單地擴充它。我們看到越來越多的 Workers 和 Pages 使用者使用此類案例。
無伺服器需要狀態
隨著向無伺服器和在 Workers 上構建整個應用程式的轉變，對資料的需求也隨之而來。儲存有關先前動作或事件的資訊，可讓您構建個人化的互動式應用程式。假設您需要建立使用者設定檔、儲存使用者在哪個頁面離開、瞭解使用者購物車中有哪些產品——所有這些都對應到用於維護狀態的資料點。關聯式資料庫、鍵值存放區、Blob 儲存體和 API 等後端服務都可以讓您建置具狀態應用程式。
Cloudflare 運算 + 儲存：強大的二重奏
我們有自己不斷成長的儲存產品套件：Workers KV、Durable Objects、D1、R2。隨著我們資料產品的日漸成熟，我們會深入思考它們與 Workers 的互動，這樣您就不必再進行這樣的思考！例如，在某些情況下具有更好效能的另一種方法是移動儲存空間，而不是在使用者附近進行運算。如果您正在使用 Durable Objects 建立即時遊戲，我們可以移動 Durable Objects 以最大程度地減少所有使用者的延遲。
我們對於未來狀態的目標是您設定模式 =「智慧」，我們會評估您所有資源的最佳放置位置，無需您進行額外設定。
Cloudflare 運算 + ${backendService}
如今，Smart Placement 的主要使用案例是您為應用程式使用非 Cloudflare 服務（如外部資料庫或第三方 API）的情況。
無論是自我裝載還是受管理服務，許多後端服務都是集中式的，這意味著資料在單一位置儲存和管理。您的使用者是全球性的，Workers 是全球性的，但您的後端是集中式的。
如果您的程式碼向後端服務發出多個請求，它們可能會多次穿越全球，從而對效能產生重大影響。某些服務提供資料複製和快取，有助於提高效能，但也會帶來權衡取捨，例如資料一致性和更高的成本，應根據您的使用案例進行權衡。
Cloudflare 網路僅需約 50 毫秒即可連線到全球 95% 的連線人口。反過來說，我們也非常接近您的後端服務。
應用程式效能就是使用者體驗
讓我們透過一個範例來瞭解將運算移至靠近後端服務如何減少應用程式延遲：
假設您有一個在澳大利亞雪梨的使用者，他正在存取一個在 Workers 上執行的應用程式。該應用程式會對位於德國法蘭克福的資料庫進行三次往返，以便滿足使用者的請求。
憑直覺就可以猜到，瓶頸將是 Worker 對資料庫執行多次往返所花費的時間。如果 Worker 不是在靠近使用者的位置被叫用，而是在最靠近資料庫的資料中心被叫用，會怎麼樣？
我們來對此進行測試。
我們測量了未使用 Smart Placement 的 Worker 的請求持續時間，並將其與啟用 Smart Placement 的 Worker 進行比較。在這兩次測試中，我們從雪梨向一個 Worker 傳送了 3,500 個請求，該 Worker 對位於 eu-central-1（法蘭克福）的一個 Upstash 執行個體（免費層）進行 3 次往返。
結果顯而易見！在此範例中，將 Worker 移至更靠近後端的位置將應用程式效能提高了 4-8 倍。
網路決策不應該是人類的決策
作為開發人員，您應該專注於您最擅長的事情——構建應用程式，而無需擔心如何讓應用程式更快的網路決策。
Cloudflare 有一個獨特的優勢：我們的網路圍繞使用者、Cloudflare 資料中心和後端伺服器之間的最佳路徑收集情報——因為 Argo Smart Routing，我們在這一方面擁有豐富的經驗。Smart Placement 會考慮這些因素，自動將您的 Worker 放置在最佳位置，以最大限度地縮短整體請求持續時間。
那麼，Smart Placement 是如何運作的？
可以在 [設定] 索引標籤下或 wrangler.toml 檔案中針對每個 Worker 啟用 Smart Placement：
[placement]
mode = "smart"在 Worker 或 Pages Function 上啟用 Smart Placement 後，Smart Placement 演算法會即時分析 Worker 進行的擷取請求（也稱為子請求）。然後，它將這些與我們網路彙總的延遲資料進行比較。如果我們偵測到您的 Worker 平均向後端資源發出超過一個子請求，那麼將自動從最佳資料中心叫用您的 Worker！
出於充分的理由，Smart Placement 演算法不會考慮某些後端服務：
全球分散式服務：如果與您的 Worker 通訊的服務地理上分散在許多區域，則 Smart Placement 不適合。我們會自動將這些排除在 Smart Placement 最佳化之外。
分析或記錄服務：對分析或記錄服務的請求不需要位於應用程式的關鍵路徑中。應使用
waitUnil()，以便在檢測程式碼時不會阻止傳回使用者的回應。由於從使用者的角度來看，waitUnil()不會影響請求持續時間，因此我們會自動將分析/記錄服務排除在 Smart Placement 最佳化之外。
如需 Smart Placement 演算法未考慮的服務清單，請參閱我們的文件。
Smart Placement 啟動後，您將能夠在 Worker 上看到新的 [請求持續時間] 索引標籤。我們會在未啟用 Smart Placement 的情況下路由 1% 的請求，以便您瞭解其對請求持續時間的影響。
沒錯，就是這麼簡單！
請查看我們的示範，試用 Smart Placement（樂趣多多！）。要瞭解更多資訊，請造訪我們的開發人員文件。
Smart Placement 的後續計畫是什麼？
我們才剛剛開始！對於如何改進 Smart Placement，我們有很多想法：
支援在應用程式使用多個後端時計算最佳位置
微調放置位置（例如，如果您的 Worker 依據路徑使用多個後端。我們會按路徑而不是按 Worker 計算最佳放置位置）
支援基於 TCP 的連線
我們希望傾聽您的意見！如果您有意見反應或功能要求，請透過 Cloudflare 開發人員 Discord 聯絡我們。