如果每個服務都自己處理認證、CORS、限流與 Log，第一次做完可能沒什麼感覺。真正麻煩的是共同政策改變之後，每個服務都得各改一次、各自測試、各自部署。所以我會先把適合共用的入口規則整理到 Gateway，但不是什麼都往 Gateway 塞。

本篇名詞小筆記

• Gateway：API 閘道，集中管理對外入口的路由、安全與流量政策。
• CORS：跨來源資源共用（Cross-Origin Resource Sharing），控制瀏覽器網頁可以呼叫哪些不同來源的服務。
• Correlation ID：關聯識別碼，讓同一筆請求在不同服務留下的紀錄可以互相對照。

今天要解決的問題

例如，只是想調整 CORS 來源，或統一 correlation ID 格式，卻需要所有服務各改一次、各自部署。過程中只要有一個漏掉，同一份政策就可能出現不同結果。後續要查差異，也會多花時間。

把規則集中之後，修改的地方比較清楚，但大家也會一起依賴這個入口。所以，我會先把 Gateway 的工作範圍劃好，再安排容量與故障處理。

架構師視角：Gateway 該做什麼、不該做什麼

Gateway 適合承擔的工作：

• 看 path、host 或 header，決定這筆請求要送到哪個服務。
• 先確認 Token 還有效，沒過就擋在入口。
• 把上游帶進來的 correlation ID 原封不動往下傳，讓下游接得起同一筆請求。
• CORS、限流和幾個共用的 Header，統一在這裡設一份。
• 記下入口的延遲、狀態碼和流量，之後要查才有數字可以看。

圖 Day 09-1：Gateway 治理控制點。

Gateway 若帶著業務規則，就得跟著每一項業務需求一起修改。所以訂單折扣、庫存是否足夠這類判斷，我會留給業務服務處理，Gateway 的 Filter 先對照入口共用政策。

要判斷一條規則放哪裡，我會先看它需要理解多少業務內容。像依 API 設定不同限流門檻，仍可以是入口政策；如果要知道訂單狀態或庫存規則才能決定，就需要回到業務服務確認。

有一點我想特別記下來：請求從內網進來，也不能直接當成可信任。所以 Gateway 驗過 Token，下游仍然要做自己的驗證。Day 11 與 Day 12 會再整理這個分工。

工程師視角：路由設定與管理端點

實作時，我會把路由設定放進版本控管，管理端點限制在受控範圍，後端也限制可接受的來源。接著實際測試，確認呼叫端不能繞過 Gateway，讓入口規則真的用得上。

錯誤回應也一起整理。對外有一致的格式與 correlation ID，使用者回報時才找得到那筆請求；內部例外與 stack trace，則留在有權限管控的 Log 裡查。

策略取捨與限制

入口整理好之後，還要維護它的可用性。這一層一旦出問題，所有依賴它的對外服務都可能一起受到影響，所以多個 instance、健康檢查與 timeout 都需要規劃。

驗證方式與衡量指標

入口上的資料，目前只能說明經過它的那一部分。所以也要看看有沒有流量繞過 Gateway；如果還有，就先列出來源與原因。

今天先整理到這裡

今天先把 Gateway 的工作整理在入口政策、路由與流量管理這個範圍。下一篇，我想用 Spring Cloud Gateway 的 Route、Predicate 與 Filter，繼續看看設定怎麼配合。

參考資料

1. Spring, Spring Cloud Gateway Reference，查閱日期：2026-09-22。