工程 · 2 min read
Load balancer 怎麼選後端
Origin 的 load balancer 怎麼選後端：路徑前綴交給 bucket，一條 header 規則交給 proxy，同一個網域就這樣分成兩條路線。
Load balancer 依路徑前綴把 request 交給不同的 bucket。有一條規則例外，它看 header。
上一篇我畫出 request 會走到 load balancer（一個 request 走過的路）。這一篇看 load balancer 怎麼決定下一站。
- 大部分檔案依路徑前綴，直接交給存放它的 bucket。
- Load balancer 有一條路由規則讀自訂的 proxy header（
x-use-proxy）。Proxy 本身不讀它。CDN 只在副檔名是 html、css、js 的 request 加上這個 header（Cache header：誰設定，誰讀取）。 - CDN 和 load balancer 都只看 URL 的副檔名，不看回應的 MIME type（
Content-Type）。 - Proxy 是一個 Go 寫的小服務，跑在雲端的 serverless 服務上，例如 AWS Lambda、Cloud Run、Azure Functions。它從 bucket 讀檔案，再做一點內容改寫。
- 共用 script 的規則排在 header 規則前面，所以共用 script 不經過 proxy。這就是 Load balancer：一個入口，依規則分給很多後端 說的 priority order。
同一個網域，兩條路
| Bucket 路線 | Proxy 路線 | |
|---|---|---|
| 檔案類型 | 圖片、影片、共用 JS | 素材資料夾裡的 html、css、js |
| 後端 | storage | serverless compute |
| 檔案來源 | storage bucket | 也是 storage bucket，經過 proxy 讀取 |
我當時只覺得這是一個分流設定。後來才知道，這兩條路線的 cache 行為完全不同（Bypass header 只在有規則的地方有效）。
兩條路線拿的是同一個 bucket 的檔案。不一樣的，是路上的那一層 cache。
延伸閱讀：Load balancer：一個入口，依規則分給很多後端、Cache header：誰設定，誰讀取、一個 request 走過的路、兩層 cache：我原本以為的樣子、Bypass header 只在有規則的地方有效。或回到系列總覽。