騰訊雲國際帳號開通 騰訊雲CLB實現動靜態資源分離教學

一、為什麼要做動靜態資源分離

網站或應用在上線後，流量的性質通常會逐漸變得“分裂”：一部分請求主要是靜態資源——JS、CSS、圖片、字體、媒體檔；另一部分則是動態請求——登入、查詢、下單、個性化內容、API 回調。這兩類請求的特徵完全不同：前者更像“重複訪問的內容分發”，後者則更依賴“計算能力與狀態處理”。

騰訊雲國際帳號開通 如果把動靜態混在同一套後端、同一個路徑、同一個負載策略裡，常見的結果是：靜態資源吞噬了連線與帶寬，導致動態請求等待時間上升；動態服務因為突發流量被拖慢；而且你很難對靜態做針對性的快取、壓縮、降級策略。長期下來，性能成本越來越高，排障也越來越困難。

騰訊雲國際帳號開通 “動靜態資源分離”做的事其實很直觀：讓靜態請求走更適合分發的通道，動態請求走更關注計算與可用性的通道。你並不需要把整個系統改到面目全非；通常只要在入口層把流量分路、在後端層做合理配置，就能讓性能和可維護性顯著改善。

二、CLB 在這個方案裡扮演的角色

CLB（Cloud Load Balancer，通用負載均衡）能夠在入口接收用戶請求，根據規則轉發到不同後端實例或不同服務端點。對“動靜態資源分離”而言，CLB 的價值在於：你可以用 URL 路徑、主機名、請求協議、端口等條件，把請求精準地導到對應的後端組群。

騰訊雲國際帳號開通 把概念先定牢：靜態資源後端通常更輕量、可橫向擴展更快，且更適合做快取與 CDN/對象儲存回源；動態後端則需要更關注健康檢查、超時控制、連線保活、以及灰度發布後的可觀測性。CLB 是兩者之間的“切分點”。

此外，CLB 能提供一致的入口能力（統一網關、SSL、路由、健康檢查等），避免你在每個子系統前都搭一套入口，導致配置分散、管理成本飆升。

三、目標與衡量指標

在開始配置前，我建議先把目標量化。否則你會在“看起來已經分離了”與“真的提升了”之間徘徊。

可衡量指標大致分三類：

1. 性能類

動態接口的 P95/P99 延遲是否下降？靜態資源是否能保持穩定的回應時間？CPU、帶寬是否被更有效地利用？

2. 穩定性類

當動態服務擴容/故障時，靜態是否仍然可用？當靜態服務異常時，動態是否能不被拖累？

3. 可維護性類

發布、回滾是否更可控？監控告警是否能針對性定位到“哪一類流量”的問題？配置是否能被複用和模板化？

四、整體架構設計（從“分路”到“落地”）

一個典型架構可以長這樣：用戶請求先進入 CLB；CLB 根據規則把靜態流量轉發到“靜態後端”組群（例如 Nginx/對象儲存回源節點/靜態服務）；把動態請求轉發到“動態後端”組群（例如應用伺服器、API 網關、微服務）。

更進一步，你可以讓靜態請求走更激進的快取策略；動態則採取更保守的超時、重試和熔斷策略。兩邊的資源配比也應當不同：靜態通常更偏網路帶寬和快取命中率；動態則偏 CPU、記憶體、資料庫連線與排隊控制。

騰訊雲國際帳號開通 五、路由規劃：如何判斷“這個是靜態請求”

動靜態分離最關鍵的是路由規則要“穩定、可預期、可覆蓋”。你可以採用多層條件：URL 路徑、擴展名、前綴目錄、甚至是 header（例如 Accept 或自定義 header）。但對教學場景而言，最常用、也最容易落地的是：基於 URL 路徑與擴展名。

1. 路徑規則（建議作為主線）

常見做法：把靜態內容統一放在特定前綴目錄，例如：

/static/、/assets/、/images/、/css/、/js/、/fonts/。

這樣 CLB 只要看到請求以這些前綴開頭，就把流量導向靜態後端。

2. 擴展名規則（補充覆蓋）

有些項目靜態資源不一定都在固定目錄下，因此需要擴展名判斷：.js、.css、.png、.jpg、.jpeg、.gif、.svg、.woff、.woff2、.map、.mp4、.webm 等。

騰訊雲國際帳號開通 擴展名規則要注意兩個坑：第一，避免把 .json、.xml 等“可能是 API 回應”的請求誤判為靜態；第二，確認你的應用不會把動態頁面以奇怪的副檔名形式暴露。

3. 動態 API 規則（以白名單控制更穩）

對動態接口，你也可以採用白名單：/api/、/auth/、/order/ 等。當靜態匹配不完全時，動態白名單能避免請求落到錯誤後端。

更務實的做法是：先用靜態規則定義“明確屬於靜態的集合”，剩下的大多數情況就當作動態；同時對確實是動態但看起來像靜態的路徑，補充“例外規則”。

六、後端組群設計：靜態與動態應該各自怎麼配置

路由只是第一步，後端的處理方式決定你最後能得到多少收益。

1. 靜態後端：追求快與穩

靜態後端通常使用 Nginx、輕量 HTTP 服務或“指向對象儲存”的回源節點。配置重點包括：

• 合理設置 Cache-Control、ETag、Last-Modified（配合瀏覽器與上游快取）。
• 壓縮（Gzip/Brotli）只針對合適的資源類型，避免 CPU 被低價值請求拖垮。
• 上傳大檔時的超時、最大請求體大小要提前規劃。
• 對於會高頻訪問的小檔，優先保證文件系統與網路的吞吐，不要把靜態後端放在資源緊張的機器上。

如果你還配了 CDN，那靜態後端更像是回源服務，穩定性和回源策略會變得更重要。

2. 動態後端：追求吞吐與可控的延遲

動態後端的配置要面向“排隊與故障”，例如：

• 連線與超時（CLB 到後端的健康檢查超時、轉發超時等）要與應用超時邏輯一致，避免出現“前端等不到，但後端仍在處理”的浪費。
• 重試策略要謹慎。某些非冪等請求（例如下單）不應自動重試。
• 健康檢查要選對指標。只要用戶能看到成功頁就算健康，可能會錯誤掩蓋資料庫故障；健康檢查應能反映關鍵依賴。
• 對突發流量要有熔斷/限流/降級策略，否則隊列堆積會讓延遲爆炸。

七、在騰訊雲 CLB 上做分路：核心步驟

下面進入“教學落地”的核心部分。由於控制台界面會隨版本更新略有差異，我用概念與操作順序講清楚你應該做什麼；你照著類似項目逐一填即可。

1. 準備後端服務與實例

先把兩套後端準備好：

• 靜態後端：一組或多組承載靜態的實例（或回源服務）。
• 動態後端：一組承載 API/業務邏輯的實例。

建議你至少為每類後端準備多台，以免單點故障掩蓋問題。

2. 配置兩個後端目標池（或兩個服務組）

CLB 通常需要把後端實例歸到某個“後端服務/目標組”裡。你可以做兩個：靜態目標組、動態目標組。後續路由規則只要把流量轉發到對應目標組即可。

騰訊雲國際帳號開通 在目標組內，你還要配置協議與埠（例如 CLB 到後端用 HTTP 轉發，後端實例對應的埠是 80 或自定義埠）。

3. 設定健康檢查（靜態與動態都要有）

健康檢查是分路方案能否穩定運行的保命環節。兩類後端的健康檢查路徑不一定相同：

• 靜態後端可用簡單的 /health 或返回固定內容的路徑。
• 動態後端建議使用能反映關鍵依賴的探測路徑，例如包含資料庫連接檢測、或至少能返回版本/服務狀態。

調整參數時要注意：探測間隔太短會增加壓力；太長又會導致故障切換慢。你可以先用保守值觀察，再逐步收斂。

4. 配置監聽器（Listener）

監聽器對應“從哪個入口接收請求”。典型做法是：

• 80 端口（HTTP）重定向到 443（HTTPS），或直接在 80 上提供最小服務。
• 443 端口（HTTPS）作為主入口。

如果你需要 SSL 證書，請在監聽器層完成證書綁定。

5. 配置路由規則（核心：把 URL 分到不同目標組）

在路由層新增多條規則，順序很重要：一般“更精確的規則”應該放在前面，避免被寬泛規則吞掉。

例如你可以設計如下邏輯（用概念描述）：

• 規則 A（靜態前綴）：若 URL 路徑以 /static/、/assets/、/images/ 開頭，轉發到靜態目標組。
• 規則 B（靜態副檔名）：若 URL 以 .js、.css、.png、.jpg、.woff2 等結尾，轉發到靜態目標組。
• 規則 C（動態 API 白名單）：若 URL 以 /api/、/auth/ 開頭，轉發到動態目標組。
• 規則 D（兜底）：其餘未匹配的路徑轉發到動態目標組（或根據你的業務需要轉到前端渲染服務）。

這樣做的好處是：靜態規則覆蓋明確；動態規則提供保底；你不需要在 CLB 裡處理複雜的業務邏輯。

6. 檢查 HTTP 方法與壓縮等行為

不少團隊在這一步會忽略“行為一致性”。即使分路正確，如果你忽略某些細節，仍可能造成錯誤：

• 如果你的靜態服務只需要 GET/HEAD，確保其他方法不要誤路由到靜態。
• HTTP/2、壓縮、緩存頭由哪一層決定？CLB 有些能力會影響上游行為，你要保證最後對客戶端回應的頭部符合預期。

尤其對前端框架的資源（例如 SPA 的路由），要確認你不是把某些“應回靜態 index.html”的請求誤判為動態。

八、快取與回源：讓靜態真正“便宜”

做了分路不等於靜態就一定快。真正的收益來自“讓靜態請求更容易被快取命中”。即使你目前只用 CLB，仍可以把靜態服務做得更靠近“內容分發”的思路。

1. 設計靜態資源的 Cache-Control 策略

常見做法是“指紋化文件名”+“長緩存”：把資源檔名帶上 hash，文件更新時文件名變更，舊檔自然過期；此時就可以設置較長的 max-age，讓瀏覽器長期命中。

同時，對未指紋化但需要更新頻繁的檔（例如某些入口 index.html）則設置較短的緩存或協商式更新。

2. 回源與降級策略

如果你把靜態服務接到了外部儲存或回源鏈路，還要考慮“回源失敗時怎麼辦”。通常做法包括：

• 在回源失敗時返回合理的錯誤碼，並保證動態服務不受影響。
• 避免在故障期間對回源鏈路進行過度重試，否則會造成級聯故障。
• 在靜態目標組內保留足夠的容量，或至少提供可降級的備份來源。

九、監控與告警：你要看到“分離是否真的生效”

分路方案最怕的是“看配置像做了，實際沒生效”。因此監控要同時覆蓋兩個層次：入口路由命中與後端健康狀態。

1. 觀察路由命中率

你需要能看到：靜態規則是否被正確匹配，動態規則是否出現大量兜底。若兜底比例過高，通常意味著你的靜態路徑/副檔名規則覆蓋不夠。

2. 觀察後端成功率與延遲分佈

對靜態目標組與動態目標組分別看：

• 成功率（2xx/3xx）與錯誤率（4xx/5xx）。
• 延遲的分位數（P50/P95/P99）。
• 健康檢查狀態是否頻繁波動。

如果動態延遲仍然高，但你看到靜態規則匹配正確，那多半是動態服務自身的瓶頸（例如資料庫、緩存命中率、慢查詢）而不是入口流量混雜。

3. 在發布或擴容時做“對照試驗”

例如你做動態服務灰度發布，可以對比靜態目標組的錯誤率是否保持穩定。若靜態也一起抖動，說明你的故障可能是共享資源問題（如同一層網路、共享資料庫、或共享入口帶寬）。

十、常見踩坑與排查思路

下面這些坑是團隊實施過程中最常見的。你提前知道，就能少走彎路。

1. SPA 路由誤判

單頁應用常見情況是：前端路由由 JS 接管，後端需要把所有未知路徑回到 index.html。若你用“路徑兜底到動態”，動態服務可能正確回了 index.html；但若你用副檔名規則或特定前綴規則不當，可能導致某些前端路由被送到靜態後端，靜態後端找不到對應檔案。

解法：對前端路由做明確約束。要麼把“應回 index.html 的路徑”視為動態；要麼在靜態服務提供 index.html 回填邏輯（但那會讓靜態變複雜）。

2. 規則順序錯誤

很多人只看“我加了靜態規則”，但沒有注意路由規則的匹配優先級。若“兜底規則”在前，靜態規則永遠匹配不到。

解法：把精確規則放前，兜底放末尾；新增規則後用測試路徑驗證匹配結果。

3. 健康檢查過於寬鬆

動態服務健康檢查只返回 200，但其實資料庫不可用。表面上 CLB 認為服務健康，實際用戶請求會大量失敗。

解法：健康檢查探測要貼近“用戶能否完成關鍵流程”。至少要包含核心依賴的簡化檢測。

4. 資源配比沒有調整

分離後你仍用相同數量的實例承接兩類流量，效果會打折。因為靜態與動態在資源消耗上差異很大。

騰訊雲國際帳號開通 解法：根據觀測的流量比例、帶寬、CPU 使用率重新調整目標組容量。先保證穩，再做成本優化。

十一、容量演練：讓你在事故來臨時不慌

教學裡常常只講配置，不講演練。但真正在生產環境，要靠演練把不確定性變成可預期。

1. 模擬靜態後端故障

例如暫停靜態目標組的一部分實例，觀察：

• 健康檢查是否迅速判斷失效並摘除。
• 動態目標組是否完全不受影響。
• 用戶在靜態資源失敗時是否出現明顯的“白屏時間”或錯誤放大。

2. 模擬動態後端性能下降

可以在動態服務引入延遲（例如慢查詢或限流），看 CLB 轉發的超時與應用層行為是否一致。目標是讓“失敗能被快速切換/降級”，而不是讓隊列堆爆。

3. 發布回滾演練

用灰度發布動態服務，觀察：

• 路由分離後的流量是否仍然正確落到兩個目標組。
• 回滾時錯誤率是否能迅速回落。
• 監控告警是否能在第一時間指出“動態服務”而不是誤報“整體故障”。

騰訊雲國際帳號開通 十二、總結：真正有效的分離是“入口可控、後端可觀、策略可調”

用 CLB 實現動靜態資源分離，本質上是一種工程化的“流量治理”。你把靜態與動態的責任邊界在入口層切開，讓它們走不同的後端策略，從而達到性能更穩、成本更可控、排障更清晰。

一個好的方案通常具備三點：第一，路由規則清晰且可覆蓋（避免誤判與漏判）；第二，健康檢查反映真實可用性（避免假健康）；第三，監控與演練讓你能在問題發生時快速定位與切換。

當你完成這套分離後，不只是“看起來更專業”，更重要的是：你可以把資源用在刀刃上，把風險隔離在最小範圍內。這才是動靜態資源分離應該帶來的實際價值。