先看幾個重點
- 作者建議的做法是由一個閘道 worker 搭配透過 service bindings 連接的功能型 workers,作者表示這種拆分能在不增加額外網路跳轉的情況下,讓團隊與爆炸半徑解耦。
- 文章以影像最佳化為例,說明每個 edge 功能都會面臨的自建或採購決策。
- 文章中有一段警告指出,Akamai 與 Cloudflare 在執行與部署模型上的差異大到,在兩者之間移植一項功能比較接近重新架構,而非單純遷移。
摘自本文 · 2026-09-23
接著看完整內容在 SaaS 規模下拆分 Edge Worker

一篇於 2026 年 9 月 23 日發布的 InfoQ 文章,詳細說明 Salesforce 如何重構一套運行於 Cloudflare Workers 上的多租戶 SaaS edge 平臺,取代一個已累積了影像最佳化、容錯頁面、路由、標頭與 Cookie 重寫,以及每租戶設定查詢等功能的單一龐大 worker。該篇文章由 Salesforce 技術幕僚首席成員 Chintan Tank 撰寫,並由 AWS Data Hero Renato Losio 審閱,描述了此平臺如何在多個內容傳遞網路前端處理數十萬個租戶帳號的網路流量,並主張在這樣的規模下,單一 worker 模型會成為部署上的瓶頸。作者建議的做法是由一個閘道 worker 搭配透過 service bindings 連接的功能型 workers,作者表示這種拆分能在不增加額外網路跳轉的情況下,讓團隊與爆炸半徑解耦。
以影像最佳化作為實例分析
文章以影像最佳化為例,說明每個 edge 功能都會面臨的自建或採購決策。由於 CDN 的區域層級影像開關對多租戶 SaaS 來說過於粗糙,因此涵蓋 AVIF、WebP 與舊有格式的格式協商、依裝置調整的尺寸控制,以及每租戶的退出邏輯,都在 worker 內部實作。作者將這個模式定位為將每個 edge 能力視為可獨立部署的單元,而非再疊加到共用入口點的另一項職責的範本。
Akamai 與 Cloudflare 無法相互取代
文章中有一段警告指出,Akamai 與 Cloudflare 在執行與部署模型上的差異大到,在兩者之間移植一項功能比較接近重新架構,而非單純遷移。因此,在兩個 CDN 之間維持對等性會被視為一項持續性的約束,而非一次性的工作。從實例分析中得出的意涵是,團隊在設計 edge workers 時就必須為跨 CDN 相容性預作規畫,而非事後才補救。
每租戶版本控管與測試紀律
由於此平臺服務數十萬個租戶帳號,文章主張每帳號的版本控管與分階段佈署不再是可選項:適用於單一帳號的單一版本模型,一旦該帳號變成租戶基礎,就會成為一場全有或全無的豪賭。為了避免獨立的功能團隊彼此破壞,作者提出應用等級的測試紀律,包括每個功能 worker 的單元測試套件、在閘道層的整合測試,以及正式環境的合成監控,作為在此規模下安全部署的最低基本要求。
分享這篇文章






